Cargo 2026 新特性预览脚本支持、命名空间和构建缓存增强的影响保持学习保持输出。Cargo 是 Rust 的基石2026 年它要迎来一波大更新每个 Rust 开发者都应该关注。你可能觉得它就是个包管理器和构建工具但实际上 Cargo 的每一次升级都会悄悄改变 Rust 项目的开发体验。2026 年 Cargo 有几个正在推进的特性特别值得关注单文件脚本支持、crate 命名空间、构建缓存增强。一、单文件脚本支持Rust 终于有了Hello World 速写这是我最期待的特性。目前写一个最简单的 Rust 程序你至少需要cargo new my_script # 创建一个完整的项目 cd my_script # 编辑 src/main.rs cargo run # 构建并运行对于一个只是想测试三行代码的场景来说这个项目初始化的仪式感实在太重了。而 Python 呢echo print(hello) test.py python3 test.py一个命令搞定。Cargo 脚本正是为了解决这个痛点。2026 年的提案让 Rust 可以像 Python/Node.js 一样运行单文件脚本#!/usr/bin/env cargo // 文件名: hello.rs // 直接运行: cargo run hello.rs // 或给文件加执行权限: chmod x hello.rs ./hello.rs // 脚本顶部声明依赖 // [dependencies] // serde { version 1, features [derive] } // serde_json 1 use serde::{Deserialize, Serialize}; #[derive(Debug, Serialize, Deserialize)] struct Person { name: String, age: u8, } fn main() { let alice Person { name: Alice.to_string(), age: 25, }; // 直接序列化为 JSON不需要新建 cargo 项目 let json serde_json::to_string_pretty(alice).unwrap(); println!({}, json); }这背后涉及的技术点值得展开说说关键设计脚本编译结果会被缓存。第一次运行会触发编译后续运行时如果脚本内容没变直接使用缓存的二进制启动速度和 Python 脚本处于同一量级。对选手来说这个特性的价值特别大。因为它降低了写一小段 Rust 代码的摩擦成本#!/usr/bin/env cargo // 文件名: parse_log.rs // 场景快速分析昨天的 Nginx 日志 // [dependencies] // regex 1 // chrono 0.4 use regex::Regex; use std::fs; fn main() - Result(), Boxdyn std::error::Error { // 读取 Nginx 访问日志 let log_content fs::read_to_string(/var/log/nginx/access.log)?; // 正则提取 IP 地址和时间戳 let ip_pattern Regex::new(r(\d\.\d\.\d\.\d))?; let mut ip_counts std::collections::HashMap::new(); for line in log_content.lines() { if let Some(caps) ip_pattern.captures(line) { let ip caps[1].to_string(); // 统计每个 IP 的访问次数 *ip_counts.entry(ip).or_insert(0) 1; } } // 输出 Top 10 访问 IP let mut sorted: Vec_ ip_counts.into_iter().collect(); sorted.sort_by(|a, b| b.1.cmp(a.1)); println!(Top 10 访问 IP); for (i, (ip, count)) in sorted.iter().take(10).enumerate() { println!( {}. {} - {} 次, i 1, ip, count); } Ok(()) }这种一次性脚本用 Python 写当然也行但如果你已经熟悉 Rust你会喜欢它的类型安全和编译期检查——至少不会因为把String和str搞混而在运行时 panic。二、Crate 命名空间解决好名字都被占了的终极方案crates.io 上超过 15 万个 crate好名字基本都被占完了。而 Cargo 的命名空间提案就是为了解决这个问题。命名空间的意义不仅是名字好找了它还能改善代码组织# 当前的 Cargo.toml [dependencies] serde 1 serde_derive 1 serde_json 1 serde_yaml 0.9 # 未来的 Cargo.toml层级命名空间 [dependencies] serde::core 1 serde::derive 1 serde::json 1 serde::yaml 0.9代码中也更清晰// 当前依赖名和 crate 名容易混淆 use serde::{Serialize, Deserialize}; use serde_json; // 很多人会写成 use serde::json然后报错 use serde_yaml; // 未来命名空间让关系一目了然 use serde::{Serialize, Deserialize}; // serde::core use serde::json; // serde::json use serde::yaml; // serde::yaml特别对那些同一个组织维护多个子 crate的项目来说命名空间会让依赖关系更直观。比如 async-std →async_std::fs、async_std::net、async_std::task。再比如 tokio 的各个 feature flag 子模块。不过这里有个工程上的细节值得注意命名空间与 feature flag 的交互。如果 tokio 变成了tokio::fs、tokio::net这样的形式每个子 crate 可以独立管理自己的 feature flag而不是在根 crate 里维护一个越来越长的 features 列表。三、构建缓存增强写一行编译一次的时代要结束了编译速度是 Rust 被吐槽最多的问题之一。2026 年 Cargo 在构建缓存方面有几个重要改进具体来说增强集中在三个方面1. 全局共享缓存目前每个项目的target/目录是独立的。如果你有 10 个 Rust 项目都依赖 tokio 1.x你的硬盘上就会有 10 份 tokio 的编译产物。# 当前每个项目独立编译依赖 project1/target/release/deps/libtokio-xxx.rlib # 127MB project2/target/release/deps/libtokio-xxx.rlib # 127MB (完全相同的文件) # 10 个项目 1.27GB 浪费 # 未来全局共享缓存 ~/.cargo/cache/target/libtokio-1.x.rlib # 所有项目共享这一份 # 本质上是把 sccache 做得更深度集成2. sccache 原生集成sccache已经能显著加速编译但它需要额外安装和配置。Cargo 2026 提案把类似功能直接集成进 Cargo 本身# 未来在 Cargo 配置中开启 # ~/.cargo/config.toml [build] cache-dir /home/user/.cargo/cache-build # 构建缓存目录 shared-target true # 启用跨项目共享 distributed-cache redis://cache-server:6379 # 可选的分布式缓存对个人开发者来说最直观的感受是第一次cargo build后换个项目再 build如果用到相同版本的依赖速度会快很多。3. 细粒度依赖追踪// 当前一个 mod 文件修改整个 crate 重新编译 // 未来只有实际依赖了被修改部分的代码才重新编译 // 假设你修改了 helper_c.rs 中的内部实现 // mod helper_a.rs ─── 不依赖 helper_c → 不重新编译 // mod helper_b.rs ─── 依赖 helper_c 的类型定义变了 → 重新编译 // helper_c.rs ─────── 被修改 → 重新编译 // 这种细粒度的依赖追踪在大型项目中能省很多编译时间对于我这种每写三行代码就想cargo check一下确认正确的选手来说构建速度每提升 10% 都意味着每天多写几十行代码。四、这些特性对你的项目意味着什么我按项目规模分三种情况来看影响// 情况 1个人学习项目1-5 个 .rs 文件 // 影响★★★★★最大 // 单文件脚本直接省掉 cargo new 的步骤 // 写一段测试代码变成 5 秒的事 // 情况 2中型项目10-50 个文件多个外部依赖 // 影响★★★★ // 命名空间让依赖管理更清晰 // 全局缓存让 CI 构建节省 30-50% 时间 // 情况 3大型项目/工作区workspace100 个文件 // 影响★★★ // 细粒度追踪对编译时间影响最大 // 分布式缓存对 CI 团队有显著收益如果你现在就开始做准备我建议整理现有的Cargo.toml把功能相近的依赖放在一起虽然命名空间还没上线但好习惯先养起来关注 sccache 配置即使原生集成还没到现在配置好 sccache 也能省不少编译时间把常用脚本改成 Rust 单文件试试用 nightly 的 cargo-script 功能感受下Rust 脚本的体验# 安装 cargo-scriptnightly 预览版 cargo install cargo-script # 创建一个快速脚本 cat check_deps.rs EOF #!/usr/bin/env cargo // [dependencies] // cargo_toml 0.15 fn main() - Result(), Boxdyn std::error::Error { // 快速检查项目的依赖是否有更新 let manifest cargo_toml::Manifest::from_path(Cargo.toml)?; for (name, dep) in manifest.dependencies.iter() { println!( {}: {}, name, dep.req()); } Ok(()) } EOF cargo-script check_deps.rs五、总结Cargo 2026 的三个方向让我对 Rust 开发体验有了新的期待单文件脚本降低学习摩擦。不再需要cargo new才能写 Rust 代码对选手来说意味着想到就写、写了就跑的即时反馈。学 Rust 最怕的就是被工具链劝退脚本支持让门槛降了一大截。命名空间解决生态扩展的瓶颈。crates.io 注册量每年翻倍扁平命名空间迟早会撞墙。层级命名空间是典型的未雨绸缪——不是当前最痛的问题但等痛了再来改就晚了。构建缓存是生产力基建。写得快但编得慢和编得快但写得慢都不是好状态Cargo 2026 在努力让两者都快起来。全局缓存 细粒度追踪 sccache 集成三管齐下。工具链的进步与语言本身同样重要。Rust 语言固然好但如果 Cargo 不好用你的产品力会大打折扣。我从 Python 生态转过来时特别感受深刻——pip/poetry/uv 的体验和 Cargo 的体验差距直接影响了我的开发效率。保持学习保持输出。现在用的这些工具每天都在迭代 跟上变化本身就是一种竞争力。资料说明本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论不应视为行业事实。可参考 0730 资料来源索引并在发布前将具体来源贴到对应断言之后。