用ast而非正则统计函数定义，因正则会误匹配注释、字符串和变量名；ast解析器只识别真实可编译的函数声明，需过滤方法（recv==nil）和非法节点（params!=nil），并排除测试/生成文件及重复初始化fileset。
为什么用 ast 而不是正则统计函数定义
因为正则会把注释里的 func、字符串里的 "func main()" 甚至变量名 funcName 全部误判。而 ast.ParseFile 是 Go 官方语法解析器，只识别真实、可编译的函数声明节点，结果可靠。如果你只是想数 func 关键字出现次数，那用 strings.Count 更快——但那不是「代码统计」，只是文本统计。
ast.Inspect 遍历时如何准确识别函数声明
关键不是找 ast.FuncDecl 类型节点，而是要过滤掉方法（receiver 不为 nil）和接口中的方法签名。真实函数定义必须满足：node.Type.Params != nil（排除没有参数列表的非法节点），且 node.Recv == nil（排除方法）。示例片段：
ast.Inspect(fset, node, func(n ast.Node) bool {
if fd, ok := n.(*ast.FuncDecl); ok && fd.Recv == nil && fd.Type.Params != nil {
count++
}
return true
})
注意：不要在 ast.File 层级直接断言 *ast.FuncDecl，它只出现在 file.Decls 中；ast.Inspect 会进入所有子节点，包括 ast.BlockStmt 里的闭包——那些是 *ast.FuncLit，不是函数定义，别混进来。
统计前必须处理 go:generate 和测试文件干扰
默认 ast.ParseFile 会读取所有 .go 文件，包括 _test.go 和含 //go:generate 的生成文件。它们可能包含大量模板函数或 mock 实现，拉高统计偏差。建议在遍历文件前加过滤：
- 跳过文件名含
_test.go或.gen.go的路径 - 用
build.Default.IsGoBuildable判断是否在当前构建 tag 下有效（比如跳过// +build ignore文件） - 若需统计测试逻辑，应单独跑一遍并显式传入
srcDir和build.Context{BuildTags: []string{"test"}}
性能瓶颈常出在 token.FileSet 重复初始化
每调用一次 ast.ParseFile 就新建一个 token.FileSet，内存占用随文件数线性增长。实际项目里几百个文件就可能吃掉几十 MB。正确做法是复用同一个 *token.FileSet：
fset := token.NewFileSet()
for _, filename := range files {
f, err := parser.ParseFile(fset, filename, nil, parser.ParseComments)
// ...
}
另外，如果只需要函数数量，不必保留整个 AST 树，parser.ParseFile 的第 3 个参数传 nil 即可跳过注释解析，提速约 15%–20%。真正难的是跨 package 的函数调用链统计——那得结合 types.Info，已经超出纯 ast 能力范围了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
