Cargo 提示 patch 未使用：预发布版本没有满足传递依赖

Cargo.lock 出现 [[patch.unused]]，构建日志同时编译 foo 1.0.0 和 foo 1.0.0-patch.1。即使直接依赖用了修补版，也不能据此认为传递依赖已经切换。先检查每条依赖的版本要求，而不只是确认工作区根清单里有 [patch]。

例如，某个依赖要求 foo = "1.0"，本地修补副本却把版本改成 1.0.0-patch.1。普通的 1.0 或 ^1.0 要求默认不接收预发布版本。[patch] 把另一份源码加入指定来源的候选集合，并不会跳过这层匹配。SemVer 的版本先后顺序，也不能代替 Cargo 的版本需求规则。

把来源替换与版本选择一起核对

先看根工作区的 [patch] 指向哪个来源，再逐项核对修补副本的包名、版本，以及 Cargo.lock 实际选中的版本和来源。依赖包自己声明的 [patch] 不会自动成为整个应用的覆盖规则。

若上游仍要求稳定版范围，可以让经审查的本地修补副本保留满足这些要求的版本，再通过根工作区的来源替换使用它。例如下面只演示 crates.io 来源的局部配置：

[patch.crates-io]
foo = { path = "../reviewed-foo" }

这里的 reviewed-foo 必须是实际存在、已审查的包目录；其 Cargo.toml 包名仍为 foo，版本也必须满足依赖图要求。不要把同名版本号误当成内容完全相同的证明。修补副本的提交、内容差异和来源应在项目自己的依赖审计中留存，也不要把它冒充上游正式发布物。

确实需要使用预发布版本时，需要相关依赖要求明确允许它。只修改应用的直接依赖，不会重写第三方包内部的稳定版要求。若无法控制这些要求，就不能靠加一条 [patch] 承诺全部切换；应选择兼容的修补交付方式，或协调依赖方调整。

用依赖图确认没有留下另一条旧路径

修改前保存清单和锁文件。在正常开发环境查看：

cargo tree -d

它用于查看重复版本，不会替你判断哪个版本包含所需改动。需要更新锁文件时限定到目标包，审查版本与来源差异，避免把全部依赖顺带升级。cargo update 不能强迫一个不匹配的预发布版本满足稳定版要求。

验收应同时确认：目标补丁不再被列为未使用，相关传递路径确实指向审定的包来源，没有另一份原版本仍被编译；然后执行项目既有构建与行为检查。仅看到修补副本编译成功，或警告消失，都不足以证明所有调用路径已切换。