Go parser.ParseDir 怎样按包名分组源码文件

想用 Go 一次读取一个目录里的源码文件，并按包名继续分析时，parser.ParseDir 返回的不是“目录对应一个 AST”，而是一个 map[string]*ast.Package。键来自每个文件的 package 声明，同一包名下的文件会被放进同一个 ast.Package。

官方资料：https://pkg.go.dev/go/parser#ParseDir

最小正确用法是准备非空的 token.FileSet，调用 ParseDir，遍历返回的包映射和 Files；不要把目录名、文件名或 build tags 当成分组依据。

ParseDir 返回值到底按什么分组

函数会读取指定目录，跳过子目录和非 .go 文件，然后逐个解析源码。解析成功后，它使用 AST 中的包名作为键：例如 user.go 和 admin.go 都声明 package account，就会合并到 pkgs["account"] 的 Files 中。

用 FileSet 和过滤器读取目标源码

fset 不能传 nil，因为解析出的节点要把偏移量映射回文件名和行列位置。filter 可以按 fs.FileInfo 排除测试文件、生成文件或不想纳入本轮分析的文件；它只影响是否把文件交给解析器，不会替你判断构建标签。

package main

import (
	"fmt"
	"go/ast"
	"go/parser"
	"go/token"
	"io/fs"
	"log"
	"strings"
)

func main() {
	fset := token.NewFileSet()

	// 只保留非测试 Go 文件，避免把 *_test.go 混入包级 AST。
	filter := func(info fs.FileInfo) bool {
		return !strings.HasSuffix(info.Name(), "_test.go")
	}

	// 解析结果按源码里的 package 名称聚合，而不是按目录名称聚合。
	pkgs, err := parser.ParseDir(fset, "./internal/account", filter, 0)
	if err != nil {
		log.Printf("解析目录时出现错误: %v", err)
	}

	for packageName, pkg := range pkgs {
		fmt.Printf("包 %s 包含 %d 个文件\n", packageName, len(pkg.Files))
		for filename, file := range pkg.Files {
			// file.Name.Name 是 AST 中的包名，可用 FileSet 查询位置。
			pos := fset.Position(file.Package)
			fmt.Printf("  %s: %s:%d\n", filename, pos.Filename, pos.Line)
		}
	}

	_ = ast.File{} // 说明包级 AST 的文件元素类型是 *ast.File。
}

这里的 mode 会原样传给 ParseFile，可以根据需求组合 parser.ParseComments、parser.ImportsOnly 或其他解析模式。若只做导入统计，使用 ImportsOnly 可以减少不需要的 AST 内容，但返回的分组规则不变。

目录错误和解析错误要分开处理

目录本身无法读取时，返回的是 nil map 和对应错误；如果某个 Go 文件解析失败，函数可能返回一个非 nil 但不完整的 map，同时返回第一次遇到的错误。因此不能用“有错误就一定没有结果”来写统一分支。

func readPackages(path string) (map[string]*ast.Package, error) {
	fset := token.NewFileSet()

	// 让调用方拿到部分成功结果，同时保留首个错误供日志和决策使用。
	pkgs, err := parser.ParseDir(fset, path, nil, parser.ParseComments)
	if err != nil && pkgs == nil {
		// 目录读取失败时没有可继续分析的包。
		return nil, fmt.Errorf("读取源码目录 %q: %w", path, err)
	}
	if err != nil {
		// 解析失败可能只影响一个文件，先保留其他完整包供诊断。
		return pkgs, fmt.Errorf("源码存在解析错误: %w", err)
	}
	return pkgs, nil
}

生产代码可以把“继续分析部分结果”作为明确策略：静态索引器通常会记录错误后继续展示已解析的包；需要生成完整产物的任务则应把非空结果也视为失败，避免把残缺 AST 当作完整输入。

为什么 ParseDir 不适合替代构建上下文加载

官方文档明确提示，ParseDir 不考虑 build tags。也就是说，一个目录里的文件可能在不同 GOOS、GOARCH 或自定义标签下属于不同构建集合，但 ParseDir 仍按目录中可见的 .go 文件直接解析并按包名聚合。

如果任务只是做轻量 AST 扫描、导入统计或教学示例，ParseDir 仍然直观；如果需要精确表示“当前构建会包含哪些文件”、解析模块依赖，或进一步做类型检查，应考虑官方文档推荐的 golang.org/x/tools/go/packages。选择工具时要把“解析语法树”和“加载真实 Go 包”当成两个不同问题。

常见问题

为什么 map 里可能有多个包？因为同一目录可以出现多个 package 声明，ParseDir 会按声明名分别建立 ast.Package；是否符合项目构建规则，需要由更完整的加载逻辑判断。

filter 能过滤 build tags 吗？不能。它接收的是文件信息，只能基于文件名、大小、时间等元数据决定是否解析；它不会计算构建约束。

解析错误时应该立即丢弃 pkgs 吗？不一定。返回 map 非空时可以继续做诊断，但必须把结果标记为不完整；需要完整分析时应中止后续产物生成。

总结：ParseDir 的核心是“目录文件 → package 声明 → map[string]*ast.Package”。准备好 FileSet、正确理解过滤器和部分结果，再根据是否需要 build tags 选择下一层工具，就能避免把包名分组误当成完整构建分析。