最快获取AST的方式是clang::tooling::buildASTFromCodeWithArgs，但需显式传入语言标准（如"-std=c++17"）和系统头路径（如"-I/usr/include/c++/11"），否则无法识别现代C++特性及标准库类型。
直接用 clang::tooling::buildASTFromCodeWithArgs 是最快拿到 AST 的方式，但必须传对编译参数，否则连 auto 或 std::vector 都解析不出来——这不是代码写错了，是 Clang 根本没启用对应语言标准。
用 buildASTFromCodeWithArgs 快速构建单 TU 的 AST
这是调试 AST 结构最轻量的入口，适合验证函数签名、类成员、表达式节点类型等。它不读磁盘文件，只处理内存中的一段字符串，省去编译数据库和路径配置。
- 必须显式传入语言标准，比如
{"-std=c++17"}，缺了就识别不了范围 for、结构化绑定、std::optional等 - 如果代码里用了系统头（如
<vector></vector>），得补上 include 路径，例如{"-std=c++17", "-I/usr/include/c++/11"}，否则std::vector会被当作未定义标识符 - 返回的是
std::unique_ptr<:astunit></:astunit>，要从中取 AST 上下文，必须调用getASTContext()，不能直接访问内部指针 -
ASTUnit析构后，其持有的ASTContext*和所有 Decl/Stmt 指针全部失效；若需长期持有节点，得用clang::ast_type_traits::DynTypedNode包装或提前拷贝关键信息
为什么 RecursiveASTVisitor::VisitFunctionDecl 不触发
不是 visitor 写得不对，而是 Clang 的 AST 只包含**完成语义分析**的 Decl。语法错误、缺失头文件、模板未实例化，都会导致对应节点根本不在 AST 中。
- 检查函数是否是定义而非声明：
D->isThisDeclarationADefinition()返回false时，D->getBody()一定为nullptr，但VisitFunctionDecl仍会被调用 - 模板成员函数（如
template<typename t> void foo() {}</typename>）默认只生成FunctionTemplateDecl，不会展开成具体CXXMethodDecl；需在源码中显式实例化（如template void MyClass::foo<int>();</int>）才能出现在 AST 中 - 若用
runToolOnCode，它默认不走完整的 Sema 流程，某些依赖上下文的推导（如auto x = func();的返回类型）可能失败，此时整个函数体可能被跳过
用 libclang C API 做轻量解析（不依赖 LLVM 构建）
如果你只需要遍历符号、提取类名/函数名/字段，不想链接整个 Clang 工具链，libclang 是更松耦合的选择。它通过 C 接口暴露核心能力，二进制兼容性好，VS Code 的 clangd 就基于它。
立即学习“C++免费学习笔记（深入）”；
-
clang_parseTranslationUnit返回CXTranslationUnit，必须配clang_defaultEditingTranslationUnitOptions或至少加CXTranslationUnit_DetailedPreprocessingRecord才能获取宏和注释信息 - 头文件路径必须通过
options数组传入，例如const char* args[] = {"-I./include", "-std=c++17"};，空指针或错位会导致nullptr返回 -
CXCursor是游标而非节点指针，每次遍历都需重新clang_getCursorLocation获取位置，不能缓存跨回调使用 - 它不支持修改 AST，仅用于只读分析；想做代码注入或重写，必须切回
libTooling+ASTFrontendAction
最容易被忽略的是：AST 节点生命周期完全绑定在 ASTContext 实例上，而后者又依附于 ASTUnit 或 TranslationUnit。一旦这些容器析构，所有指针立刻悬空——哪怕只是多写了一行 std::cout getNameAsString(); 在 visitor 外面，也可能 crash。
