Cargo 报 Option verbose given more than once，检查两处详细日志开关

构建还没进入 Rust 源码检查，就报 Option 'verbose' given more than once。查看实际 rustc 命令后若能看到两次 --verbose，应先处理参数来源，修改业务代码不会解除这个命令行错误。

Cargo 1.99.0-nightly（2026-07-29）的明确触发组合是：

CARGO_TERM_VERBOSE=true RUSTFLAGS=--verbose cargo +nightly check

Cargo 的详细模式与手动编译器参数相遇后，可能产生重复的 --verbose。这是特定 nightly 的已知触发，不应扩大成所有 Cargo 版本都有同一问题。

分清谁需要详细输出

CARGO_TERM_VERBOSE 面向 Cargo 输出；RUSTFLAGS 会进入 rustc 调用。若自己只想看详细构建过程，通常不必再手动向 rustc 加同名参数。删除自己加入的 --verbose，保留优化、条件编译或链接选项等其他必要内容。

若 RUSTFLAGS 完全只有 --verbose，可在当前命令中去掉这一变量，再保留 Cargo 的详细输出。不要在不知道内容时整体清空 CI 的 RUSTFLAGS：它还可能承载目标平台必需的参数。

有些项目通过 trybuild 等测试工具设置 RUSTFLAGS=--verbose，调用方未必方便修改。此时先在该测试步骤局部关闭 Cargo 详细模式，并检查外层脚本有没有额外传 -v。例如，在原工具链与测试参数保持一致的前提下，把 CARGO_TERM_VERBOSE 设为 false，仅用于验证是否为这个冲突。不要永久关闭全部日志后就结束排查。

保存最终 rustc 参数，而不只看环境变量

参数还可能来自 .cargo/config.toml、上级配置、编码环境变量或测试工具内部。检查真正失败的 rustc 命令，确认 --verbose 剩下一次或不再出现，同时核对其他 flags 保留。

工具升级后应重新确认它是否仍注入该参数。不要仅因为一个修复 PR 合并，就假定当前安装的 trybuild 或 Cargo 已包含修复；以锁文件、工具链版本和实际调用为准。

修改前保留 CI 变量与配置差异，复查原失败命令和相关编译失败测试。编译失败测试可能比较诊断输出，关闭或改变详细模式后还需检查期望输出，不能只看进程不再因参数错误退出。若后续升级让临时设置不再必要，逐项移除绕行并复测，避免它长期掩盖新的诊断差异。