Go 1.26 递归泛型约束怎么读：自引用类型参数与接口实现限制

升级到 Go 1.26 后，下面这段声明终于可以成立：type Adder[A Adder[A]] interface { Add(A) A }。第一次看到它，很容易把两个 Adder[A] 当成无限递归，或者误以为 Go 同时增加了“带类型参数的方法”。实际情况更克制：自引用只出现在泛型类型的类型参数约束里，编译器要检查的是类型集合和方法集合能否闭合。

读这类声明时，先把 Adder[A] 看作“满足 Add(A) A 的类型集合约束”，再看具体类型是否实现它；不要把约束回指理解成运行时递归。

先把自引用约束读成普通接口

类型约束本身就是接口，只是它还承担“允许哪些类型参数”的筛选职责。普通接口主要描述方法集合，例如 interface { Add(int) int }；泛型约束则可以把方法参数写成当前类型参数 A，从而表达“加法器接收与自己同型的值”。

这里有两个边界要分开。第一，约束边界描述编译期允许的类型；第二，普通接口仍然遵守隐式实现，具体类型只要拥有同名、同参数、同返回值的方法，就能满足对应方法集合。约束不会创建一个运行时对象，也不会自动递归调用任何方法。

用 Adder[A] 看清类型参数的回指

把声明拆成三层就不绕了：

type Adder[A Adder[A]] interface {
    Add(A) A
}

func algo[A Adder[A]](x, y A) A {
    return x.Add(y)
}

A 是类型参数；右侧的 Adder[A] 是它的接口约束；接口里的 Add(A) A 又使用同一个 A 描述输入和输出。algo[A] 只能接收同时满足这个约束的具体类型，所以调用时 A 会被替换为某个确定类型，而不是保留一个无限展开的接口。

这也是 Go 1.26 的变化点：过去编译器会拒绝类型参数列表里对正在声明类型的回指，现在允许这种约束闭合。它解决的是表达能力问题，不等于放宽所有递归类型规则。

区分接口实现、类型集合与方法声明

最常见的误判是把三件事混在一起。具体类型通过方法集合实现普通接口；类型集合只在泛型约束位置筛选类型；方法声明则规定某个类型的方法签名。比如：

type IntAdder int

func (x IntAdder) Add(y IntAdder) IntAdder { return x + y }

var _ Adder[IntAdder] = IntAdder(0)

最后一行是编译期断言，也是编译器检查方法集合的最小入口：如果 IntAdder 的方法签名不匹配 Add(A) A，检查会失败。它没有把 Adder[A] 当作普通数据类型使用，也没有要求接口方法再写一组类型参数。Go 的接口方法不能声明新的类型参数，但可以使用接口声明里已有的类型参数，这正是本例的边界。

用最小编译检查确认边界

遇到“递归泛型约束不能用”时，先看工具链而不是急着重写接口。Go 1.26 的发布说明明确给出了 type Adder[A Adder[A]] interface 这一类自引用约束；如果本地仍报类型参数列表相关错误，优先检查：

• go version 是否确实使用 Go 1.26 或更新版本，编辑器选择的工具链不能只看系统默认值。
• go.mod 的 go 指令和 CI 镜像是否一致，避免本地能解析、流水线却用旧编译器。
• 具体类型的方法接收者、参数和返回值是否都替换成同一个 A，不能只满足方法名相同。

把正例与反例放在同一个小包中，先保留 var _ Adder[IntAdder] = IntAdder(0) 这类断言，再逐项改动。这样看到错误位置时，能判断是版本问题、方法集合不匹配，还是把类型约束误写成了泛型方法。

常见问题

Go 1.25 能否使用 Adder[A] 这种声明？

不能按 Go 1.26 的规则使用。需要升级编译器和 CI 工具链，或暂时改成不自引用的约束表达。

这是不是 Go 1.27 的泛型方法？

不是。本文的回指发生在泛型类型的类型参数约束中；泛型方法是方法声明自己增加类型参数，属于另一项语法能力。

为什么方法名相同仍然无法满足约束？

接口实现看完整方法签名。接收者、参数或返回值只要没有与 A 对齐，方法集合就不匹配，编译期断言会直接暴露问题。