Go 泛型约束如何允许自定义数值类型参与运算

想让一个泛型函数同时接收 int64 和自定义的 PriceCents，关键不在函数体里写更多类型判断，而在约束中描述“底层类型可以是什么”。给类型前加 ~ 后，类型集合会包含底层类型匹配的命名类型；函数体再根据这个集合允许的运算符完成累加。

先用 ~ 描述“底层类型可以匹配”

直接写 int64 | float64 时，类型集合表达的是这两个具体类型。自定义的 PriceCents int64 并不会因此自动进入集合。改成 ~int64 | ~float64，表达的就是底层类型分别为 int64 或 float64 的类型集合。

这类约束适合金额分、距离或比例等领域类型：它们保留了业务语义，却仍能复用同一套数值函数。注意，类型别名与定义新类型不是一回事；这里讨论的是带有独立类型名的定义类型。

把允许的运算写进 Number 约束

package main

// Number 只允许参与加法的整数和浮点底层类型。
type Number interface {
	~int | ~int64 | ~float64
}

// Sum 返回同一种 T 的累计值，调用方不需要丢失自定义类型。
func Sum[T Number](values ...T) T {
	var total T
	for _, value := range values {
		// 约束保证 T 支持加法，空参数时返回 T 的零值。
		total += value
	}
	return total
}

type PriceCents int64
type Meters float64

func main() {
	// 命名类型的底层类型匹配 ~int64 和 ~float64。
	price := Sum(PriceCents(1200), PriceCents(350))
	distance := Sum(Meters(1.5), Meters(2.25))
	_, _ = price, distance
}

Number 中的每个成员都支持 +，因此 Sum 可以在不使用反射的情况下累加。返回值仍然是 T，所以 price 的结果是 PriceCents，不会悄悄退化成 int64。

自定义类型能参与运算，但一次调用仍只有一个 T

Sum(PriceCents(1200), PriceCents(350)) 中所有参数都能推断为 PriceCents。如果把 PriceCents 和 Meters 放进同一次调用，编译器无法为同一个 T 同时选择两个命名类型。即使它们的底层类型都是数值，也不能把金额和距离混成一个结果。

确实需要合并时，先在业务边界显式转换为统一单位和统一类型；不要为了让泛型调用通过而把约束放宽成 any。显式转换也能提醒后来维护代码的人：这里发生了单位或精度决策。

需要比较或更窄的业务范围时单独拆约束

数值集合不是越大越好。若函数需要排序、比较大小或表达金额整数单位，可以定义更窄的约束，避免把不符合业务语义的类型混进来。例如只接受整数：

// WholeNumber 把业务结果限制在整数，避免浮点精度进入计数逻辑。
type WholeNumber interface {
	~int | ~int64
}

// Max 返回整数集合中的较大值。
func Max[T WholeNumber](left, right T) T {
	// 约束成员都支持比较，返回值保持调用方的 T。
	if left > right {
		return left
	}
	return right
}

如果约束要覆盖字符串、整数等可排序类型，应以实际使用的运算符为准选择官方或项目内的约束定义。约束的职责是声明可用能力，不是把所有类型都收纳进来。

常见问题

为什么没有 ~ 时自定义类型不能传入？

没有 ~ 时，集合成员表示具体类型；加上 ~ 才会按底层类型匹配定义类型。

可以让 Sum 同时接收 int64 和 float64 吗？

可以在约束中允许两者，但同一次调用仍需推断出一个统一的 T，混合参数应先显式转换。

为什么不直接用 any 再做类型判断？

那会把错误推迟到运行时，也无法让编译器保证 + 对所有输入成立；类型集合更适合表达这个边界。

记住一条判断标准：先列出函数真正需要的运算，再反推约束中的类型集合。这样既能让自定义数值类型复用泛型逻辑，也能把单位、精度和混用风险留在清晰的类型边界内。