Go go/types.Config 怎样定位资源未释放

先说结论：go/types.Config 本身不是文件、连接或 goroutine 这类需要调用 Close 的资源句柄。遇到“资源未释放”或内存持续上涨时，真正需要定位的通常是 Config.Check 产生的 types.Package、调用方传入的 types.Info、不断累积文件的 token.FileSet，以及自定义 Importer 或业务缓存。

官方资料：https://pkg.go.dev/go/types

排查思路是沿着一次类型检查的数据生命周期往回找：谁创建了输入，谁保存了检查结果，谁把结果放进了全局 map、队列或缓存。只要把这几个边界拆开，就能判断是“仍被业务需要”，还是“检查结束后仍被意外引用”。

先区分配置对象与检查产物

Config.Check 接收包路径、token.FileSet、AST 文件和可选的 types.Info，然后返回 *types.Package 与错误。Config 描述检查行为，不能把它当作拥有底层资源的管理器；检查结束后是否继续占用内存，取决于调用方是否继续持有这些输入、输出和缓存。

因此，第一步不要寻找不存在的 Config.Close()。先记录一次检查前后哪些对象被加入了长期容器，再用堆画像确认这些对象是否仍被引用。

为单次检查建立生命周期边界

如果分析器只需要输出诊断文本或少量摘要，就不要把完整的 Package、Info 和 AST 放进全局结构。可以把它们限制在一次函数调用内，让函数返回后由垃圾回收器自行回收。

package analyzer

import (
	"go/ast"
	"go/parser"
	"go/token"
	"go/types"
)

// checkSource 只返回调用方真正需要的摘要，避免把完整检查图交给长期缓存。
func checkSource(filename string, src []byte) (bool, error) {
	fset := token.NewFileSet()
	file, err := parser.ParseFile(fset, filename, src, 0)
	if err != nil {
		// 解析失败时不把半成品 AST 放到共享容器。
		return false, err
	}

	conf := types.Config{}
	pkg, err := conf.Check("example", fset, []*ast.File{file}, nil)
	if err != nil {
		// 只把成功与否传给上层；不要在这里保存 pkg 或 fset。
		return false, err
	}
	// 读取需要的结果后，让 pkg、file 和 fset 随函数作用域结束。
	return pkg.Complete(), nil
}

Check 的文件参数是 []*ast.File，所以示例显式导入了 go/ast。保留完整的类型边界很重要，排查时不要用“看起来能编译”的伪修复掩盖引用关系。

如果业务必须保留结果，建议只保存文件名、行列号、对象名称或序列化后的诊断数据。完整的 Info 会把标识符、对象和类型关系串起来；保存它的一个指针，可能比保存一条错误字符串多出一整张对象图。

用堆画像识别持续增长的引用

当每次分析任务都创建局部变量，但内存仍持续增长时，重点看 in-use_space 与 in-use_objects 的变化，并比较两次采样中的类型名。目标不是证明某个函数“泄漏”，而是找到仍在被谁引用的对象。

import (
	"net/http"
	_ "net/http/pprof"
)

// startDebugServer 只用于受控诊断环境，生产环境应限制监听地址与访问权限。
func startDebugServer() {
	go func() {
		// pprof 的 heap 入口用于观察当前仍在使用的堆对象。
		_ = http.ListenAndServe("127.0.0.1:6060", nil)
	}()
}

# 采集仍存活对象的堆画像，文件名按采样时点区分。
curl -o heap-before.pb.gz http://127.0.0.1:6060/debug/pprof/heap
# 完成一批分析任务后再次采样，用 in-use_space 看保留内存。
curl -o heap-after.pb.gz http://127.0.0.1:6060/debug/pprof/heap
# 只比较当前仍被引用的对象，不把累计分配误判成未释放。
go tool pprof -inuse_space heap-after.pb.gz

在 pprof 中优先关注名称包含 go/types、go/ast、go/token 的对象，再回到业务代码搜索谁保存了它们。若主要增长的是自定义 map 的节点，根因往往是业务缓存没有淘汰；若增长集中在导入包，则继续检查 Importer；若每个任务都让 FileSet 变大，则检查 FileSet 是否被跨任务复用。

分别检查 Importer、FileSet 和 Checker

自定义 Importer 是否有缓存上限

标准导入器或自定义导入器可能为了复用导入包而缓存结果。缓存本身不等于泄漏，但必须有清晰的 key、生命周期和淘汰策略。按文件路径、模块版本或租户维度分析时，不能把无限增长的业务标识直接当作永久缓存 key。

排查时记录缓存条目数、每个条目引用的 Package 数量，以及任务结束后条目是否仍可从缓存根对象到达。若只需要类型名称，不要把完整的 Package 图挂在结果对象上。

FileSet 是否跨任务不断累积

token.FileSet 负责把 token 位置映射到文件。一个分析任务使用一个 FileSet 最容易划清边界；如果为了复用而让所有任务共享同一实例，就要确认文件表的增长是否符合预期。尤其当诊断对象保留了 token.Pos 并同时保存 FileSet 时，位置就会间接把旧文件表留在内存中。

Checker 是否被错误地当成可重置对象

types.NewChecker 返回的 Checker 维护一次检查所需的状态，Checker.Files 支持把多个文件加入同一个包的检查过程。它不是通用的清理 API，也不适合在不同项目之间无限复用。需要隔离任务时，优先为任务创建新的 Checker，并在任务结果只保留摘要。

// analyzePackage 为一个独立包创建独立的状态边界。
func analyzePackage(files []*ast.File, fset *token.FileSet) error {
	conf := &types.Config{}
	pkg := types.NewPackage("example", "example")
	info := &types.Info{}
	checker := types.NewChecker(conf, fset, pkg, info)
	if err := checker.Files(files); err != nil {
		// 当前任务的错误交给调用方，避免把 checker 放入共享池。
		return err
	}
	// 使用必要字段生成摘要后，不再向外暴露 checker、pkg 或 info。
	return nil
}

按症状选择清理策略

可以把判断顺序记成一句话：先看 Config 是否只是配置，再沿 Check 的输入、产物和缓存根对象找持有者。如果对象仍然被业务使用，它不是“未释放”；如果任务已结束但仍从全局容器可达，才需要修复生命周期。

相关问题

go/types.Config 需要调用 Close 吗？

不需要。它是类型检查配置，不提供文件或连接式的 Close 语义。需要释放的是调用方不再使用的检查输入、结果和自定义缓存引用。

为什么函数返回了，Package 还没有回收？

函数返回只代表局部变量离开作用域；如果 Package、Info、FileSet 或其中的对象仍被全局 map、缓存、goroutine 闭包或诊断队列引用，垃圾回收器仍会把它们视为可达对象。

看到堆画像里有 go/types 就能确定是 Config 泄漏吗？

不能。堆画像只能告诉你哪些对象仍在使用中，不能单独证明根因。还要沿引用关系回到业务容器、Importer、FileSet 或 Checker 的持有位置，再决定缩短作用域或增加淘汰策略。