要用go/ast提取单行注释，需启用parser.ParseComments模式获取ast.File.Comments，遍历ast.CommentGroup.List中的*ast.Comment，用fileset.Position(c.Pos()).Line获取行号，并用strings.TrimPrefix清理"//"前缀。
怎么用 go/ast 提取单行注释（//）
Go 的 AST 不会把 // 注释当作节点挂到语法树上，默认直接丢弃。想拿到它们，得在遍历 AST 时同步读取源码文本，靠位置信息对齐。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
parser.ParseFile解析时传入parser.ParseComments模式，否则*ast.File.Comments是空的 -
*ast.File.Comments是一个[]*ast.CommentGroup，每个CommentGroup包含连续的注释（可能跨行），需遍历其List字段取*ast.Comment -
*ast.Comment.Text带换行和前缀（如// hello），要用strings.TrimPrefix(c.Text, "//")或正则清理 - 别依赖
Comment.Pos()直接转行号——得用fileset.Position(c.Pos()).Line才准
为什么 /* */ 块注释比 // 更难定位到具体函数
块注释在 AST 中虽被保留，但不绑定到任何节点；它只是按出现顺序堆在 *ast.File.Comments 里。你无法直接知道某段 /* ... */ 是写在函数声明前、后，还是嵌在函数体中间。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 手动计算注释位置与最近的
*ast.FuncDecl节点位置关系：比较comment.Pos()和funcDecl.Doc.Pos()（如果有Doc）、funcDecl.Pos()、funcDecl.Body.Lbrace - 若注释紧贴函数声明上方且无空行，大概率是函数文档注释；但 Go 不强制，得结合间距判断（需读原始字节切片算换行数）
- 别用
funcDecl.Doc.Text()反推——那是 AST 已解析出的文档注释，只包含显式绑定的/* */或//，不覆盖所有块注释
提取注释时容易漏掉的三种边界情况
不是所有注释都“规整”。真实代码里常有干扰项，硬套模板会丢数据。
常见错误现象：
- 结构体字段后的
// +build这类构建标签，被当成普通注释提取，但实际是编译指令 - 函数参数列表里的内联注释：
func f(x int // not a real comment—— 这种未闭合的/*会让 parser 报错或跳过后续内容 - 字符串字面量里的伪注释：
s := "a // b"，go/ast不会误判，但你自己用正则预处理时可能中招
应对方式：始终以 go/ast 解析结果为准，别在源码字符串上做全文搜索。
性能关键点：别反复调用 parser.ParseFile
每次调用 parser.ParseFile 都会重读文件、重建 *token.FileSet、重新扫描词法，开销不小。批量处理多个文件时很容易成为瓶颈。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 复用同一个
*token.FileSet实例，传给所有ParseFile调用 - 用
parser.ParseDir一次性解析整个目录，返回map[string]*ast.Package，再逐个包遍历 - 如果只需注释不关心 AST 结构，考虑用
go/scanner手动扫 token —— 它更快更轻，但要自己维护位置和上下文
注释位置和 AST 节点之间的映射没有标准规则，不同编辑器、格式化工具插入的空行数量会影响判断逻辑，这点在跨项目分析时特别容易翻车。
