Go go/types.Hasher 怎么做类型键：Identical 与标签忽略的缓存一致性

做静态分析缓存时，最容易被忽略的不是哈希算法，而是“两个类型什么时候算同一个”。Go 1.27 在 go/types 中补上了 Hasher 和 HasherIgnoreTags，前者跟随 Identical，后者跟随 IdenticalIgnoreTags。选错一套规则，缓存命中率和结果正确性都会一起出问题。

一、先把类型缓存的等价关系说清楚

先看一个很小但很关键的差异：两个字段都叫 ID、类型也都是 int，只是标签不同。对静态分析器来说，标签可能影响 JSON 或数据库映射；对只关心字段布局的工具来说，它又可能只是附加信息。

id := types.NewVar(token.NoPos, nil, "ID", types.Typ[types.Int])
withJSON := types.NewStruct([]*types.Var{id}, []string{`json:"id"`})
withDB := types.NewStruct([]*types.Var{id}, []string{`db:"id"`})

strict := types.Hasher{}
loose := types.HasherIgnoreTags{}
fmt.Println(strict.Equal(withJSON, withDB)) // false
fmt.Println(loose.Equal(withJSON, withDB))  // true

这里的关键不是“哪个结果更好”，而是缓存的业务定义。编译器插件、类型检查结果和需要区分序列化协议的缓存，应使用 types.Hasher；只按字段形状复用分析结果时，才考虑 types.HasherIgnoreTags。两者不能交叉：用忽略标签的桶键，却用严格的 Identical 复查，会出现定位相同而命中判断失败的额外碰撞；反过来则可能把本不该复用的结果合并。

二、按同一规则生成桶键并复查碰撞

types.Hasher.Hash 不返回整数，而是把类型编码写入 maphash.Hash。应用层可以用一个进程内的 maphash.Seed 生成桶索引，再在桶中调用 Equal。下面的容器故意把“哈希定位”和“语义确认”拆开：

type typeEntry struct {
    typ   types.Type
    value any
}

func bucketOf(h types.Hasher, seed maphash.Seed, typ types.Type) uint64 {
    var mh maphash.Hash
    mh.SetSeed(seed)
    h.Hash(&mh, typ)
    return mh.Sum64()
}

func lookup(h types.Hasher, seed maphash.Seed, table map[uint64][]typeEntry, typ types.Type) (any, bool) {
    for _, item := range table[bucketOf(h, seed, typ)] {
        if h.Equal(item.typ, typ) {
            return item.value, true
        }
    }
    return nil, false
}

同一个 maphash.Seed 要覆盖这张缓存的所有键；零值哈希也能工作，但显式保存进程内 seed 更容易把生命周期讲清楚。重要的是：哈希相同只表示进入同一个候选桶，不能直接当成类型相等。maphash.Hasher 的契约要求等价值产生相同哈希，却不要求不等价值永远不同。

不要把 Sum64() 写入磁盘当作跨进程稳定 ID。官方文档明确说明 seed 属于单个进程，无法序列化后在另一个进程复现；若需要持久化键，应另行定义版本化、可迁移的规范编码。

三、把攻击面收进缓存边界

这类缓存的风险通常来自边界混乱，而不是来自某个神秘的碰撞攻击。把标签当成身份还是噪声，必须在配置层固定；缓存实例里不要同时混用 types.Hasher 和 types.HasherIgnoreTags；哈希桶的键只做索引，条目里的 types.Type 才是最终复查对象。

还有一个容易漏掉的事实：go/types 的等价判断要求符号集合一致。来自不同导入器或重复创建的包符号，可能让本来想比较的 Named 类型失去一致性。因此缓存键设计完成后，还要回头检查类型加载链路，尽量让整棵依赖树使用同一个 Importer。

四、用验证清单固化实现约束

上线前可以按四个问题复查：第一，业务是否明确标签敏感还是标签忽略；第二，桶键和条目复查是否使用同一个 Hasher；第三，碰撞路径是否保留了 Equal；第四，seed、类型文本和缓存版本是否有清晰的生命周期。日志记录缓存版本、桶命中和碰撞次数就够了，不必把完整类型内容打进生产日志。

如果只是把 types.Type 放进一个临时进程内缓存，Go 1.27 的两个 Hasher 已经能把“自定义类型哈希”从工具包内部实现提升为标准库约定。它们解决的是一致性契约，不是持久化编码、加密摘要或并发容器本身。

常见问题

Hasher 能直接当作 Go 内置 map 的 key 吗？

不能。它提供的是 maphash.Hasher 所需的 Hash 和 Equal 方法，容器仍要负责桶、碰撞和并发策略。

HasherIgnoreTags 会忽略所有类型差异吗？

不会。它只对应 IdenticalIgnoreTags 的等价关系，结构体标签和签名接收者有明确的忽略范围，其他类型差异仍然需要保留。

为什么哈希相同还要 Equal？

哈希函数允许碰撞。只有先定位候选桶，再用匹配的 Equal 确认，缓存才能在碰撞时保持正确。