Go 同名类型参数为什么不能当成同一个类型对象

先说结论：Go 里的类型参数名称只在自己的声明作用域内有意义。func A[T any](v T) T 和 func B[T any](v T) T 中的两个 T，即使拼写、约束都相同，也不是同一个类型参数对象。判断它们时要回到声明对象，而不是把名称当成全局 ID。

官方地址：https://pkg.go.dev/go/types#TypeParam

Go 规范把类型参数描述为声明产生的新类型占位符；go/types.TypeParam 则通过 Obj() 暴露对应的 TypeName，通过 Constraint() 暴露约束。两者分别回答“它是谁”和“它允许什么”，不要混为一个判断。

使用场景：名称相同，为什么分析结果不能合并

源码分析器常见一个看似自然的做法：遇到类型参数就用 obj.Name() 作为键。这样做在单个声明内部可能暂时有效，但一旦同时分析多个函数、方法或泛型类型，多个独立声明都可以使用 T，名称键就会发生覆盖。

type Box[T any] struct {
	value T // 这里的 T 属于 Box 的类型参数列表。
}

func Convert[T any](value T) T {
	// 这里的 T 属于 Convert 的函数声明，不能与 Box[T] 合并。
	return value
}

上面两个 T 的约束都是 any，但它们来自两个不同的泛型声明。把它们合成一个键，会让后续的引用解析、替换和类型展示互相污染。

候选方案：比较名称、约束，还是比较声明对象

可以把常见判断方式分成五类。它们不是互相替代的“哪个更高级”，而是对应不同问题。

因此，展示文本可以用名称；建立符号表要保存声明对象；判断约束要检查 Constraint()；做类型等价判断才考虑 types.Identical。最容易出错的是拿前两种“显示属性”代替身份判断。

最小示例：创建两个名字都叫 T 的 TypeParam

如果只是想把规则缩小到 go/types API，可以手工创建两个独立的 TypeName，再分别创建 TypeParam。这里不依赖真实文件，重点是观察对象之间的关系。

package main

import (
	"fmt"
	"go/token"
	"go/types"
)

func newT(pkg *types.Package) *types.TypeParam {
	// 每次创建一个新的 TypeName，表示新的声明锚点。
	obj := types.NewTypeName(token.NoPos, pkg, "T", nil)
	// 空接口约束已完成，作为这个参数的约束类型。
	constraint := types.NewInterfaceType(nil, nil).Complete()
	return types.NewTypeParam(obj, constraint)
}

func main() {
	pkg := types.NewPackage("demo", "example.com/demo")
	left := newT(pkg)
	right := newT(pkg)

	fmt.Println(left.String(), right.String()) // 输出文本都是 T T。
	fmt.Println(left == right)                 // false：两个 TypeParam 指针不同。
	fmt.Println(left.Obj() == right.Obj())     // false：声明对象也不同。
	fmt.Println(types.Identical(left, right))  // false：类型参数身份不同。
}

这个例子最关键的不是把对象指针当作业务数据，而是说明身份来源：NewTypeParam 接收哪个 TypeName，这个参数就绑定到哪个声明对象。两个对象都叫 T，不会因此共享身份。

对比维度：同名、同约束和同类型不是一回事

把三个容易混淆的概念拆开，源码分析就会稳定很多。

1. 同名：只是 Obj().Name() 返回相同字符串，适合做展示或生成局部提示。
2. 同约束：表示允许的类型集合或可用操作可能一致，但不改变参数的声明来源。
3. 同类型对象：需要两个引用指向同一个声明产生的类型参数，不能由字符串相等推导出来。

例如，两个函数都写成 [T any]，约束相同；但把第一个函数的 T 换成第二个函数的 T，并不会得到合法的跨声明引用。实例化时也要区分：Box[int] 的相同性来自同一个定义类型和相同类型实参，并不是因为两个地方都写过字母 T。

推荐选择：按任务决定比较入口

如果程序正在做源码索引，优先保留声明对象和作用域；如果程序只生成提示文本，才读取名称。下面这段代码展示了从声明字段拿到类型参数对象的思路，重点是以 types.Info.Defs 作为声明映射，而不是建立全局的名字表。

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

func declaredTypeParams(info *types.Info, decl *ast.FuncDecl) []*types.TypeParam {
	var result []*types.TypeParam
	if decl.Type.TypeParams == nil {
		return result // 没有类型参数的普通函数直接返回。
	}

	for _, field := range decl.Type.TypeParams.List {
		for _, name := range field.Names {
			// Defs 记录“这个标识符声明了哪个对象”，不会把同名引用混在一起。
			obj, ok := info.Defs[name].(*types.TypeName)
			if !ok || obj == nil {
				continue // 缺少定义信息时跳过，避免把名称猜成对象。
			}
			if param, ok := obj.Type().(*types.TypeParam); ok {
				result = append(result, param)
			}
		}
	}
	return result
}

实际项目中还需要先用 types.Config 对 AST 做类型检查，并把完整的 types.Info 传给检查器。这里的选择规则比具体初始化代码更重要：定义位置走 Defs，使用位置走 Uses，显示文本才走 Name()。

不适用情况：什么时候不能只看 TypeParam

有三类问题不能用“两个 TypeParam 是否相同”一句话解决：

• 想知道两个参数能否接收同一个实参时，要比较约束和实例化条件，而不是比较参数对象。
• 想知道两个结构体实例化后是否同类型时，要比较定义类型及所有类型实参，不能只比较参数列表。
• 想生成用户可读的错误信息时，名称还不够，通常还要附带包路径、声明位置和所属泛型声明。

可以把决策压缩成一句话：名称用于显示，Obj 用于定位，Constraint 用于能力边界，Identical 用于类型等价；不要用名称代替身份。

速查表：Go 同名类型参数的判断顺序

相关问题

两个函数都写 [T any]，能不能共用一个 T？

不能。每个泛型声明都会创建自己的类型参数，除非它们实际引用同一个声明位置，否则名称和约束相同都不改变身份。

TypeParam.String() 不同了，是不是就一定是不同对象？

字符串不同可以提示显示结果不同，但字符串相同也不能证明对象相同。要定位声明，应保留 Obj() 及其位置和所属作用域。

约束完全相同，为什么还要保留两个对象？

约束只描述允许的类型集合和操作边界；对象身份还承担绑定、替换、引用解析和实例化关联。合并对象会丢失这些声明关系。