Go NaN 作为 map key 为什么无法正常查找

我第一次把 float64 直接当作缓存键时，看到 NaN 写入成功却查不回来，很容易先怀疑 map 或哈希实现出了问题。其实 float64 确实允许作为 Go 的 map key，真正的问题在于 NaN 的相等比较：NaN 连自己都不相等，所以同一个变量再次参与查询时，也不能命中原来的条目。

官方地址：https://go.dev/ref/spec

如果业务数据可能出现 NaN，不要把原始 float64 当成需要稳定回查的键。可以先把 NaN 归一化为显式标记，再把归一化后的结构体作为 key。下面先解释现象，再给出这种改法。

float64 能做 key，但 NaN 不适合回查

Go 要求 map 的 key 类型可以比较。float64 满足这个条件，因此下面的声明和写入都合法：

package main

import (
	"fmt"
	"math"
)

func main() {
	values := make(map[float64]string)
	nan := math.NaN()

	// float64 是可比较类型，所以这次写入在语法和类型层面都成立。
	values[nan] = "特殊值"

	// NaN 不等于自身，查询不会因为变量复用而自动命中。
	value, ok := values[nan]
	fmt.Printf("value=%q, found=%v\n", value, ok)
}

这里最容易混淆的是“可以作为 key”和“适合作为稳定 key”并不是一回事。前者只说明类型满足 map 的语法要求，后者还要求查询时的相等规则能够把同一个业务值识别出来。

为什么查询表达式看起来相同却找不到

浮点比较的关键规则是：NaN 与任何值比较都不相等，包括另一个 NaN。map 查询要判断候选 key 是否与查询 key 相等，因此 values[nan] 不会把“都是 NaN”当作相等条件。

这和普通的 float64 键不同。比如 1.5 再次参与查询时，比较结果为相等，map 可以找到原值；而 NaN 的特殊比较语义让这条回查路径失效。map 并没有承诺把“位模式相同”当作“键相等”，代码也不能依赖底层哈希布局来绕开语言规则。

package main

import (
	"fmt"
	"math"
)

func main() {
	nan := math.NaN()

	// 直接比较会得到 false，这是 NaN 参与浮点比较的定义。
	fmt.Println(nan == nan)

	values := map[float64]string{nan: "已写入"}
	_, found := values[nan]
	// found 为 false，不能用“写入过”推断“可以按 NaN 查回”。
	fmt.Println(found)
}

插入、查询和删除分别会受到什么影响

把 NaN 放进 map 后，最直观的影响不是“写入立即报错”，而是后续操作不再符合普通键的直觉：

• 插入：赋值语句可以执行，代码不会因为 key 是 NaN 而被编译器拒绝。
• 查询：使用 NaN 查询时，通常得到该值类型的零值和 ok=false，因为比较不成立。
• 删除：使用 NaN 调用 delete 也不能依靠相等比较定位到原条目。
• 遍历：遍历 map 仍可能看到相关条目，但遍历得到的 key 不能因此变成可稳定回查的 key。

因此，问题不只是一次查询失败，而是 NaN 不适合承担“唯一标识—再次读取”的职责。若把它用于缓存、去重、聚合或索引，失效会表现为重复写入、命中率异常或清理不完整。

把 NaN 归一化为稳定的结构体 key

如果业务必须保留“NaN 是一类特殊值”这个信息，可以在进入 map 前先做规范化。下面的做法把所有 NaN 统一为 nan=true，普通数值则保存其位模式；同时把正零和负零统一，避免把语言层面相等的两个零拆成两个业务键。

package main

import (
	"fmt"
	"math"
)

type floatKey struct {
	nan  bool
	bits uint64
}

func normalizeFloatKey(value float64) floatKey {
	if math.IsNaN(value) {
		// 所有 NaN 归并为同一个明确的业务键，不再直接比较 NaN。
		return floatKey{nan: true}
	}
	if value == 0 {
		// +0 和 -0 在 Go 的数值比较中相等，这里把它们统一成 +0。
		value = 0
	}
	// 非 NaN 值保存位模式，结构体本身可以稳定参与 map 比较。
	return floatKey{bits: math.Float64bits(value)}
}

func main() {
	values := make(map[floatKey]string)
	nan := math.NaN()

	// 写入和读取都经过同一套规范化逻辑。
	values[normalizeFloatKey(nan)] = "特殊值"
	value, found := values[normalizeFloatKey(nan)]
	fmt.Printf("value=%q, found=%v\n", value, found)
}

这个结构体的重点是：NaN 分支不再把 NaN 放进可比较字段，而是使用布尔标记；普通数值才进入 bits。只要写入和查询都调用 normalizeFloatKey，同类 NaN 就能映射到同一个结构体 key。

什么时候应该改用字符串或业务 ID

如果 map 的真正目的不是保存浮点位模式，而是按业务对象查找，使用业务 ID 往往更清楚。例如传感器编号、请求 ID 或记录主键都比原始浮点数更适合作为稳定索引。字符串哨兵也能表达 NaN，但要额外处理哨兵与真实字符串冲突，类型安全性不如带 nan 字段的结构体。

只有在确实需要按浮点值分组，并且要保留非 NaN 数值的位模式时，才适合采用上面的 floatKey。如果业务要求区分不同 NaN payload，也不能把所有 NaN 都归一化为同一个标记，而应在结构体中保存经过明确约定的 payload；这属于业务规则，不应由 map 默认行为替你决定。

最小验证：把语言规则写成测试

不需要观察运行时内部结构，只要把比较行为和规范化后的查找行为分别写进测试，就能防止后续重构把 NaN 直接塞回原始 map。

package nankey_test

import (
	"math"
	"testing"
)

func TestNormalizeNaNKey(t *testing.T) {
	values := map[floatKey]string{}
	nan := math.NaN()

	// 统一通过 normalizeFloatKey 写入，测试业务键而不是 NaN 的直接比较。
	values[normalizeFloatKey(nan)] = "特殊值"
	got, ok := values[normalizeFloatKey(nan)]
	if !ok || got != "特殊值" {
		// 失败时同时报告命中状态和返回值，便于区分键问题与值问题。
		t.Fatalf("lookup failed: got=%q, ok=%v", got, ok)
	}
}

如果只是想确认原始行为，可以单独断言 math.IsNaN(nan) 和 nan != nan 的语义；不要把“原始 map 查询失败”写成必须通过的业务测试。对生产代码来说，应该测试你选定的规范化策略，而不是依赖 NaN 的异常特性。

结论

Go 的 float64 可以作为 map key，但 NaN 的比较规则决定了它不是一个可稳定回查的值。写入可能成功，查询和删除却不能按普通浮点键工作。最稳妥的做法是让 NaN 在进入 map 前变成显式、可比较的业务键；如果 map 实际服务于业务对象索引，则优先使用业务 ID。

相关问题

• Go 中 +0 和 -0 作为 map key 是否应该归一化？
• 如何在保留 NaN payload 的同时构造可比较的 Go key？
• 为什么浮点数适合计算，却不一定适合做缓存键？