Go 泛型约束怎样表达可排序元素

如果一个泛型函数内部要使用 、> 或直接调用标准库排序，真正需要声明的不是“任意类型”，而是“具备有序关系的类型集合”。Go 可以用 cmp.Ordered 表达这个边界：整数、无符号整数、浮点数、字符串，以及底层类型属于这些集合的命名类型都可以进入函数；布尔值、复合结构和没有统一顺序的业务对象则会在编译期被挡住。

本文使用的官方文档入口：https://pkg.go.dev/cmp。下面的重点是约束表达与可比较类型，不把“能比较”误解成“适合所有业务排序”。

先把“可排序”收紧成一个约束

一个常见场景是：同一段排序逻辑既要处理整数，也要处理浮点数或字符串。若把参数写成 any，函数体无法安全地使用有序运算；若只接受 int，复用范围又太窄。把类型参数写成 T cmp.Ordered，就是把可用类型集合直接写进函数签名。

package main

import (
	"cmp"
	"fmt"
	"slices"
)

// SortedCopy 返回升序副本，避免排序函数改写调用方持有的切片。
func SortedCopy[T cmp.Ordered](values []T) []T {
	result := slices.Clone(values)
	slices.Sort(result) // cmp.Ordered 让 slices.Sort 能建立统一的有序边界。
	return result
}

func main() {
	prices := SortedCopy([]float64{3.2, 1.5, 2.8})
	names := SortedCopy([]string{"go", "cmp", "generic"})
	fmt.Println(prices, names)
}

这里的安全边界有两层：cmp.Ordered 限制类型参数，slices.Clone 让示例返回新切片。按代码语义，价格会按数值升序排列，字符串会按字节序排列；两者都不需要为每种具体类型复制一份函数。

约束能接住哪些类型，哪些类型会被挡住

cmp.Ordered 覆盖有 、、>=、> 语义的基础类型，包括各种整数、浮点数和 string。约束定义中的波浪号意味着，底层类型属于这些集合的命名类型也可以使用。

package main

import "cmp"

type Score int
type Label string

// Max 返回两个有序值中的较大者，约束拒绝没有统一顺序的类型。
func Max[T cmp.Ordered](left, right T) T {
	if left > right { // 有序约束保证这里的比较表达式合法。
		return left
	}
	return right
}

func example() {
	_ = Max(Score(8), Score(5))
	_ = Max(Label("beta"), Label("alpha"))
	// Max(true, false) 会失败：bool 不属于 cmp.Ordered。
}

Score 和 Label 是命名类型，但底层类型分别是 int 和 string，因此可以进入 Max。这并不表示任意结构都能“自定义变成有序”：如果对象需要按多个字段、空值规则或业务优先级排序，就应该提供比较函数，而不是强行套用 cmp.Ordered。

从风险控制角度看，约束解决的是类型边界，不解决业务顺序。编译器能告诉你某个类型不在集合内，却不能替你决定“相同分数时按时间还是按名称排列”。

浮点数的 NaN 是排序约束里的特殊风险

浮点数虽然属于 cmp.Ordered，但 NaN 不是普通数字。直接使用语言比较运算时，NaN 与其他值比较会得到特殊结果；如果业务要求稳定、可解释的顺序，应该明确使用 cmp.Compare 或 cmp.Less 的语义，而不是只看到“类型可排序”就认为所有输入都没有边界。

package main

import (
	"cmp"
	"fmt"
	"math"
)

// CompareScore 把 cmp 的三态结果转换成调用方需要的排序方向。
func CompareScore(left, right float64) int {
	return cmp.Compare(left, right) // cmp 对 NaN 的顺序有明确约定。
}

func main() {
	result := CompareScore(math.NaN(), 10)
	fmt.Println(result)
}

官方 cmp 文档将 NaN 视为小于非 NaN，两个 NaN 视为相等，负零与正零相等。若产品规则要求“缺失分数永远排在最后”，那是另一层业务策略：可以先把缺失状态拆出来，或用 slices.SortFunc 写明确的比较函数，不要把通用约束当成领域规则。

什么时候应该换成自定义比较函数

如果排序对象是结构体、需要降序、要按多个字段稳定排序，或者有空值、NaN、大小写等业务规则，参数应从“类型约束”转向“比较策略”。常见形态是让调用方提供 func(T, T) int，由函数内部调用 slices.SortFunc；这样约束负责保证参数类型一致，比较函数负责表达业务顺序。

不要为了复用而把所有排序都抽成一个过度泛化的接口。简单数值和字符串排序用 cmp.Ordered 足够清晰；复杂对象则把比较策略留在调用点，读者更容易审计排序资产、输入边界和异常值处理。

写泛型排序函数前的检查清单

• 函数真正需要的是基础有序类型，还是一个结构体字段的业务比较。
• 是否需要接受底层类型为整数或字符串的命名类型。
• 是否明确了字符串按字节序比较，而不是按本地化语言规则排序。
• 浮点输入是否可能包含 NaN、正负零或缺失值。
• 排序是否应该原地修改；不应改写调用方时先复制切片。
• 复杂对象是否应该改用显式比较函数，而不是扩大类型约束。

两个容易混淆的问题

为什么 bool 不能传给 cmp.Ordered？ 因为布尔值没有 Go 语言定义的大小关系，只有真假逻辑；如果业务需要把真假映射成优先级，应先转换成明确的整数或提供比较函数。

自定义类型一定不能用吗？ 不一定。底层类型是允许的整数、浮点数或字符串时可以使用；如果类型是结构体，或顺序取决于多个字段，就应把排序规则显式写出来。

归纳起来，cmp.Ordered 适合表达“这个泛型函数只处理天然有序的值”。它把错误尽量提前到编译期；当排序语义超出基础类型时，及时切换到自定义比较函数，边界会更清楚。