Go 泛型约束抽象数值运算而不丢类型的设计方法

Go 泛型要抽象数值运算，关键不是把参数写成“任意类型”，而是把运算真正需要的能力写进类型约束。以整数和浮点数求和为例，K comparable 保证键能用于 map，V int64 | float64 则限定值可以参与加法；函数返回 V，调用 int64 map 得到的仍是 int64，不会退化成 any。

先明确键和值的类型边界

把两个普通函数合并前，先拆出两个问题：键只需要满足 map 的可比较要求，值则必须支持当前函数中的运算。Go 预声明的 comparable 适合描述 map 键；它不等于“所有类型都能相加”，也不应被拿来代替数值约束。

因此函数签名可以先定成下面这样。注释说明了约束职责，后续新增数值类型时只改值约束，不改变键的边界。

package main

// SumValues 把 map 中的数值相加，并保持结果类型为 V。
// K 只负责满足 map 键的可比较要求，V 负责限定可执行的数值运算。
func SumValues[K comparable, V int64 | float64](values map[K]V) V {
    // 用 V 的零值初始化，避免先转成 float64 再丢失类型信息。
    var total V
    for _, value := range values {
        total += value
    }
    return total
}

用联合约束抽象整数与浮点数运算

V int64 | float64 是一个类型集合，表示调用方只能把 int64 或 float64 作为 V。编译器会据此确认 total += value 对集合中的每个允许类型都成立。若传入 int，它不会因为“看起来也是整数”而自动通过。

调用时可以显式写类型实参，也可以让编译器从 map 参数推断。下面的两次调用分别保持整数和浮点数结果：

func main() {
    // 两个 map 使用不同的值类型，验证泛型函数不会统一改成 float64。
    counts := map[string]int64{"ok": 4, "retry": 2}
    ratios := map[string]float64{"first": 0.25, "second": 0.75}

    // K 和 V 能从实参推断出来，因此调用处可以省略类型实参。
    countTotal := SumValues(counts)
    ratioTotal := SumValues(ratios)
    println(countTotal, ratioTotal)
}

这段代码的设计结果是：countTotal 的静态类型为 int64，ratioTotal 的静态类型为 float64。不要为了让两个结果“统一”而把函数改成返回 float64；那会把整数语义、边界判断和后续 API 类型一起变模糊。

用命名约束接住自定义数值类型

业务代码通常会给数值定义名称，例如订单数量或比例。若约束只写 int64 | float64，下面的命名类型不会自动属于集合：

type Quantity int64

// NumericValue 允许底层类型为 int64 或 float64 的命名类型。
// ~ 表示匹配底层类型，而不是只匹配一个精确类型名。
type NumericValue interface {
    ~int64 | ~float64
}

// SumNamedValues 返回 V，调用方仍能得到 Quantity 等具体类型。
func SumNamedValues[K comparable, V NumericValue](values map[K]V) V {
    // 仍从 V 的零值开始，避免在泛型内部做不必要的类型转换。
    var total V
    for _, value := range values {
        total += value
    }
    return total
}

~ 只放宽“底层类型”匹配，不代表任意自定义类型都能混算。一次调用中的 V 仍然是单一具体类型；map[string]Quantity 可以求和，但不能把 Quantity 和 float64 混在同一个 V 中。

检查类型推断和约束边界

如果编译器无法仅从参数推断出类型，调用处再补上 SumValues[string, int64](counts)。如果运算需要比较、除法或排序，也要重新检查集合中的每个类型是否都具备相同语义：能通过编译不等于溢出、精度和零值行为已经符合业务要求。

常见问题

为什么不直接使用 any？

any 不能让编译器证明加法成立，通常会把问题推迟到类型断言或反射；联合约束更适合有明确数值边界的函数。

为什么返回值要写成 V？

返回 V 会让整数输入得到整数结果、浮点输入得到浮点结果，调用方不必再做断言或转换。

可以把 int 也加入约束吗？

可以，但应根据接口和溢出语义决定是否加入，不要因为它也是整数就无条件扩大类型集合。