登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  科技周边 >  业界新闻

Cargo新增未使用依赖提示后为何检查单个bin看不到警告

来源:17golang原创

时间:2026-11-15 13:41:31 414浏览 收藏

如果你刚升级到 Rust 1.100,可能会遇到一个看似矛盾的现象:Cargo 已经新增了未使用依赖提示,但执行 cargo check --bin foo 时,Cargo.toml 里明显没有被 foo 使用的依赖却没有任何警告。这个结果通常不是提示失效,而是检查范围还没有覆盖依赖表可能服务的全部构建目标。

官方公告地址:https://blog.rust-lang.org/2026/11/12/Rust-1.100.0/

Rust 1.100 的 Cargo 未使用依赖提示,只有在相关依赖表的所有可能使用目标都被构建时才适合下结论。单独检查一个 bin 不能代表同一 package 的其它 bin、测试、示例或基准;dev-dependencies 则不会触发这条提示。

Rust 1.100 的提示到底检查什么

Rust 1.100 把 Cargo 的 unused dependencies 提示纳入新的 Cargo lint 系统,默认以 warn 级别报告。它解决的是一个长期存在的误判:rustc 能发现某个编译单元没有使用 crate,但 Cargo.toml 中的同一个依赖可能被另一个 bin 或其它目标使用,因此不能仅凭当前编译单元就把依赖判成多余。

因此,这条提示的判断单位更接近“依赖表和它覆盖的构建目标”,而不是“当前打开的一个源文件”。Rust 官方公告给出的例子正是多个 bin 共享 [dependencies]:一个 bin 不使用 tracing-subscriber,并不代表整个 package 都不使用它。

为什么检查单个 bin 看不到警告

当 package 里有 foo 和 admin 两个 bin,且 admin 使用了某个普通依赖时,下面的命令只选择了一个目标:

# 只检查 foo,不能代表同一 package 的其它 bin
cargo +1.100 check --bin foo

# 让 Cargo 把常见的库、bin、测试、基准和示例一起纳入检查
cargo +1.100 check --all-targets

第一条命令的输出没有提示,并不能推出依赖一定没问题。Cargo 需要避免把“foo 没有使用”误报成“package 的依赖没有使用”,所以只要依赖表仍可能被未参与本次检查的目标使用,就不会发出这条全局结论。

Cargo依赖表与多个bin和测试目标的覆盖关系说明图
图1:目标覆盖说明图,单个 bin 只是依赖表可能服务的一个入口,不是整个 package 的结论。

--all-targets 是更稳妥的起点。Cargo 官方命令文档说明它等价于同时选择库、所有 bin、测试、基准和示例;如果是 workspace,还要结合 --workspace 检查所有成员。它扩大了覆盖面,但不等于自动覆盖所有平台条件、特性组合和自定义构建入口,跨平台项目仍要按实际 CI 矩阵安排检查。

dev-dependencies 为什么不会触发这条提示

dev-dependencies 的用途与普通依赖不同。Cargo 官方文档把它定义为测试、示例和基准等开发目标的依赖,它们不会参与普通 package 构建,也不会传递给依赖当前 package 的其它包。

[dependencies]
# 普通构建目标可能共享这项依赖
tracing-subscriber = "0.3"

[dev-dependencies]
# 这项依赖只服务测试、示例或基准
assert_cmd = "2"

Rust 1.100 官方公告明确写出:Cargo 不会为未使用的 dev-dependencies 发出这条提示,因为 Cargo 没有办法保证所有开发构建目标都已经被构建。即使你运行了 cargo check --all-targets,也不应把“没有提示”理解成 Cargo 已经证明开发依赖被使用或未被使用。

Cargo普通依赖与开发依赖覆盖边界说明图
图2:依赖范围说明图,普通依赖和开发依赖对应不同构建目标,提示能力的边界也不同。

项目里应该怎样安排检查

可以按下面的顺序处理,而不是先看到空输出就删除 Cargo.toml 条目:

  1. 先确认工具链。用 rustc --version 确认实际执行的是 Rust 1.100 或更高版本;旧工具链不会提供同样的 Cargo 提示。
  2. 扩大目标范围。单 package 优先使用 cargo check --all-targets;workspace 使用 cargo check --workspace --all-targets,再按项目的 features 和 target 条件补充 CI 检查。
  3. 按依赖表分类。只对 [dependencies]、目标专属普通依赖或 workspace 继承的普通依赖期待这条提示;看到 [dev-dependencies] 没有提示属于已知边界。
  4. 结合代码和目标确认。一个依赖可能由 build script、平台条件、另一个 bin 或测试目标使用,清理前先查清它的实际入口,不要把一次命令的静默当成删除依据。

如果项目的 CI 已经分别检查库、bin、测试和示例,新增提示更适合作为依赖清理的线索:出现 warning 时再回到对应目标确认;没有 warning 时,只能说明当前覆盖范围内没有形成可报告的结论。

几个容易误解的场景

场景看到的结果应该怎样理解
只有一个 bin,执行 --bin name可能出现普通依赖警告目标集合简单,但仍要考虑平台条件和实际 manifest 配置。
多个 bin,只检查其中一个看不到共享依赖的警告其它 bin 仍可能使用该依赖,扩大目标范围后再判断。
依赖位于 [dev-dependencies]没有这条提示这是 Cargo 1.100 公告明确说明的能力边界。
workspace 只检查当前成员其它成员的依赖没有结论需要显式使用 --workspace 或在 CI 中逐成员覆盖。

总结

Cargo 的新提示不是对每一次单目标编译都给出“依赖是否多余”的即时答案,而是避免在目标覆盖不足时误报。检查单个 bin 看不到警告,最常见的原因是同一依赖还可能被另一个构建目标使用;dev-dependencies 不提示则是 Rust 1.100 已公开的限制。把检查范围、依赖表类型和 CI 目标矩阵放在一起看,才能决定是否真的需要清理依赖。

相关问题

cargo check 默认会检查所有 bin 吗?

在没有指定目标选择参数时,Cargo 会检查所选 package 的库和二进制目标;但测试、示例和基准等目标需要通过 --all-targets 纳入,workspace 成员则要看当前 package 选择范围。

没有 unused dependency 警告就能删依赖吗?

不能。没有警告可能只是当前构建目标或平台组合没有形成可报告结论,仍应结合 Cargo.toml 的依赖表、目标条件和源码使用点确认。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>