cargo clean --offline 仍下载工具链：先检查 rustup 代理

cargo clean --offline 没有删除构建输出，反而先打印 syncing channel updates，随后因下载工具链元数据失败而退出。若项目的 rust-toolchain.toml 指定了本机未安装的版本，应先检查 rustup 代理这一层。

终端里的 cargo 可能是 rustup 提供的代理。它先决定应该启动哪个工具链中的 Cargo，缺失时可能尝试安装；只有真正的 Cargo 被启动后，--offline 才能约束它的网络访问。因此，离线模式不能自动提供一个本机不存在的 Cargo。

先确认所选工具链已经在本机

查看项目工具链文件及目录覆盖设置，再通过 rustup toolchain list 核对已安装版本。不能只看到机器上有一个 stable 就认定项目指定版本可用，也不要为了清理产物随意改掉整个项目的工具链约束。

真正需要离线工作时，应在获准联网的准备阶段，预置项目要求的工具链及组件。离线 CI 镜像也要带上同样内容；复制源码和依赖缓存，并不会一并复制编译工具链。

如果此时必须保证不自动下载，可仅对这次进程禁用 rustup 自动安装：

RUSTUP_AUTO_INSTALL=0 cargo clean --offline

这是 POSIX shell 写法。缺少所选工具链时，它应直接报错，而不是完成清理；这项设置解决的是意外自动安装，不是让不存在的工具链可用。Windows 环境按相应终端设置变量，并在受控范围内恢复原值。

不用盲删 target 代替工具链判断

手工递归删除 target 看似能避开启动问题，但输出目录可能被 target-dir、环境变量或其他构建设置改变。目录里也可能有需要保留的诊断材料，不能看到同名目录就直接删除。

确实要清理可重建产物时，先确认实际目录、用途和没有正在写入的构建，并保留需要的材料；更稳妥的入口仍是让匹配工具链的 Cargo 按项目配置清理。另选一个已安装版本也可能面对不同目录布局与配置，应先确认兼容性，不能把全局改成 stable 当作无条件修复。

验收分别检查两个结果：禁止自动安装时没有再尝试下载；正确工具链预置后，原离线清理入口能找到它，并只处理预期构建输出。前者失败得更快，不等于后者已经完成。