用类型约束实现数值聚合而不牺牲可读性

数值聚合很适合用 Go 泛型，但可读性的关键不是把所有数值类型都塞进一条最长的签名，而是把复杂度集中到一个命名清楚的类型约束中。下面用 Number 表达项目真正支持的数值集合，再实现短小的 Sum 和 SumBy。调用方依靠类型推断，仍然像调用普通函数一样写代码。

官方泛型教程：https://go.dev/doc/tutorial/generics

前置条件：先确定聚合 API 的边界

这个实验只解决“对一组数值做加法”这一件事。约束应包含业务实际需要的类型，而不是为了显得通用而枚举全部整数、浮点和复数。范围越窄，调用者越容易知道函数支持什么，编译错误也越直接。

先固定三个语义：返回类型与元素类型一致；空切片返回对应类型的零值；泛型只复用算法，不改变整数溢出和浮点舍入规则。金额若要求十进制精度，仍应使用整数最小单位或专门的十进制类型，不能因为用了泛型就改用 float64。

初始化：建立最小模块与测试入口

创建一个小模块，并把聚合函数放在独立的 aggregate 包中。目录只需要实现文件与测试文件，便于把约束、调用和边界放在同一处阅读。

# 创建实验模块与聚合包目录
mkdir -p numeric-lab/aggregate
cd numeric-lab
go mod init example/numeric-lab

# 准备实现与测试文件，内容见后续代码
touch aggregate/sum.go aggregate/sum_test.go

# 运行包内全部测试
go test ./...

这里不额外引入第三方约束包。对于只做求和的项目，自定义一个短约束比增加依赖更直观，也能精确表达允许的底层类型。

编写代码：用近似类型项定义 Number

类型集合中的 | 表示并集，~int64 表示底层类型为 int64 的所有类型。这一点很重要：如果只写 int64，业务声明的 type Points int64 不在类型集合中；加上 ~ 后，它可以直接参与聚合，同时返回值仍保持 Points 类型。

package aggregate

// Number 只收纳当前项目需要参与加法的数值底层类型。
// 使用 ~ 让 Points、Amount 等业务命名类型也能满足约束。
type Number interface {
    ~int | ~int64 | ~float32 | ~float64
}

// Sum 对数值切片求和，返回值保持元素的具体类型。
func Sum[T Number](values []T) T {
    var total T // 空切片自然返回 T 的零值。
    for _, value := range values {
        total += value
    }
    return total
}

这段签名只暴露一个类型参数 T。函数体使用了 +=，所以约束中的每个类型都必须支持加法；编译器会在编译期检查这一点。调用时通常不需要写 Sum[int64](values)，因为编译器可以从 []int64 推断 T。

运行检查：用表驱动测试固定行为

测试至少覆盖整数、浮点、命名类型和空切片。整数可以直接比较；浮点示例用容差判断，避免把二进制浮点的细小舍入差异误判成聚合逻辑错误。

package aggregate

import (
    "math"
    "testing"
)

type Points int64

func TestSumIntegers(t *testing.T) {
    tests := []struct {
        name string
        in   []int64
        want int64
    }{
        {name: "多个值", in: []int64{12, 8, 5}, want: 25},
        {name: "空切片", in: nil, want: 0},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            // 类型参数由 []int64 自动推断。
            if got := Sum(tt.in); got != tt.want {
                t.Fatalf("Sum() = %d, want %d", got, tt.want)
            }
        })
    }
}

func TestSumNamedAndFloatTypes(t *testing.T) {
    // ~int64 允许业务命名类型 Points 复用同一实现。
    if got := Sum([]Points{3, 4, 5}); got != Points(12) {
        t.Fatalf("Sum(Points) = %d, want 12", got)
    }

    // 浮点结果使用容差比较，不直接依赖精确二进制表示。
    got := Sum([]float64{0.1, 0.2, 0.3})
    if math.Abs(got-0.6) > 1e-9 {
        t.Fatalf("Sum(float64) = %.12f, want 0.6", got)
    }
}

运行 go test ./... 后，预期看到所有包测试通过。若删除约束中的 ~，命名类型用例会在编译阶段失败；这正是该测试希望锁定的 API 能力，而不是运行时分支。

扩展实验：用 SumBy 聚合结构体字段

真实业务往往不是直接拿到数值切片，而是需要累计订单金额、任务耗时或积分字段。把字段访问写进每个循环会重复样板代码；直接让聚合函数理解所有业务结构体，又会让通用包与业务模型耦合。一个简洁折中是传入提取函数。

package aggregate

// SumBy 从每个元素中提取一个数值，再使用同一加法规则聚合。
func SumBy[T any, N Number](items []T, pick func(T) N) N {
    var total N
    for _, item := range items {
        total += pick(item)
    }
    return total
}

T any 表示输入元素不受数值约束，只有提取结果 N 必须满足 Number。调用处仍然保留业务语义，不需要暴露复杂类型实参：

type Order struct {
    ID       string
    AmountCF int64 // 金额使用“分”保存，避免浮点金额误差。
}

orders := []Order{
    {ID: "A-101", AmountCF: 1299},
    {ID: "A-102", AmountCF: 2500},
}

// 提取函数明确指出本次聚合的是订单金额字段。
totalCF := aggregate.SumBy(orders, func(order Order) int64 {
    return order.AmountCF
})
fmt.Println(totalCF) // 预期为 3799。

如果同一个字段频繁聚合，可以把提取函数命名为 OrderAmount；如果只在一个位置使用，短闭包通常更容易顺着调用代码阅读。不要为了复用一行循环而引入反射，反射会把本可编译期检查的字段和类型错误推迟到运行时。

边界速查：泛型没有替你解决什么

清理与总结

完成实验后，保留的核心代码只有一个 Number 约束、一个 Sum 和一个可选的 SumBy。如果项目只聚合 int64，普通函数可能更清晰；当相同算法确实跨多个数值类型或业务命名类型重复时，再使用泛型最合适。

可读性来自三个取舍：约束名称表达业务含义，类型集合保持窄小，调用端依靠类型推断。这样泛型复杂度集中在实现边界内，日常调用仍然是 Sum(values) 或 SumBy(items, pick)，不会把类型系统细节扩散到每个业务函数。

相关问题

为什么约束要写成接口？

Go 用接口描述类型集合。包含具体类型项或近似类型项的接口用于约束类型参数，不能当作普通运行时值类型随意使用。

可以把 uint 和 complex 也加入 Number 吗？

技术上可以，只要函数使用的运算对所有成员都有效；但应根据真实业务扩展。无需求地扩大类型集合会让 API 语义更难解释。

SumBy 会不会比手写循环更快？

本文目标是复用和类型安全，不承诺性能提升。对性能敏感的热路径，应使用目标 Go 版本和真实数据做基准测试，再决定是否保留抽象。