Go 类型分析工具怎样缓存只读 MethodSet 供多次查询

在 Go 类型分析工具里，如果同一种类型需要被多个规则反复检查，直接每次调用 types.NewMethodSet 会把构造工作重复做一遍。更合适的方式是：在一次分析会话内为类型建立稳定键，只构造一个 *types.MethodSet，随后让多个查询共享它。MethodSet 的 Len、At 和 Lookup 都是读取入口，适合放在只读缓存中。

官方文档：https://pkg.go.dev/go/types#MethodSet

缓存的重点不是把 MethodSet 序列化，而是缩短同一类型在同一分析上下文中的重复构造路径。缓存键要绑定当前类型对象和分析会话，缓存值只读共享，失效时随会话一起丢弃。

先分清构造和查询

types.NewMethodSet(T) 返回给定类型的完整方法集合，即使集合为空也会返回非 nil 的 MethodSet。拿到集合后，Len 读取数量，At 按稳定顺序取出选择结果，Lookup 按包和方法名查找匹配项。

因此缓存层可以把重复的“从 Type 计算集合”放在 miss 分支，把轻量的读取操作留给每个规则。MethodSet 内部不是给调用方编辑的容器，调用方不应尝试修改它，也不应把其中的 Selection 复制成另一套状态。

用分析会话内的类型身份做缓存键

类型分析工具通常已经持有 types.Type。最简单的缓存键可以使用接口值本身：在同一次类型检查会话中，类型对象通常由同一套检查结果产生，接口值可直接作为 map 键。不要只用 Type.String() 作为全局键，因为同名类型可能来自不同包，字符串也不适合作为跨会话身份。

package methodcache

import "go/types"

// MethodSetCache 只在一个 types.Package 分析会话内使用。
// Type 作为键，避免把不同包或不同会话的同名类型误合并。
type MethodSetCache struct {
	sets map[types.Type]*types.MethodSet
}

// New 创建一个空缓存；缓存不跨 Checker 或分析任务复用。
func New() *MethodSetCache {
	return &MethodSetCache{sets: make(map[types.Type]*types.MethodSet)}
}

// Get 返回类型对应的只读 MethodSet，首次访问时才构造。
func (c *MethodSetCache) Get(t types.Type) *types.MethodSet {
	// nil 类型通常意味着上游解析失败，调用方应先处理错误。
	if t == nil {
		return nil
	}
	if set, ok := c.sets[t]; ok {
		return set
	}

	// NewMethodSet 的结果只通过 Len、At、Lookup 读取，不向外暴露可变容器。
	set := types.NewMethodSet(t)
	c.sets[t] = set
	return set
}

这个版本适合单线程遍历 AST 或类型对象。如果多个规则并发调用 Get，普通 map 既会发生数据竞争，也可能在同一时刻重复构造。并发版本要把 map 访问和 miss 合并保护起来。

并发场景下合并 cache miss

读多写少的缓存可以用读写锁：先用读锁命中，miss 后释放读锁，再用写锁二次检查。二次检查很重要，因为另一个 goroutine 可能已经在等待写锁期间完成构造。

package methodcache

import (
	"go/types"
	"sync"
)

// ConcurrentCache 让同一分析会话内的 MethodSet 可以被多个规则读取。
type ConcurrentCache struct {
	mu   sync.RWMutex
	sets map[types.Type]*types.MethodSet
}

// Get 通过读锁快速命中，并在写锁阶段再次确认 miss。
func (c *ConcurrentCache) Get(t types.Type) *types.MethodSet {
	if t == nil {
		return nil
	}

	c.mu.RLock()
	set := c.sets[t]
	c.mu.RUnlock()
	if set != nil {
		return set
	}

	c.mu.Lock()
	defer c.mu.Unlock() // 保证写入完成后释放锁，避免读者看到半成品。
	if set = c.sets[t]; set != nil {
		return set
	}
	set = types.NewMethodSet(t)
	c.sets[t] = set
	return set
}

// NewConcurrent 创建已初始化的并发缓存。
func NewConcurrent() *ConcurrentCache {
	return &ConcurrentCache{sets: make(map[types.Type]*types.MethodSet)}
}

二次检查不能把构造过程放到读锁里，否则读操作会被长时间阻塞。它的职责是确保最终只保留一个结果；写锁内的第二次读取会让后到者直接复用已缓存的集合。

复用 MethodSet 的三个查询入口

缓存返回后，规则只做查询。按名称找方法时使用 Lookup；需要输出完整方法列表时遍历 At；只关心是否存在方法时先检查 Len 或直接判断 Lookup 的结果。

// describeMethod 展示只读查询，不修改 MethodSet 内部状态。
func describeMethod(set *types.MethodSet, pkg *types.Package, name string) string {
	if set == nil {
		return "类型不可用"
	}
	if set.Len() == 0 {
		return "没有可见方法"
	}
	if sel := set.Lookup(pkg, name); sel != nil {
		// Selection.String 只用于展示；业务逻辑应保留 Selection 本身。
		return sel.String()
	}
	return "未找到指定方法"
}

需要注意，Lookup 的匹配包含包和名称；仅凭方法名判断可能把不同包的同名方法混在一起。若工具要生成诊断结果，建议把包路径、方法名和选择对象一起传入后续格式化函数。

指针类型、接口和生命周期不能忽略

NewMethodSet 遵循 Go 的方法集规则。命名指针类型不能声明方法，因此对应结果可能为空；指向接口的指针也没有方法集。工具应把这些情况当作类型语义，而不是把“空集合”误判成缓存失效。

另外，接口类型需要在适合的时机完成。官方实现明确提示，外部调用 NewMethodSet 时应确保接口已经 complete。若分析流程还在填充类型信息，不要提前把未完成状态放入长期缓存。

最后，缓存的生命周期应短于或等于类型检查会话。若重新创建 types.Config、types.Info 或加载另一套包图，就创建新的缓存；不要跨项目、跨版本或跨检查器复用旧的 MethodSet。

一张表记住落地边界

常见问题

MethodSet 可以跨多个 types.Checker 复用吗？

不建议。缓存键和方法对象都应属于同一分析上下文，跨 Checker 复用会让类型身份、包信息和诊断位置脱节。

只有一次 Lookup 还需要缓存吗？

通常不需要。缓存适合多个规则、多个遍历阶段或重复访问同一批类型；一次性查询应优先保持代码简单。

能用 Type.String 作为唯一键吗？

只能在你已经明确限定包图和会话的场景中谨慎使用。通用工具应保留类型对象身份，避免同名类型或不同会话发生碰撞。

总结：把 NewMethodSet 放到缓存 miss 路径，把 Len、At、Lookup 留给并发读者，并让缓存跟随当前类型检查会话生命周期，就能在不改变 go/types 语义的前提下减少重复构造。