为何clangd集成的clang-tidy比独立(run-)clang-tidy快这么多？

1. 增量处理与缓存机制 #

clangd会持续维护整个项目的编译数据库缓存，包括已解析的头文件、AST节点、符号信息等。当编辑单个文件时，它只会重新解析修改的部分，而不是像单独运行clang-tidy那样，每次都从头开始解析所有依赖的头文件（哪怕这些头文件根本没变化）。大型项目的头文件往往层层依赖，单独运行时重复解析的开销占了绝大多数时间。

2. 默认规则集的差异 #

确实，clangd默认会禁用部分高开销的clang-tidy规则，比如：

• misc-no-recursion：需要遍历整个调用链，开销极大
• cppcoreguidelines-no-malloc：需要跟踪内存分配的完整路径
• performance-unnecessary-copy-initialization：在大型代码库中分析对象拷贝场景会非常耗时
• 部分涉及跨文件分析的规则（如bugprone-cross-container-move）

你可以查看项目根目录的.clangd配置文件确认：默认情况下，clangd会使用类似clang-tidy -checks=clang-diagnostic-*,clang-analyzer-*,modernize-*,performance-*,-performance-unnecessary-copy-initialization的规则集，主动排除了高耗时检查项。

3. 分析范围的限制 #

clangd的clang-tidy检查仅针对当前编辑的文件及直接关联的少量代码，不会进行全局跨文件的深度分析。而单独运行clang-tidy时，默认会对整个翻译单元（包括所有依赖头文件的内容）进行全面检查，甚至可通过-header-filter等参数扩展分析范围，这自然会大幅增加耗时。

4. 针对性的性能优化 #

clangd为适配IDE实时响应需求，做了大量优化：

• 延迟分析：仅在光标停留或文件保存时，对当前关注的代码段进行检查，而非一次性分析整个文件
• 多线程并行：后台异步解析和分析，不阻塞UI；而单独运行clang-tidy默认多为单线程（需手动指定-j参数开启并行）
• 内存复用：持续驻留内存，复用已解析的AST和符号数据，避免重复加载解析的开销

准确性的权衡 #

clangd并没有牺牲核心准确性，只是在分析深度和范围上做了取舍：

• 针对当前文件的本地检查（如语法错误、简单代码风格问题），结果和单独clang-tidy完全一致
• 禁用的高开销规则本身误报率较高，clangd默认关闭是合理的性能-准确性平衡
• 若需要完整检查结果，可在.clangd中手动开启所有规则，或触发clangd的"重新检查整个文件"操作（此时耗时会接近单独运行clang-tidy，但仍会利用缓存加速）

内容的提问来源于stack exchange，提问作者pJunger