[!info] 关联笔记

• 所属 MOC：测试与质量 · 工具链 · 学习路线
• 前置概念：Rustup、Cargo
• 后续概念：测试、[[rust-static-analysis|（若有）]]
• 容易混淆：测试

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 --all-targets --all-features -- -D warnings
cargo test

在已有项目中运行；--check 只检查不改写。

结合场景再看三个关注点

1. 格式与 lint 分离
2. -D warnings 把警告当错误（团队可选）
3. allow/deny 属性可局部调整

核心概念与准确模型

• rustfmt：几乎无配置哲学（可有 rustfmt.toml）
• 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	官方	组件