libtooling 不能直接自动修复，需手动构造 replacement 并调用 applyallreplacements；修复本质是源码文本替换，非 ast 修改，须精确计算字符范围、处理多文件依赖与头文件一致性。
LibTooling 能不能直接做自动修复
不能。LibTooling 本身只提供 AST 访问和编译过程控制能力，不内置“修复”逻辑——它让你看到 VarDecl、CallExpr、BinaryOperator，但不会告诉你“这里该加括号”或“这个空指针解引用要加判空”。自动修复必须由你基于语义分析后，调用 clang::tooling::Replacement 和 clang::tooling::applyAllReplacements 显式构造文本替换。
怎么让 LibTooling 修改源码而不是只打印 AST
关键在两步：先用 MatchFinder 定位问题节点，再用 clang::tooling::Replacement 描述怎么改。注意：Replacement 操作的是源码字符区间（SourceLocation + 长度），不是 AST 节点本身。常见错误是直接修改 AST 节点（比如调用 setInit()）——这无效，Clang 不会反向同步到文件。
实操建议：
- 用
MatchFinder::addMatcher(..., &Handler)绑定一个继承自MatchCallback的处理器 - 在处理器的
run()里，从const MatchResult&提取SourceManager和LangOptions - 用
CharSourceRange::getTokenRange()或getSourceRange()获取可安全替换的字符范围 - 构造
Replacement时，确保FilePath与SourceManager.getFilename()一致，否则applyAllReplacements()会跳过 - 所有替换必须收集到
std::vector<replacement></replacement>，最后传给applyAllReplacements()
为什么修复后代码编译失败或格式错乱
根本原因是：LibTooling 的替换是纯文本操作，不感知缩进、换行、宏展开或模板上下文。例如，把 if (x) y(); 改成 if (x) { y(); } 时，若原代码是多行或含注释，直接插 { 和 } 极易破坏格式甚至语法。
规避方法：
- 优先使用
clang::Lexer::getLocForEndOfToken()精确计算插入位置，避免跨 token 替换 - 对需要补大括号、分号等结构符的场景，用
clang::tooling::fixit::createInsertion()辅助生成更鲁棒的Replacement - 永远在
runToolOnCode()单元测试中验证修复后代码能否被 Clang 成功 parse（用clang::ast_matchers::match再跑一次检查结构是否符合预期） - 不要试图修复宏定义体内或预处理条件分支中的代码——
SourceManager对这些区域的FileID可能为无效值
实际重构项目里最常被忽略的环节
AST 匹配器写得再准，如果没有处理好头文件依赖和多翻译单元一致性，修复就会漏改或误改。比如修复 std::make_shared<t>(args...)</t> 为 std::make_shared<t>(std::forward<args>(args)...)</args></t>，若 T 在头文件中定义而主文件未显式包含，QualType::getAsString() 可能返回空或乱码；又比如同一符号在多个 .cpp 中被不同方式调用，替换逻辑必须统一应用，否则链接时报 undefined reference。
这意味着你必须：
- 在
ClangTool构造时传入完整CompilationDatabase，不能只喂单个文件 - 用
SourceManager::isInMainFile()过滤掉头文件中的匹配结果（除非你明确要修头文件） - 对跨文件影响的修复（如改函数签名），需额外维护符号映射表，并在所有引用处批量触发替换
没做这几步，工具看起来能跑，但上线后大概率修坏真实项目。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
