sccache 把工作区包装器认成 C 编译器：检查探测阶段的 CARGO

Dioxus 等工具启动 Rust 构建时，日志显示 sccache dx /path/to/rustc -vV，接着报 Compiler not supported，还可能出现看似 C 编译器无法理解 Rust 片段的语法错误。若同时配置了 RUSTC_WRAPPER 和 RUSTC_WORKSPACE_WRAPPER，先检查版本探测进程是否收到 CARGO。

Cargo 1.94.1 的这个分支会让 rustc -vV 经过包装链，却未像正常编译那样提供 CARGO。sccache 检测到的第一个可执行文件不是 rustc 时，会用 CARGO 的存在作为识别工作区包装器的条件；缺少它，就可能误入另一种编译器检测路径。

保留双层包装，只补正确的环境

先确认包装器顺序与实际可执行文件。典型链是外层 sccache，再到工具设置的工作区包装器，最后才是 rustc。不要为了让第一个文件看起来像 rustc，就把包装器改名或复制成另一个编译器。

对仍受影响的入口，可仅给该进程提供实际使用的 Cargo 路径，例如：

CARGO=/approved/toolchain/bin/cargo dx serve

这是 POSIX shell 的局部环境示例，路径必须替换成当前项目使用、真实可执行的 Cargo，dx serve 也应是原来获准的开发入口。不要为了填上变量，从 PATH 中随意挑另一套不兼容的工具链。命令会启动开发构建及相关进程，执行前应保留原参数与环境。

后续 Cargo 的探测实现已补上这一环境设置；更换工具链时仍需核对实际调用链。机器装了新版 Cargo，但外层工具继续启动旧版，也不会改变探测进程。

缓存命中率是另一条问题

这里发生在识别编译器阶段，并不是已经编译后因为 CARGO_* 值变化而缓存未命中。清空 sccache 或删掉 Cargo 缓存不能补上缺失的环境，也不应机械删除所有 CARGO 相关变量。

验收先确认 -vV 探测能正确识别真正的 rustc，再让原构建继续，检查项目需要的工作区包装功能仍在。对使用热重载的开发流程，还要验证该功能没有因移除包装器而悄悄失效。若变量已经正确传入却仍报不支持，继续核对包装器版本和完整参数，不能把所有 sccache 识别错误都归为这一原因。