Go 泛型自引用约束怎样表达递归接口

如果一个泛型函数要求类型 A 提供 Add(A) A，你现在可以直接把这层关系写进约束接口：type Adder[A Adder[A]] interface { Add(A) A }。这类“自引用”描述的是类型参数和方法参数之间的关系，不是链表、树那样的递归数据结构；该声明从 Go 1.26 起才被语言规则放开。

先看清“递归接口”究竟递归在哪里

这里的递归不是接口里嵌套自己，也不是运行时对象指向自己。递归关系只出现在类型约束表达式中：接口 Adder[A] 接收类型参数 A，而 A 又被要求满足 Adder[A]。接口的方法把同一个 A 放在参数和返回值位置，于是泛型函数可以保留具体类型。

Go 官方在 1.26 发布说明中给出的关键形状就是下面这样。先记住它表达的关系，再把它放进一个完整的小项目：

// Adder 要求实现类型的 Add 方法接收并返回同一种类型 A。
type Adder[A Adder[A]] interface {
    Add(A) A
}

用一个小项目固定 Go 版本和目标

这个写法依赖 Go 1.26 的语言变化，因此先在项目根目录固定语言版本。这里不需要额外依赖，项目只包含标准 Go 代码。

# 创建示例目录，并把语言版本固定到支持自引用约束的 Go 1.26。
mkdir -p recursive-adder
cd recursive-adder
go mod init example.com/recursive-adder

# go.mod 中的 go 行应保持为 1.26 或更高版本。
go mod edit -go=1.26

go 行表示项目按哪个语言版本解释代码。它不是把本机工具链自动升级到 1.26；如果本机仍是更早版本，应该先更换工具链，再继续这个示例。

声明自引用约束并实现具体类型

接着定义一个整数分值类型。Score 的 Add 方法必须精确接收和返回 Score；如果把参数写成 int，即使底层类型也是整数，也不再是同一个方法签名。

package main

import "fmt"

// Adder 把类型参数 A 同时放进约束和 Add 方法签名。
type Adder[A Adder[A]] interface {
    Add(A) A
}

// Score 是满足 Adder[Score] 的具体值类型。
type Score int

// Add 接收 Score 并返回 Score，保持类型关系闭合。
func (s Score) Add(other Score) Score {
    return s + other
}

// combine 只依赖 Adder[A] 的 Add 能力，不需要知道 A 的底层类型。
func combine[A Adder[A]](left, right A) A {
    return left.Add(right)
}

func main() {
    // 类型参数可以从两个 Score 参数中推断出来。
    total := combine(Score(18), Score(24))
    fmt.Println(total)
}

这里的关键不是把 Score 转成接口，而是让编译器确认 Score 满足 Adder[Score]。因此 combine 返回的仍然是 Score，调用方不需要手工断言。

从调用结果判断约束是否生效

运行项目后，输出是一个普通的数值结果：

42

更重要的判断点有两个：第一，combine 没有写死 Score，却能调用 Add；第二，返回值仍保持 A，所以后续代码可以继续使用 Score 的方法，而不必从普通接口值中取回具体类型。

如果新增另一个类型，只要它实现同形状的方法，就能复用同一个泛型函数：

// Distance 也把输入和输出保持为同一个具体类型。
type Distance float64

// Add 的参数和返回值都必须是 Distance。
func (d Distance) Add(other Distance) Distance {
    return d + other
}

// 这里仍由编译器推断 A 为 Distance。
var routeLength Distance = combine(Distance(1.5), Distance(2.25))

三类边界最容易混淆

把下面三种情况分开，基本就能判断这条约束是否写对：

可以用下面的错误示例理解最后一种边界：

// BadScore 的方法没有保持 BadScore 这一具体类型关系。
type BadScore int

// 参数和返回值都是 int，因此不能满足 Adder[BadScore]。
func (s BadScore) Add(other int) int {
    return int(s) + other
}

// 这行会因为方法集合不匹配而无法通过类型约束。
// var _ Adder[BadScore] = BadScore(1)

最后一行用类型断言式的赋值检查约束，但故意保留为注释，避免把错误示例混进可运行主程序。真正排查时，优先比较方法的接收者、参数和返回值三处类型。

什么时候该使用这种写法

当算法需要“输入类型和返回类型始终是同一个实现类型”时，自引用约束能让接口声明更贴近这个意图，例如数值累加器、同类型合并器或返回同类型副本的值对象。它适合表达静态类型关系，不负责创建递归对象，也不替代运行时的递归终止条件。

• 先确认项目确实以 Go 1.26 或更高版本编译。
• 检查方法签名是否严格使用同一个具体类型，不要只看底层类型是否相同。
• 如果只需要“有一个方法”而不要求输入输出同型，普通泛型接口或更宽的约束更容易理解。
• 如果问题是树、链表或 AST 的节点递归，应单独设计数据结构，不要把它误写成类型约束问题。

常见问题

这是不是 Go 的递归数据结构？

不是。递归只发生在约束声明的类型参数关系里；示例中的 Score 仍是普通数值类型，没有指向自身的字段。

为什么 Add(int) int 不能满足 Adder[BadScore]？

因为约束实例化后要求的是 Add(BadScore) BadScore。底层类型相同不等于方法签名相同，Go 不会自动把这两个签名视为可替换。

旧版本有什么直接替代写法？

可以把接口参数化但不在接口自己的参数列表中引用接口自身，再让泛型函数使用它；不过本文的直接声明形式依赖 Go 1.26，升级工具链后再采用更清晰的写法。