Go 泛型约束如何设计可复用排序函数：类型集合、比较器与编译期边界

同一个排序需求，落到项目里经常会变成三份近似代码：整数按大小排，字符串按字典序排，业务结构体再按优先级和创建时间排。真正难的不是把切片排起来，而是让“哪些类型允许进入函数”和“两个值怎么比较”分别说清楚。Go 泛型的类型约束适合管前一件事，比较器适合管后一件事。

先把“能排序什么”与“按什么排序”拆开

有一批配置项需要按名称排序，另一批数字需要按大小排序。若函数内部写死 item.Name，它只能服务一个结构体；若把所有值都塞进 any，调用方又要承担类型断言和运行时失败。

更清晰的边界是：类型参数约束说明允许哪些值，比较器说明顺序。这里的方案形状很简单：

type Ordered interface {
    ~int | ~int64 | ~float64 | ~string
}

func SortOrdered[T Ordered](items []T) {
    slices.Sort(items)
}

func SortBy[T any](items []T, less func(T, T) bool) {
    slices.SortFunc(items, func(a, b T) int {
        switch {
        case less(a, b):
            return -1
        case less(b, a):
            return 1
        default:
            return 0
        }
    })
}

Ordered 只允许指定的基础类型及其底层类型进入第一条路径；SortBy 则把判断顺序交给调用方。两者各自解决一类问题，后面排结构体时不必伪造一个“所有字段都可比较”的约束。

基础类型：类型集合要覆盖实际别名

项目里常见的不是裸 int，而是 type Score int、type UserName string 这样的业务别名。约束中的波浪号表示允许底层类型匹配，因此这些别名也能复用排序函数。

type Score int
type UserName string

scores := []Score{42, 7, 19}
names := []UserName{"Zoe", "Amy", "Lin"}

SortOrdered(scores)
SortOrdered(names)
// scores: [7 19 42]
// names:  [Amy Lin Zoe]

这一步的检查点是编译器，而不是运行时日志：如果把 []time.Time 传给 SortOrdered，它不应悄悄进入函数后再报错，而应在调用处直接指出约束不满足。若团队已经使用支持泛型排序的标准库 API，也可以直接采用库里的有序约束，减少自维护类型集合。

业务结构体：比较器决定真正的业务优先级

订单列表通常不是“字段越小越靠前”这么简单。假设待处理订单先按 Priority 降序，再按 CreatedAt 升序，最后用 ID 作为稳定的兜底顺序：

type Order struct {
    ID        int
    Priority  int
    CreatedAt time.Time
}

orders := []Order{ /* ... */ }
SortBy(orders, func(a, b Order) bool {
    if a.Priority != b.Priority {
        return a.Priority > b.Priority
    }
    if !a.CreatedAt.Equal(b.CreatedAt) {
        return a.CreatedAt.Before(b.CreatedAt)
    }
    return a.ID 

这里别把多个条件压成一行。每一层都是业务规则，拆开后更容易发现“高优先级是否真的在前面”和“同一时间是否有稳定顺序”这两个验收点。

比较器的三个边界，必须单独测

排序函数最容易被忽略的 bug，不在泛型声明，而在比较器返回了不一致的关系。至少准备三组测试数据：严格小于、严格大于、所有关键字段相等。比较器应满足：

• less(a, a) 必须为 false，否则同一个元素会被判定为小于自己。
• 如果 less(a, b) 为 true，就不能同时让 less(b, a) 为 true。
• 关键字段相等时返回 false，让下一个字段或最终 ID 接管顺序。

对 SortBy 的测试不要只断言首元素。逐项检查相邻元素的顺序，才能捕捉中间位置被错误插入的问题：

for i := 1; i 

什么时候不该继续抽象

如果只有一个结构体、一个调用点，而且排序规则会频繁变化，直接写一个局部 slices.SortFunc 往往比新增公共泛型函数更容易维护。泛型抽象的收益来自重复调用和稳定边界，不是来自代码里出现了一个类型参数。

还要留意浮点数中的 NaN。它不具备普通数值那样直观的全序关系，若业务数据可能出现 NaN，应先明确它应该排在最前、最后，还是在入库时拒绝。不要把一个默认比较器当成数据清洗策略。

上线前的最小验收清单

1. 用整数、字符串和一个底层类型别名分别调用，确认约束覆盖范围符合预期。
2. 用结构体传入比较器，检查主排序字段、次排序字段和稳定兜底字段。
3. 为比较器补自反、反向和相等场景，逐项检查排序后的相邻元素。
4. 故意传入不满足约束的类型，确认错误在编译期暴露。
5. 对可能出现 NaN、空切片和重复元素的数据单独写测试，不把它们混在普通 happy path 里。

常见问题

泛型排序一定比 interface{} 更快吗？

不能只凭写法下结论。泛型通常能让类型信息在编译期保留，但最终还要结合具体数据、比较器和基准测试判断。先用 go test -bench . 测量，再决定是否值得抽象。

结构体能不能直接放进有序类型约束？

通常不应这样做。结构体的业务顺序往往由多个字段组成，显式比较器比人为定义一个全局“大小”更可靠，也更容易随需求调整。

如何判断比较器写对了？

先检查同值、反向和重复字段，再对排序结果逐项验证相邻关系；如果顺序依赖时间或浮点数，补上边界数据，不要只测一组正常样本。

小结

可复用排序函数的关键不是把所有类型塞进同一个签名，而是把约束和顺序分工：基础类型用类型集合保护编译期边界，业务结构体用比较器表达实际优先级。最后用编译失败用例和排序结果检查共同验收，抽象才不会变成另一层不透明的复杂度。