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 的依赖没有使用”,所以只要依赖表仍可能被未参与本次检查的目标使用,就不会发出这条全局结论。

--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.toml 条目:
- 先确认工具链。用
rustc --version确认实际执行的是 Rust 1.100 或更高版本;旧工具链不会提供同样的 Cargo 提示。 - 扩大目标范围。单 package 优先使用
cargo check --all-targets;workspace 使用cargo check --workspace --all-targets,再按项目的 features 和 target 条件补充 CI 检查。 - 按依赖表分类。只对
[dependencies]、目标专属普通依赖或 workspace 继承的普通依赖期待这条提示;看到[dev-dependencies]没有提示属于已知边界。 - 结合代码和目标确认。一个依赖可能由 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 的依赖表、目标条件和源码使用点确认。
-
471 收藏
-
330 收藏
-
414 收藏
-
200 收藏
-
103 收藏
-
495 收藏
-
374 收藏
-
158 收藏
-
118 收藏
-
253 收藏
-
384 收藏
-
251 收藏
-
327 收藏
-
184 收藏
-
479 收藏
-
266 收藏
-
469 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 立即学习 543次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 立即学习 516次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 立即学习 500次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 立即学习 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 立即学习 485次学习