Go 泛型 Named.Obj 与 Origin.Obj 应该怎样选择

对泛型 Named 的实例，inst.Obj() 与 inst.Origin().Obj() 返回同一个声明 TypeName。需要声明名字、所属包或位置时，直接用 Obj 即可；需要原始泛型类型对象时用 Origin；需要这次实例的类型实参时保留 inst 并读取 TypeArgs。

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

需要声明名字时直接用 Obj

假设分析接口要同时显示 Box 的声明位置和 Box[int] 的具体类型，关键不是选一个“更准确的名字”，而是分别保存声明和实例。Obj 负责声明信息，Origin 返回原始 Named，二者不是两套声明来源。

图中实例 Named 与原始 Named 的 Obj 都对应 TypeName，它提供 Name 和 Pkg 等声明信息。未实例化类型调用 Origin 返回自身，所以为读取名称而先调用 Origin 通常只是多写一层。

保留实例信息的最小示例

package main
import (
 "fmt"
 "go/token"
 "go/types"
)
func main() {
 // 为一个泛型声明建立独立类型参数
 tp := types.NewTypeParam(types.NewTypeName(token.NoPos, nil, "T", nil),
  types.Universe.Lookup("any").Type())
 pkg := types.NewPackage("example.com/model", "model")
 origin := types.NewNamed(types.NewTypeName(token.NoPos, pkg, "Box", nil),
  types.NewStruct([]*types.Var{types.NewField(token.NoPos, pkg, "Value", tp, false)}, nil), nil)
 origin.SetTypeParams([]*types.TypeParam{tp})
 // 实例化可能失败，先处理错误再读取实例
 typ, err := types.Instantiate(nil, origin, []types.Type{types.Typ[types.Int]}, true)
 if err != nil { fmt.Println(err); return }
 inst := typ.(*types.Named)
 fmt.Println(inst.Obj() == inst.Origin().Obj())
 // 声明对象与实例分开保留，避免通过 Obj().Type() 丢失 int
 fmt.Println(inst.Obj().Name())
 fmt.Println(types.TypeString(inst.TypeArgs().At(0), nil))
 fmt.Println(types.TypeString(inst, nil))
}

代码手工建立 Box[T] 并实例化为 Box[int]，没有在本机执行。按接口规则，第一项对象比较预期为 true，名称为 Box，实参为 int。不要把示例预期当成实际执行记录。

这里 TypeName 对应原始声明。如果从 inst.Obj().Type() 重新取得类型，不应期待它仍保留这一次的 int 实参。需要展示实例时直接格式化 inst，需要逐项处理实参时遍历 TypeArgs。

接口返回值怎样避免丢失类型实参

实例 inst 关联 Origin 和 TypeArgs，后者包含 int；接口记录可同时保存声明对象与实例信息。这样按声明归类时使用声明对象，展示具体使用方式时仍能区分不同实参。

Obj相同就能认定实例相同吗？不能。Box[int] 与 Box[string] 可以共享声明对象，却有不同实参。完整类型同一性应使用 types.Identical，且类型对象需来自一致的符号集合。

所有类型都能直接断言成 Named 吗？不能。真实工具应检查类型断言；别名或指针需要按具体任务处理，不能忽略输入类型直接强转。本例 Instantiate 的输入明确是 Named，因此结果按文档也是同类实例。

这个接口选择不会生成函数或执行业务代码。跨包分析应复用统一的导入与符号环境；跨进程持久化不能直接保存内存指针，应设计声明路径和实例描述。不要把 Obj 的共享关系误用为所有场景的唯一缓存键。