Cargo 改了包描述仍显示旧值：检查外部同名环境变量

改了 Cargo.toml 的 package.description，程序里 env!("CARGO_PKG_DESCRIPTION") 编译进去的内容却还是旧描述；换一个全新的 target 目录又能得到新值。若启动 Cargo 的环境中恰好保留着旧的 CARGO_PKG_DESCRIPTION，先把这个变量与构建新鲜度判断放在一起检查。

Cargo 1.99.0 的明确触发组合是：先用旧描述编译，随后只修改清单描述，再让外层环境继续提供旧描述。普通构建复用旧二进制，而独立输出目录重新构建得到新描述。这不等于 env! 会在运行时读取 shell，也不能据此认定所有清单修改都不会触发重编译。

描述属于编译输入，运行时改环境补不回来

Cargo 为编译中的 crate 设置 CARGO_PKG_DESCRIPTION，其正常含义是该包清单中的描述。下面的 Rust 片段在编译期取得它：

const DESCRIPTION: &str = env!("CARGO_PKG_DESCRIPTION");

如果业务使用的是 std::env::var，那是运行时读取环境，排查路径不同。先确认真正部署的二进制、选中的包和工作区继承配置，再比较该包解析到的描述；不要误把根工作区的字段当作每个成员已经采用的字段。

在这条特定组合中，外层同名旧值会伴随错误的复用结果，但它并非应用应当用来覆盖清单描述的正式配置入口。内部具体如何比较编译环境仍需结合所用 Cargo 的实现和日志确认；不能从一次旧值输出推断清单完全没有被读取。

构建脚本也可能通过 cargo::rustc-env 设置同名变量。遇到这种项目，要保留这层输入并核对最终传给 rustc 的值，不能只删除 shell 变量后就宣称所有优先级问题都已解决。

去掉外部旧值，再用独立输出目录对照

先检查 CI、包装脚本或开发 shell 为什么设置了 CARGO_PKG_DESCRIPTION。若只是上一轮构建残留，就在原有入口局部移除这一项，保留项目所需的其他环境。POSIX shell 中，一次命令可以写成：

env -u CARGO_PKG_DESCRIPTION cargo run -q

这会构建并运行当前项目，可能还原依赖；参数应补上原来的包选择、功能、目标和配置。Windows 使用所在终端对应的临时移除方式，不要直接照抄 POSIX 写法。

若仍拿到旧内容，在没有其他构建写入的情况下，选择本任务独占、此前不存在的输出目录，保留同一份源码和依赖条件做一次冷构建。例如：

env -u CARGO_PKG_DESCRIPTION cargo run -q --target-dir target-description-check

target-description-check 是示例目录名，应先确认归属和不存在；它会新增构建产物，不能指向其他项目或正式发布目录。冷构建得到新描述，能够把“当前源码编译结果”与“旧输出被复用”区分开，但不会修正 Cargo 内部的增量判断。

不要手工改二进制中的字符串，也不要删除整个 Cargo home。若最终需要清理旧产物，先确认实际 target 目录、包范围和无并发写入，按项目已有流程处理可重建输出。清理后仍留下外部旧值，会让后续编辑再次面对同一触发条件。

验收要连续覆盖两次不同描述：每次修改后，普通增量入口与独立输出目录应得到一致的新值；同时检查原有构建脚本确实需要设置的变量没有被误删。正式版本升级后仍用同一组合回归，不预先假定后续 Cargo 已消除这条路径。