rust-analyzer 的 on-save check 默认调用 rustc，仅当配置 "rust-analyzer.checkonsave.command": "clippy" 时才触发 cargo clippy；二者诊断独立，clippy 不影响调试执行。
Clippy 的检查结果默认不阻断 cargo run 或调试执行，但 VS Code 中若配置不当，容易误以为“检查失败=无法运行”，其实二者完全独立——关键在于区分 rust-analyzer 的实时诊断和 cargo clippy 的显式检查触发点。
rust-analyzer 的 on-save check 是 Clippy 还是 rustc？
VS Code 默认用 rust-analyzer 提供的语义诊断（比如类型错误、借用冲突），它底层调用的是 rustc 的编译器前端，不是 clippy。只有你显式配置了 "rust-analyzer.checkOnSave.command": "clippy"，保存时才真正跑 cargo clippy。
- 没配这个字段时，编辑器里看到的波浪线全是
rustc报的，跟 Clippy 无关 - 配了之后，保存会触发完整
cargo clippy扫描，耗时明显变长，尤其项目大时 -
rust-analyzer自身不执行--fix，所以即使 Clippy 能自动修复的 lint，保存时也不会改代码
cargo clippy --fix 和 VS Code 的 “Quick Fix” 冲突吗？
不冲突，但行为不同：VS Code 的 Quick Fix（Ctrl+.）只响应 rust-analyzer 报出的、它自己支持修复的问题（如补全 impl、加 use）；而 cargo clippy --fix 是独立命令，只修 Clippy 明确标记为可自动修复的 lint（例如 clippy::redundant_clone）。
- 想让 Quick Fix 生效，得确保
rust-analyzer启用了对应能力："rust-analyzer.cargo.loadOutDirsFromCheck": true -
cargo clippy --fix必须手动运行，且要求工作区干净（或加--allow-dirty） - 两者修复范围无重叠——
rust-analyzer不会修clippy::too_many_arguments这类问题，Clippy 也不会修E0425（未定义变量）
调试时如何跳过 Clippy 检查干扰？
Clippy 检查本身不影响 cargo run 或调试器启动，但如果你在 launch.json 里错误地把 preLaunchTask 设为 clippy，就会卡住调试流程。
- 标准 Rust 调试任务（如
lldb或gdb）不依赖 Clippy，删掉preLaunchTask里任何含clippy的条目即可 - 如果想“调试前先过一遍 Clippy”，应单独建一个 task（比如叫
check-and-debug），而不是塞进 launch 配置 - 注意
cargo clippy默认不检查测试代码，要测#[cfg(test)]块得加--tests，否则调试 test 函数时可能漏报
真正容易被忽略的是：Clippy 的 lint 级别（allow/warn/deny）在 clippy.toml 和 Cargo.toml 里可以混用，但 VS Code 只读 clippy.toml 里的设置；而 CI 里用 cargo clippy -- -D warnings 会覆盖所有配置——本地和线上行为不一致，往往是静默失效的根源。
