Rust 1.100 调整 32 位 Windows 支持：保留标准库，开发转向交叉编译

从 Rust 1.100.0 开始，两个 32 位 Windows 目标将不再提供宿主工具链：i686-pc-windows-msvc 从“带宿主工具的 Tier 1”调整为“不带宿主工具的 Tier 1”，i686-pc-windows-gnu 则从“带宿主工具的 Tier 2”调整为“不带宿主工具的 Tier 2”。标准库仍会发布，但开发者需要在受支持的宿主环境中交叉编译 32 位程序。

这不是删除 32 位 Windows 目标，也不意味着现有的 32 位二进制立即失效。真正变化的是：不能再把 32 位 Windows 当作 Rust 编译器、Cargo 等工具的运行平台。

“只提供 std”具体意味着什么

调整之后，Rust 仍然会为以下目标分发预编译标准库：

• i686-pc-windows-msvc
• i686-pc-windows-gnu

因此，64 位 Windows 等受支持宿主上的 Rust 编译器，仍可生成对应的 32 位 Windows 程序。但这些目标不再获得可直接运行在 32 位 Windows 上的宿主工具，例如：

• rustc
• cargo
• rustdoc
• 其他随工具链分发的宿主可执行文件

两个目标的保障等级也有所区别：

这里最容易误解的是“Tier 1”。i686-pc-windows-msvc 仍是 Tier 1 目标，并继续接受 CI 测试，但它已经不是一个受支持的 Rust 宿主平台。目标支持与宿主工具支持是两件不同的事。

其他 32 位平台不受这次调整影响。

为什么交叉编译成为默认路线

桌面和服务器领域已经超过 15 年没有销售仅支持 32 位 x86 的新 CPU，通用的 32 位 Windows 支持也已在 2025 年 10 月结束。仍然运行这类系统的机器数量很少，硬件能力通常也不适合承担现代 Rust 与 LLVM 工具链的构建工作。

即使在现代 x86_64 硬件上生成 i686 Windows 宿主工具链，稳定性和资源消耗仍是实际障碍。相关构建中已经出现过 i686 MSVC 编译器二进制崩溃，以及 GNU C++ 工具链在构建 LLVM 时内存耗尽的问题。

因此，Rust 项目选择保留“生成 32 位程序”的能力，同时停止生产“运行在 32 位系统上的开发工具”。这将维护成本集中到更常见、更可靠的 64 位宿主环境中。

在 64 位 Windows 上构建 32 位程序

下面以 MSVC 目标为例。运行前需要准备：

1. 64 位 Windows Rust 工具链；
2. Visual Studio Build Tools，以及可用于 x86 的 MSVC 工具；
3. Rust 1.100.0 或更新版本。

在 PowerShell 中可以这样创建并编译一个最小项目：

# 确认当前 Rust 编译器运行在受支持的宿主上
rustc -vV

# 为当前宿主工具链安装 32 位 Windows 标准库
rustup target add i686-pc-windows-msvc

# 创建示例项目
cargo new hello-win32
Set-Location hello-win32

@'
fn main() {
    println!("Hello from a 32-bit Windows binary!");
}
'@ | Set-Content -Encoding utf8 .\src\main.rs

# 由 64 位宿主工具链生成 32 位程序
cargo build --release --target i686-pc-windows-msvc

# 产物位于：
Get-Item .\target\i686-pc-windows-msvc\release\hello-win32.exe

如果安装了 Visual Studio 的 dumpbin，可以进一步确认 PE 文件的机器类型：

dumpbin /headers .\target\i686-pc-windows-msvc\release\hello-win32.exe |
    Select-String "machine"

输出中应能看到 x86 或 14C 一类标识。注意，成功构建只说明链接过程完成；如果程序依赖 DLL、驱动或其他本地组件，仍需要在真实的 32 位运行环境中做兼容性测试。

如果项目始终需要生成 32 位产物，可以添加 .cargo/config.toml：

[build]
target = "i686-pc-windows-msvc"

此后直接运行 cargo build --release 即可。但对同时发布 32 位和 64 位版本的项目，不建议全局固定目标；在 CI 或发布脚本中显式传递 --target 通常更清晰。

CI 中同时发布 x86 与 x64

可以这样实践：让 Windows x64 Runner 承担两种架构的构建，而不是维护一台 32 位构建机。下面是一个可改造的 GitHub Actions 示例：

name: windows-release

on:
  workflow_dispatch:
  push:
    tags:
      - "v*"

jobs:
  build:
    runs-on: windows-latest
    strategy:
      matrix:
        target:
          - x86_64-pc-windows-msvc
          - i686-pc-windows-msvc

    steps:
      - uses: actions/checkout@v4

      - name: Install Rust target
        shell: pwsh
        run: rustup target add ${{ matrix.target }}

      - name: Build release binary
        shell: pwsh
        run: cargo build --release --locked --target ${{ matrix.target }}

      - name: Upload artifact
        uses: actions/upload-artifact@v4
        with:
          name: app-${{ matrix.target }}
          path: target/${{ matrix.target }}/release/*.exe

对于 i686-pc-windows-gnu，思路相同，但宿主环境还必须提供兼容的 32 位 MinGW 链接器和相关本地库。若项目没有必须使用 GNU ABI 的约束，在 Windows 上通常应优先评估 MSVC 目标，因为它仍保持 Tier 1 和 CI 测试状态。

迁移时不要只检查 Rust 代码

纯 Rust 项目通常只需安装目标标准库并修改构建命令。包含本地依赖的工程则需要额外审查：

• C、C++ 或汇编代码是否能够编译为 x86；
• 链接的 .lib、.a 和 DLL 是否提供 32 位版本；
• build.rs 和过程宏应由宿主工具链运行，不能误用目标架构的可执行文件；
• 打包脚本是否从新的 target/i686-pc-windows-msvc/release 路径取文件；
• 自动化测试是否覆盖真实或虚拟化的 32 位 Windows 环境；
• 应用自身以及第三方依赖是否仍承诺支持 32 位 Windows。

如果团队目前仍在 32 位 Windows 上运行 Cargo，迁移重点不是“寻找另一个 32 位 Rust 安装包”，而是把构建任务转移到 64 位 Windows 或其他受支持的宿主工具链。现有 32 位机器更适合作为部署验证环境，而不再适合作为开发和发布节点。

Rust 1.100.0 的边界很明确：32 位 Windows 仍可作为输出目标，但不再作为工具链宿主。尽早把目标安装、交叉编译、本地依赖检查和 x86 运行测试纳入 CI，可以让这次调整停留在构建流程层面，而不是在发布当天变成故障。