Go sort.SliceIsSorted 遇到 NaN 时为什么判断异常

我第一次遇到这个现象，是在给浮点指标做升序校验时：普通数字都排好了，只要某个采集值变成 math.NaN()，sort.SliceIsSorted 的结果就不像“从小到大”那么直观。结论先说清楚：函数没有随机判断，它只按你提供的 less 检查相邻元素；而普通的 遇到 NaN 时无法提供完整的排序关系。

先看 SliceIsSorted 到底检查什么

当前 Go 标准库的实现从切片尾部向前遍历，判断是否存在 less(i, i-1) 为真的相邻对。一旦发现后一个元素应该排在前一个元素之前，就返回 false；全部检查都为 false 才返回 true。它不会验证你的比较器是否满足严格弱序，也不会扫描出一个“更合理”的 NaN 规则。

因此，下面的写法表达的是“按普通小于关系，没有发现相邻逆序”，并不等于“这些 float64 按业务意义已经严格升序”。

values := []float64{1, math.NaN(), 3}
sorted := sort.SliceIsSorted(values, func(i, j int) bool {
	// 这里只使用数值小于；NaN 的位置策略还没有定义。
	return values[i] 

NaN 为什么让普通小于比较失去排序关系

Go 规范把 float32 和 float64 的比较交给 IEEE 754 语义。对 NaN 来说，nan == nan 是 false，nan 、1 也都是 false。这里的 false 不是“两个值相等”，而是这个比较没有给出先后关系。

这会带来一个容易误读的结果：如果切片中出现 NaN，普通比较器可能对多个相邻对都返回 false，于是检查函数返回 true；但这只说明“比较器没有报告逆序”，不说明 NaN 已经落在你期望的位置。Go 文档也特别提醒，浮点 在 NaN 参与时不是严格弱序。

根据业务决定 NaN 是拒绝、过滤还是排在最前

我更愿意先在数据边界定策略，而不是直接换一个排序 API。金融或计费数据通常应拒绝 NaN 并记录来源；展示型指标可以过滤 NaN；如果必须保留所有样本，则应明确规定 NaN 排在最前或最后。关键是同一份数据在清洗、排序、校验和分页时使用同一规则。

func rejectNaN(values []float64) error {
	for index, value := range values {
		// NaN 不能用 value == value 代替识别，使用 math.IsNaN 更直白。
		if math.IsNaN(value) {
			return fmt.Errorf("values[%d] is NaN", index)
		}
	}
	return nil
}

如果选择过滤，保留原始下标或记录标识，别让监控人员只看到“少了一条”而找不到数据源。

让排序和检查共用同一套比较语义

需要保留 NaN 时，可以把“NaN 在最前”写成稳定的比较关系。标准库的 sort.Float64Slice.Less 就采用了类似思路：普通数值比较为真，或者左值是 NaN 且右值不是 NaN。若业务要求 NaN 在最后，则交换这两个分支。

lessNaNFirst := func(values []float64) func(int, int) bool {
	return func(i, j int) bool {
		left, right := values[i], values[j]
		leftNaN, rightNaN := math.IsNaN(left), math.IsNaN(right)
		// 先决定 NaN 的位置，再比较两个都不是 NaN 的值。
	if leftNaN != rightNaN {
			return leftNaN
		}
		return left 

这里的重点不是调用两次 API，而是排序和校验拿到同一个闭包。若一个地方用 、另一个地方用 NaN 优先，排出来的切片和校验结论当然可能不一致。

上线前用边界样本复查结果

至少准备空切片、单元素、单个 NaN、多个 NaN、math.Inf(-1)、math.Inf(1) 和普通逆序样本。检查时同时断言 NaN 的数量、位置策略和普通数字的顺序。不要把 SliceIsSorted == true 单独当作数据质量证明，它只对当前比较器负责。

常见问题

为什么 NaN 不能用 value == value 判断？

因为 NaN 与自身比较也为 false。可读性更好的写法是 math.IsNaN(value)。

sort.Float64sAreSorted 能直接解决吗？

它定义了 NaN 排在其他值之前，适合接受这条规则的场景；若业务规则不同，继续使用自定义比较器，并让排序和校验共享它。

为什么检查返回 true 但我仍然不放心？

因为 true 只表示没有发现比较器报告的相邻逆序。先确认 NaN 策略，再确认比较器满足严格弱序，最后检查数据清洗链路是否一致。