Go 泛型约束里的 ~ 类型集怎么选：底层类型、接口满足与编译器核对

写一个泛型函数处理金额、温度或业务编号时，最容易卡在一个看似细小的选择：约束里写 int，还是写 ~int？前者只接受精确的 int，后者把底层类型是 int 的自定义类型也纳入进来。这个差异会直接影响 API 能接收哪些类型，也决定了约束是否过宽。

一、先把精确类型和底层类型分开

先看一个小例子。Cents 是有业务含义的命名类型，它的底层类型仍然是 int，但它不是 int 本身。

package main

type Cents int

func doubleInt[T int](v T) T {
	return v * 2
}

func main() {
	_ = doubleInt(3)       // T 推断为 int
	_ = doubleInt(Cents(3)) // 编译器拒绝：Cents 不是精确的 int
}

这里的拒绝不是因为 Cents 不能做乘法，而是因为约束的类型集只有一个成员：精确的 int。类型推断先要确认实参满足约束，连函数体都还没有进入。

二、~int 到底放宽了哪一层

把约束改成近似元素后，int 以及底层类型为 int 的命名类型都可以进入同一个类型集：

type Cents int

type IntLike interface {
	~int
}

func doubleValue[T IntLike](v T) T {
	return v * 2
}

func demo() {
	_ = doubleValue(3)          // int
	_ = doubleValue(Cents(150)) // Cents
}

这里的波浪号不是“任意整数”的简写，它只描述底层类型恰好为 int 的类型。int32、uint 和底层类型为 string 的命名类型仍然不在集合里。

三、用“运算能力”反推约束边界

类型集放宽以后，函数体能使用的运算仍然由约束决定。不要把“能接收更多类型”和“能做更多操作”混成一件事。

type Number interface {
	~int | ~int64 | ~float64
}

func add[T Number](left, right T) T {
	return left + right
}

type Label string

func demoAdd() {
	_ = add(1, 2)                 // int
	_ = add(int64(1), int64(2))   // int64
	_ = add(1.5, 2.5)             // float64
	_ = add(Label("a"), Label("b")) // 编译器拒绝
}

Number 表达的是三个底层类型分支，而不是“所有支持加法的类型”。如果业务需要包含自定义字符串类型，应该明确写入另一个近似元素，并重新确认 + 在这些类型上是否符合预期。约束越宽，泛型函数的语义就越需要写清楚。

四、从单一类型集扩展到可维护的约束

小函数可以直接写 ~int，公共包或多人维护的代码更适合把约束命名出来。这样以后增加 int64 时，修改点和影响范围更容易被审查。

type WholeNumber interface {
	~int | ~int8 | ~int16 | ~int32 | ~int64 |
		~uint | ~uint8 | ~uint16 | ~uint32 | ~uint64
}

func clampMin[T WholeNumber](v, min T) T {
	if v 

这类约束有两个检查点：一是每个分支是否真的需要，二是调用方的命名类型是否应该被接受。比如金额用整数分存储时，引入所有无符号类型并不一定合适，负数校验、序列化和数据库字段可能都需要对应不同规则。

五、编译器核对清单：不要靠记忆猜类型集

建议在临时文件夹下存放三组调用代码：标准类型、底层类型相同的命名类型、明显不兼容的类型。运行测试或者构建时，分别确认前两组正常通过，第三组在约束定义处报错。编译器抛出的错误信息比你肉眼通读接口要靠谱得多。

type UserID int
type Score int32

func acceptInt[T ~int](v T) {}

func check() {
	acceptInt(1)          // 应通过
	acceptInt(UserID(7))  // 应通过
	acceptInt(Score(9))   // 应拒绝：底层类型是 int32
}

如果代码要兼容多个 Go 版本，还要把约束语法、标准库行为和 CI 使用的版本一起核对。泛型约束通过，不代表业务语义就正确；例如把订单号、金额和计数器都归到 ~int，仍然可能是领域建模过粗。

六、常见问题与误区

加了 ~ 就能接收所有整数吗？

不能。~int 只覆盖底层类型为 int 的类型，int64 和 uint 需要在类型集中单独声明。

命名类型和类型别名有什么区别？

type Cents int 创建的是新命名类型，需要考虑是否满足精确约束；type Cents = int 是别名，仍然就是 int。两者在泛型调用中的表现不同。

什么时候不应该使用 ~？

当 API 只接受一个明确的标准类型，或是命名类型传入后会绕过业务校验时，不要为了省掉一次类型转换就随意放宽约束。

结语：先定能力，再定类型集

选择 int 还是 ~int，本质上是在选择泛型 API 的输入边界。先写出函数需要的运算，再列出真正支持的底层类型，最后用标准类型、命名类型和不兼容类型做一次编译核对。这样的约束既能保留业务类型的可读性，也不会把“泛型”变成没有边界的类型通行证。