Go 泛型接口如何限制方法集：类型集、接口方法与调用方边界

写一个泛型函数时，最容易混淆的是“这个类型能不能传进来”和“传进来以后能调用哪些方法”。前者由类型集决定，后者由接口方法集决定；两者写在同一个约束接口里，却是两道不同的边界。

先准备一个能跑的最小实验

下面用一个带名称的数值类型做实验。它的底层类型是 int，同时拥有一个只有自己声明的方法。我们会分别观察类型集和方法集。

package main

import "fmt"

type Score int

func (s Score) Label() string {
	return fmt.Sprintf("score=%d", s)
}

type Number interface {
	~int | ~int64
}

func Double[T Number](v T) T {
	return v + v
}

func main() {
	var s Score = 21
	fmt.Println(Double(s))
	fmt.Println(s.Label())
}

保存为 main.go 后执行：

go mod init generic-boundary-demo
go run .

正常结果包含 42 和 score=21。第一个输出证明 Score 满足 Number 的类型集，第二个输出来自具体变量本身的方法。

类型集决定哪些类型可以进入

Number 里的 ~int 不是“只允许 int”，而是允许底层类型为 int 的定义类型。于是 Score 可以作为 T 传给 Double。如果把参数改成 string，编译器会在类型推断阶段拒绝它，因为 string 不在这个类型集内。

这里的检查发生在调用边界：

type Count int
type Title string

var _ = Double(Count(3)) // 可以：底层类型是 int
var _ = Double(Title("go")) // 不可以：不在 Number 类型集

可以把类型集理解为“入场名单”。它只回答“允许哪些具体类型”，不回答“泛型函数能不能调用这些具体类型的额外方法”。

把方法写进约束，调用方才有稳定边界

现在增加一个只描述行为的约束：

type Labeled interface {
	Number
	Label() string
}

func Describe[T Labeled](v T) string {
	return v.Label()
}

Describe(Score(21)) 可以通过，因为 Score 同时满足 Number 和 Label() string。如果只写：

func Wrong[T Number](v T) string {
	return v.Label()
}

编译器不会因为 Score 实际上有 Label 方法就放行。对泛型函数来说，T 的可用方法只来自约束声明；调用者不能依赖某个类型集成员“碰巧拥有”的额外方法。

运行检查：分别验证类型和行为

把 main 改成下面的形式，检查两道边界是否都符合预期：

func main() {
	var s Score = 21
	fmt.Println(Double(s))
	fmt.Println(Describe(s))
}

// 输出：
// 42
// score=21

如果把 Label 从 Labeled 中删掉，Describe 内部就不能调用 v.Label()；如果保留方法却把 ~int 从类型集删掉，Score 又会在传入时失败。这两个报错位置不同，排查时先看是“类型不在集合”还是“约束没有声明行为”。

扩展实验：约束越宽，调用能力越窄

有时函数只需要加法，不需要标签。这时直接使用 Number 更合适；不要为了调用一个额外方法，把所有类型都塞进一个过宽的业务接口。约束过宽会让泛型函数暴露更多假设，后续替换类型时更容易出现难以解释的编译错误。

反过来，如果一个算法确实依赖 Label，就把这个方法写进约束。这样读代码的人能在函数签名处看见完整契约，不必翻遍类型集成员。

常见问题与边界提醒

类型集里的具体类型会自动带来它的方法吗？

不会。类型集负责类型资格，方法集负责泛型代码可以调用的行为；额外方法必须出现在约束接口中。

为什么定义类型可以匹配 ~int？

波浪号表示底层类型匹配，所以 type Score int 可以进入 ~int，但这不等于它会变成普通 int，它自己的方法仍然属于 Score。

遇到编译错误先看哪里？

先看调用点是否满足类型集，再看泛型函数体里调用的方法是否写在约束接口上。把这两个检查拆开，通常比反复修改类型参数更快。

把两道边界留在函数签名上

类型集是允许进入的范围，方法集是进入以后可以使用的能力。设计泛型接口时，先列出需要接受的具体类型，再列出算法真正依赖的方法；能用窄约束表达，就不要依赖某个成员类型的隐含能力。这样编译器会在正确的位置替你拦住错误调用，代码也更容易扩展。