rustup 1.29.1 发布：并发更新、更灵活的文档服务与更清晰的平台边界

预计阅读时间：7 分钟

rustup 1.29.1 已发布。这一版本没有引入破坏性的 CLI 变更，但改善了多个日常操作的效率和可预测性：工具链更新检查可以并行执行，批量组件安装也会并发进行；本地文档新增 HTTP 服务模式；部分过去会隐式安装活动工具链的行为则开始发出弃用警告。

更新和组件安装更快

运行 rustup update 时，rustup 会并行检查可能存在的更新。对于需要维护多个工具链的开发机或 CI 环境，这可以减少等待时间。

批量执行 rustup component add 时，多个组件也会并发安装。例如，可以一次安装格式化工具、代码检查工具和文档组件：

rustup component add rustfmt clippy rust-docs

如果项目固定使用某个工具链，建议显式指定它，避免命令依赖当前默认工具链：

rustup component add --toolchain stable rustfmt clippy
rustup update stable

并发操作主要改善等待时间，并不意味着所有网络或磁盘问题都会消失。在共享缓存、代理服务器或杀毒软件扫描较重的环境中，仍应观察实际耗时和失败日志。

rustup doc 现在支持 --serve 参数，可以通过本地 HTTP 服务打开 Rust 文档。这对容器化开发环境尤其有用：浏览器运行在宿主机，而 rustup 和工具链运行在容器中时，HTTP 端口比直接打开容器内文件更容易访问。

可以这样启动本地文档服务：

rustup doc --serve

如果需要明确监听端口，可以按当前版本支持的参数查看帮助信息并选择端口：

rustup doc --help
rustup doc --serve --port 8000

上面的端口参数示例适用于支持 --port 的环境；实际使用前应以本机 rustup doc --help 的输出为准。容器中运行时，可以发布端口：

docker run --rm -it -p 8000:8000 your-rust-image \
  sh -lc 'rustup doc --serve --port 8000'

然后在宿主机浏览器访问 http://localhost:8000。生产环境不应把这个临时文档服务直接暴露到公网。

1.29.1 开始，某些过去会在 rustup-init 或 rustup 命令中隐式安装活动工具链的场景，如果并不需要这种安装，rustup 会给出警告。这意味着脚本不应再把“命令自动完成安装”当作无条件保证。更稳妥的做法是显式安装并检查工具链：

set -eu

rustup toolchain install stable --profile minimal
rustup default stable
rustc --version
cargo --version

在 64 位 Windows 上安装 i686-pc-windows-* 主机工具链时，现在需要显式使用 --force-non-host。这提醒我们：目标平台和当前主机平台并不总是相同，跨平台安装应写出明确意图。

此外，项目内部将 “target triple” 更名为 “target tuple”，这是术语调整，不会破坏现有 CLI 用法；例如 --target 选项仍然可用。1.29.1 还正式支持 aarch64-pc-windows-gnullvm 主机平台。

已有 rustup 的用户可以先关闭正在使用 rustup 的程序，例如 IDE 或正在运行的 Cargo 任务，然后执行：

rustup self update

普通工具链更新结束时，rustup 也会自动尝试更新自身，因此下面的命令同样可以完成常规升级：

rustup update
rustup --version

rustup-init 取消安装后不再在磁盘上留下预期之外的文件；同时，使用 rustup-init.sh 时可能导致 Windows 安装失败的问题也已修复。

Windows 用户仍需留意杀毒软件行为。rust-docs 包含大量小文件，新版本发布后，反恶意软件扫描器可能暂时阻止文件创建或复制。这类问题通常会在扫描器获得新版本识别规则后自行缓解。遇到安装失败时，应同时检查 rustup 日志、文件权限以及安全软件隔离记录。

rustup 1.29.1 适合直接纳入日常 Rust 工具链维护，但建议按以下方式落地：

这次版本更新的重点不是新增复杂命令，而是让常用操作更快、文档访问更适合容器环境，并逐步减少隐式行为带来的不确定性。