Go TypeParam.SetConstraint 为什么应在类型构造阶段完成

用 go/types 手工构造泛型类型时，TypeParam.SetConstraint 不是一个可以随时补上的普通 setter。更稳妥的顺序是：先把约束对象本身构造完整，再把它交给 TypeParam，之后才读取约束、底层类型、索引，或把参数绑定到命名类型和签名中。

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

如果通过 NewTypeParam 传入了 nil 约束，SetConstraint 应在约束的底层类型完整后调用；返回之后参数才适合交给并发读取代码。调用前只把它用于形成其它类型，不要提前依赖它的约束语义。

• 保护对象：TypeParam 的约束、底层接口和绑定关系。
• 风险路径：约束未完成就读取 Underlying、参与实例化或让对象逃逸。
• 控制原则：构造阶段允许留空，发布阶段一次设置，使用阶段只读。

先把约束当作待保护的类型信息

TypeParam 表示泛型声明中的类型参数。NewTypeParam 的第二个参数可以是 nil，这是为了给递归关系或需要分两步组装的类型留下空间；但这不等于参数已经拥有可供分析的完整约束。官方文档还要求：如果直接传入非空约束，它必须已经完全定义。

这里的“完整”不是指字符串能打印出来，而是约束的底层类型和接口关系已经稳定。对接口约束来说，应先完成接口对象，再调用 SetConstraint。下面的代码只展示对象组装关系，未把它当成运行截图或执行证据：

pkg := types.NewPackage("demo", "demo")
name := types.NewTypeName(token.NoPos, pkg, "T", nil)

// 先创建一个暂时没有约束的类型参数，避免把半成品约束暴露出去。
tp := types.NewTypeParam(name, nil)

// 约束对象先完成自己的接口定义，再交给 TypeParam。
bound := types.NewInterfaceType(nil, nil)
bound.Complete()
tp.SetConstraint(bound)

// 约束设置完成后，才读取约束和底层类型。
fmt.Println(tp.Constraint(), tp.Underlying())

风险不在 nil，而在未完成状态被当成完成状态

把约束暂时设为 nil 本身是 API 允许的构造策略；真正危险的是在 SetConstraint 前把它当成最终类型来使用。此时如果读取 Constraint()、依赖 Underlying() 的接口语义，或者把对象交给需要完整类型信息的分析流程，调用方就可能把“尚未完成”误判为“没有约束”。

可以把风险分成三档：只保存指针、为形成其它类型而暂时引用，通常属于构造动作；读取约束、底层类型和方法集，属于需要完整语义的分析动作；将对象交给并发检查、实例化或长期缓存，则还要求 SetConstraint 已返回。官方契约强调的正是这条边界，而不是要求所有对象必须一次性创建。

按两阶段组装并建立使用边界

推荐把代码拆成“构造”和“使用”两个阶段。构造阶段创建 TypeName、TypeParam 与约束接口，完成约束后再把参数绑定到 Named.SetTypeParams 或传给 NewSignatureType。使用阶段只读取已经稳定的 Index、Constraint 和 Underlying。

// 约束完成后，TypeParam 才进入可复用的只读阶段。
tp.SetConstraint(bound)

// 下面这些动作表达“使用”而不是继续修改约束。
idx := tp.Index()
constraint := tp.Constraint()
underlying := tp.Underlying()

// 先准备一个命名类型和空参数元组，演示参数绑定位置。
namedObj := types.NewTypeName(token.NoPos, pkg, "Box", nil)
named := types.NewNamed(namedObj, types.NewStruct(nil, nil), nil)
params := types.NewTuple()
results := types.NewTuple()

// 绑定或构造派生类型时，复用同一个已经稳定的参数对象。
named.SetTypeParams([]*types.TypeParam{tp})
sig := types.NewSignatureType(nil, nil, []*types.TypeParam{tp}, params, results, false)
_ = idx
_ = constraint
_ = underlying
_ = sig

示例中的 named、params 和 results 代表已经准备好的命名类型与参数元组；重点不是补齐一个业务模型，而是不要在绑定和派生过程中继续改变约束。特别是 NewTypeParam 文档所说的“只能用于形成其它类型”，不应被扩大解释成“可以随意查询”。

发布前的检查清单

封装这类构造器时，可以在代码审查中逐项确认：

1. 是否明确记录了 NewTypeParam 创建时约束是否为空。
2. 非空约束的底层类型是否已经完成；接口约束是否已经调用 Complete。
3. SetConstraint 是否只在构造阶段调用一次，并且没有与其它读取并发发生。
4. 是否把 Constraint、Underlying、实例化或方法集分析放在设置完成之后。
5. 是否等 SetConstraint 返回后，再把参数交给并发使用或长期缓存。

这样处理的好处是，类型图的“半成品”只存在于内部构造阶段，外部分析看到的始终是完整约束。若确实需要递归类型关系，也应保留两阶段组装，但把交界点集中在一个小函数里，避免调用方自行猜测 nil 的含义。

常见问题

为什么不直接在 NewTypeParam 中传入约束？

如果约束已经完全定义，直接传入当然可以。使用 nil 再设置，主要是为递归或相互引用的类型构造留出顺序空间；它不是推荐读者忽略完整性要求。

SetConstraint 返回后还能再次修改约束吗？

公开 API 的使用契约应把它视为完成点。不要把同一个 TypeParam 当作可反复改写的配置对象；需要另一种约束时，重新构造对应的类型参数更容易保持边界清楚。

SetConstraint 前能调用 Index 吗？

官方重点限制是：除形成其它类型外，不要在约束设置前使用类型参数。即使某个简单查询看起来能返回结果，也不应把未完成对象暴露给依赖完整语义的代码。