Cargo nightly update 把刚锁定的修补版降回去了

刚把某个依赖精确更新到需要的修补版，下一次自动维护执行普通 cargo update，它又降回较旧版本。若项目设置了 registry.global-min-publish-age，先比较两次命令的策略与完整 Cargo.lock 差异。

例如，项目要求发布满一个月才采用新候选，临时审定的修补版只有几小时。一次显式允许较新候选的更新可以把它写入锁文件，但后续不带同一策略的普通 update 可能再次按年龄筛选并降版。Cargo 1.101.0-nightly 的已确认环境出现过这一过程。

锁定构建和重新选择版本不同

cargo build --locked 要求不改变锁文件；cargo update 则主动重新解析并改写版本。不能用一次锁定构建成功，推断下一次全量更新会保留同一个包。

在上述 nightly 环境中，即使先把新版本写入锁文件，普通 update 仍会将它降回满龄的旧候选。不能把既有锁定值的例外扩大理解为“普通更新永不降版”；更换工具链后，仍须用实际锁文件差异确认这个边界。

先保存降版前后的锁文件，确认目标包及传递依赖是否真的变化，检查是不是另外的 SemVer、来源替换或 yanked 条件导致选择改变。年龄配置从 Cargo 1.100 起受支持，旧工具链的不同表现也需要单独识别。

保留例外的审核边界

确实批准采用一个尚未满龄的版本时，可以把例外限定到受控更新命令，并在提交前审查整个锁文件。下面是命令形状，包名和版本必须替换为项目已审定的目标：

CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow cargo update -p PACKAGE --precise VERSION

这个环境变量影响此次依赖解析，不承诺只允许目标包而不影响它的依赖。因此需要检查所有连带变化，不能直接把它永久写进全局配置或所有 CI 任务。

若目标是项目可控制的直接依赖，精确版本要求可以表达“不接受旧候选”的约束，但也可能使后续解析失败；它不是无副作用的锁文件保护。传递依赖不能靠给所有包加直接依赖来强行固定，应按实际依赖图处理。

让自动维护发现回退

为依赖维护任务保留工具链版本和有效年龄策略，在更新结果中检查已批准的最低版本或已知修补要求。检测到降版时停止提交，不能因为 cargo update 退出零就让自动任务覆盖原来的修补选择。

复查时覆盖精确更新后的锁定构建，以及下一次真实自动维护命令。确认目标缺陷的修补仍在、未引入额外未审候选，再执行项目既有测试。若暂时不能安全表达这项例外，应保留锁文件并暂停该更新提交，而不是静默放宽全部依赖的年龄限制。