CSharpSyntaxTree.ParseText 是生成 AST 最轻量可控的方式，适合代码检查等场景；需防 null 字符串、编码乱码、HasErrors 未检查等错误，大文件应复用实例或改用 ParseFile。
用 CSharpSyntaxTree.ParseText 解析源码字符串最直接
直接拿字符串喂给编译器 API，是生成 AST 最轻量、最可控的方式。它不依赖项目文件或引用，适合做代码检查、模板生成、简单重构等场景。
常见错误现象：NullReferenceException 或解析后 Root 是空节点——通常因为传入了 null 字符串，或没检查 tree.GetRoot() 是否成功返回非空结果。
- 必须确保字符串编码为 UTF-8（或显式指定
Encoding.UTF8），否则中文注释或标识符可能乱码，导致解析失败 - 若需语义分析（比如知道某个变量类型），仅靠
ParseText不够，得配合CSharpCompilation构建语法+语义树 - 不推荐对大文件（>1MB）直接用此方式反复调用，内存分配频繁；可复用
SyntaxTree实例或改用ParseFile
示例：
var tree = CSharpSyntaxTree.ParseText("class A { void M() {} }");<br>var root = tree.GetRoot();
ParseFile 读取磁盘文件时要注意路径和编码
当处理真实 .cs 文件时，ParseFile 比先读文件再调 ParseText 更稳妥——它自动识别 BOM 并选择正确编码，避免手动读取时因编码错位导致语法错误。
使用场景：批量扫描解决方案中的 .cs 文件、CI 环境下做静态分析。
- 路径必须是绝对路径，相对路径会按当前工作目录解析，容易出错；建议用
Path.GetFullPath标准化 - 若文件含不支持的 C# 版本特性（如 records 在 C# 9 以下），解析会失败并抛
SyntaxNodeOrToken相关异常，需捕获ArgumentException或检查tree.HasErrors - Windows 上路径分隔符用反斜杠没问题，但跨平台工具中建议统一用
Path.Combine
AST 节点遍历别硬写递归，优先用 SyntaxWalker
拿到 SyntaxNode 后想查所有 MethodDeclarationSyntax，手写深度优先遍历容易漏子节点、忽略语法树特殊结构（比如 ArgumentList 下还有嵌套表达式）。
性能影响：自定义递归可能重复访问同一节点，而 SyntaxWalker 内部做了优化，且支持跳过子树（VisitChildren 返回 false）。
- 继承
CSharpSyntaxWalker，重写对应VisitXxx方法（如VisitMethodDeclaration），比用DescendantNodes().OfType<t>()</t>更高效也更安全 - 不要在
Visit方法里修改节点（如替换 IdentifierName），AST 是不可变的；需用SyntaxRewriter配合ReplaceNode - 若只需找一类节点，
root.DescendantNodes().OfType<invocationexpressionsyntax>()</invocationexpressionsyntax>可快速验证逻辑，但生产环境建议换成 Walker
生成 AST 后没报错 ≠ 代码合法，tree.HasErrors 必须检查
Roslyn 的解析器默认容忍部分错误（比如少个右括号），仍会生成“尽力而为”的语法树，但此时 Root 可能含 SkippedTokensTrivia 或 BadDirectiveTrivia，后续遍历可能行为异常。
容易踩的坑：只判断 tree != null 就继续处理，结果在 VisitIdentifierName 里遇到 null 或意外类型。
- 务必在获取
Root后立即检查tree.HasErrors，有错误时记录tree.GetDiagnostics()中的具体Diagnostic -
HasErrors不包含语义错误（如未定义变量），只反映语法层问题；语义错误要等编译后从compilation.GetDiagnostics()拿 - 某些编辑器插件会传入不完整代码片段（如用户正在输入中），此时
HasErrors为true是正常现象，需设计容错逻辑
真正难的是把 AST 和语义绑定起来——光有树不知道 List<int></int> 是哪个程序集里的 List，那得喂进编译器上下文。这事不提编译单元、不设好 MetadataReference，就永远卡在语法层。
