因为Go源码有嵌套结构，正则无法可靠识别语法单元边界；go/ast能准确区分词法角色和语法位置，避免将注释、字符串字面量、变量名误统计，确保结构分析真实反映代码意图。
为什么用 go/ast 而不是正则或字符串扫描
因为 Go 源码有嵌套结构（比如函数里嵌套闭包、结构体字段含泛型约束），正则根本无法可靠识别语法单元边界。比如 type T struct{ f int } 里的 struct 是关键字，但 var s = "struct" 里的就不是；go/ast 能准确区分词法角色和语法位置，统计才真正反映代码结构意图。
实际踩坑点：直接读取 .go 文件后用 strings.Count 数 "func " 会把注释、字符串字面量、甚至变量名（如 funcName）全算进去，结果偏差可能超 30%。
如何构建 AST 并遍历统计函数/结构体/接口数量
核心是用 parser.ParseFile 解析单个文件，再用 ast.Inspect 深度优先遍历节点。注意必须传入 parser.Mode，否则注释不会被保留（影响后续行号统计）。
关键步骤：
立即学习“go语言免费学习笔记（深入）”；
- 用
token.NewFileSet()创建文件集，它是所有位置信息的坐标系基础 - 调用
parser.ParseFile(fset, filename, src, parser.ParseComments)，src可为nil（自动读文件）或传入字节切片 - 在
ast.Inspect回调中，用node.Type()判断节点类型，例如*ast.FuncDecl对应顶层函数声明 - 结构体和接口分别匹配
*ast.StructType和*ast.InterfaceType，注意它们只代表类型字面量，不是type X struct{}这种完整声明
示例片段（统计函数声明数）：
count := 0
ast.Inspect(file, func(n ast.Node) bool {
if _, ok := n.(*ast.FuncDecl); ok {
count++
}
return true
})
如何统计有效代码行数（排除空行、注释、大括号独占行）
go/ast 本身不提供行内容分析，需结合 fileSet.Position(n.Pos()).Line 获取节点起始行号，再配合源码字符串按行切分。但要注意：AST 节点的 Pos() 指向的是语法元素起始位置，比如 func f() {} 的 FuncDecl 节点 Pos() 指向 func 关键字所在行，而右大括号可能在另一行。
实操建议：
- 先用
os.ReadFile读取原始内容，bytes.Split按\n分割成行切片 - 对每一行，用
strings.TrimSpace后判断是否为空、是否以//开头、是否仅含{或}（注意处理{ //这类边界） - 不要依赖 AST 节点的
End()行号来“覆盖”整块区域——函数体内部的空行仍需单独判断
易错点：Go 允许换行在任意操作符后，return\n42 是合法的，但这种换行不应计入有效行——所以必须基于原始文本逐行判断，而非 AST 结构推导。
跨文件统计时如何避免重复解析和路径混乱
用 build.Default.ImportDir 或 packages.Load（推荐）加载整个包，比手动遍历 .go 文件更安全。后者能自动处理 //go:build 约束、忽略测试文件（除非显式包含 _test.go），且返回的 *packages.Package 中已预解析好所有 ast.File。
关键配置项：
-
packages.Config.Mode = packages.NeedSyntax | packages.NeedTypes，至少要NeedSyntax才有 AST -
packages.Load的patterns参数支持./...、myproj/cmd/...等，比filepath.Walk更符合 Go 工作区逻辑 - 每个
pkg.Syntax是[]*ast.File，需遍历每份文件，不能只取第一个
陷阱提醒：如果项目含 cgo 或非标准构建约束，packages.Load 可能静默跳过某些文件，此时应检查 pkg.Errors 切片是否有警告。
