CARGO_BUILD_WARNINGS=deny 让链接警告也失败，先区分 Cargo 与 rustc 的门禁
同一个 linker_messages 在 -D warnings 下仍是警告，Cargo 的 warnings=deny 却可能让构建失败。先定位门禁层，再按项目策略局部绕行。
编译器仅输出 warning: linker stderr: ...，链接器没有因缺符号退出，但设置 CARGO_BUILD_WARNINGS=deny 后构建仍失败。若去掉这个 Cargo 设置就能完成，要先区分 Cargo 的警告门禁与 rustc 的 -D warnings，不要直接按链接失败去补库。
build.warnings 从 Cargo 1.97 起受支持，CARGO_BUILD_WARNINGS 是它的环境变量入口。2026 年 10 月的一个明确问题是：linker_messages 这种在 rustc 中仍保留为警告的诊断，会被 Cargo 的 deny 策略计入失败。该行为不能等同于“所有警告都被 rustc 升成 error”。
看最后失败的是哪一层
保存完整构建输出、工具链版本和实际环境。重点区分链接器非零退出、编译器硬错误，以及 Cargo 在收到警告后中止。
例如 '+zcm' is not a recognized feature for this target (ignoring feature) 是链接器诊断的一种形状，不能只看到它就认定缺少某个动态库。另一方面，真正的 undefined symbol、目标架构不兼容或链接器非零退出，仍需独立修复，不会因改警告等级而消失。
查看 CI、用户级和项目 .cargo/config.toml 是否设置了 build.warnings = "deny"，也检查 CARGO_BUILD_WARNINGS。环境中的设置可能与仓库文件不一致。
临时绕行应保留警告
若已经确认失败仅来自这层门禁，并且团队审阅过对应链接警告，可在受影响步骤局部把 Cargo 的策略改回 warn：
CARGO_BUILD_WARNINGS=warn cargo build
这里应替换为原来的构建子命令和参数，保留原 target、profile 与其他 flags。这会取消该步骤的 Cargo 警告失败策略，影响范围不只当前一条链接诊断，需要按项目对警告的要求决定是否接受。
不要改成 allow 来隐藏全部警告，也不要清空所有 RUSTFLAGS：其中可能有目标平台或安全构建需要的参数。若项目原本使用 rustc lint 门禁，仍应保留并验证它，不能因这个差异静默取消质量要求。
该问题没有提供可在这里承诺的正式修复版本。后续升级需检查匹配版本的行为，再用原诊断复查；问题关闭或关联到另一个报告不代表已安装包已修复。
验收不仅看退出码，还要确认原警告仍可见、真正编译错误仍使构建失败、产物通过项目原有测试。保留改动前的门禁配置和采用绕行的原因，后续恢复 deny 时重新跑同一路径，避免临时设置长期覆盖其他警告。