[!info] related notes

• 所属 MOC：测试与质量 · 工具链 · 学习路线
• 前置概念：Rustup、Cargo
• 后续概念：测试
• 容易混淆：测试

Rust Clippy 与 rustfmt

这个概念为什么出现

风格争论与低级踩坑会吞噬时间。
rustfmt 独裁格式；clippy 提供比 rustc 更积极的建议。

[!abstract] 一句话理解 cargo fmt 统一格式；cargo clippy 跑额外静态检查；二者应成为提交前与 CI 的默认门禁。

最小可运行示例

场景：PR 门禁命令

# 业务意图：本地复现 CI 质量检查。
# 教学点：组件安装与命令。

rustup component add rustfmt clippy
cargo fmt --all -- --check
cargo clippy --workspace --all-targets -- -D warnings
cargo test --workspace

在已有项目中运行；—check 只检查不改写。这里使用默认 feature 集；互斥 feature 不能机械 —all-features，应按实际支持的组合分别执行 Clippy 和测试。—all-targets 指当前平台的 bin/lib/test/example/bench 等构建目标，不等于全部操作系统与架构，也不能代替 doctest。

结合场景再看三个关注点

1. 格式与 lint 分离
2. -D warnings 把已启用的警告当错误（团队可选）；不会因此启用所有 Clippy lint，更不证明业务正确
3. allow/deny 属性可局部调整

核心概念与准确模型

• rustfmt 有统一默认风格，可通过 rustfmt.toml 配置；部分选项只在 nightly 可用，CI 应固定工具链
• clippy：lint 分组（correctness/style/perf…）
• 属性：#[allow(clippy::...)] 需理由

设计动机

• 减少风格噪音
• 捕获常见 API 误用
• 新人更快融入

边界与误区

• 盲目 allow 全部
• 旧代码一次 clippy 爆炸 → 分批
• 生成代码排除策略

[!warning] 常见误区：fmt 与业务提交混成难读 diff 单独提交格式化。

工程实践

1. pre-commit 或 CI 强制
2. workspace 统一
3. 新 lint 升级时预算修复
4. 文档说明允许的例外

本节总结

• fmt 管形，clippy 管味
• 工具链一等公民
• CI 固化

自测题

1. cargo fmt -- --check 用途？
2. 为何不建议全局 allow clippy？

参考答案

1. CI 验证已格式化。
2. 失去静态检查价值。

延伸阅读与资料来源

资料	类型	支撑内容
rustfmt	官方	格式化
Clippy	官方	lint
rustup components	官方	组件