Go map 用 NaN 作为键为什么难以再次删除

Go 允许 float64 作为 map 键，因此 math.NaN() 也能被写进去。真正的陷阱是：NaN 与任何浮点值比较都不相等，连它自己也不例外。map 查找和 delete 需要重新匹配键，于是一个 NaN 键可能“写得进去，却查不回来、删不掉”。相关规则可对照 https://go.dev/ref/spec#Map_types、https://go.dev/ref/spec#Deletion_of_map_elements 与 https://pkg.go.dev/math。

消息是什么：问题不在 map，而在 NaN 的相等语义

Go 规范要求 map 的键类型必须定义 == 和 !=。数字类型满足这个条件，所以 float64 可以成为键。可是 IEEE 754 为 NaN 规定了特殊比较行为：所有相等比较都返回假，包括两个位模式相同的 NaN。换句话说，“类型可比较”和“每个值都能与自身相等”不是一回事。

下面的最小程序不依赖并发，也不涉及 map 扩容，就能复现现象：

package main

import (
    "fmt"
    "math"
)

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

    // 写入成功，map 的长度变成 1。
    m[nan] = "异常采样"
    fmt.Println("写入后长度:", len(m))

    // 即使复用同一个变量，NaN 与自身比较仍然不相等。
    value, ok := m[nan]
    fmt.Println("查找结果:", value, ok)

    // delete 也要按键匹配；这里找不到原条目，因此不会删除。
    delete(m, nan)
    fmt.Println("删除后长度:", len(m))
}

典型结果是长度先为 1，查找的 ok 为 false，调用 delete 后长度仍为 1。继续执行 m[math.NaN()] = value 还可能不断增加条目，因为每次插入都找不到一个“相等的旧键”可覆盖。

为什么同一个 NaN 变量也删不掉原条目

map 写入时会保存键和值；后续查找或删除时，则根据哈希结果定位候选位置，再用键的相等语义确认是否命中。普通数字满足 k == k，所以拿着原值就能再次命中。NaN 打破了最后这一环：即便哈希把操作带到相关位置，相等比较仍然不能确认“这就是原键”。

遍历并不能绕过这个规则。for k := range m 的确能把已存储的 NaN 键交给循环变量，但随后执行 delete(m, k) 仍然需要再次匹配键，所以它也可能失败。标准库 maps.DeleteFunc 同样是逐键删除，不能把它当作 NaN 键清理器。

适用场景：哪些业务最容易把 NaN 带进键空间

这个问题常见于聚合、监控和科学计算代码。比如把计算结果直接作为分桶键、把传感器读数作为缓存索引，或把外部 JSON、CSV 解码后的浮点值直接写进 map。除零、无效运算、缺失值转换或上游明确传入的异常值，都可能产生 NaN。

风险通常不是立刻崩溃，而是 map 长度持续增长、缓存清理无效、统计条目无法覆盖。因为程序仍可遍历到这些条目，排查时容易误以为 delete 已生效，只是展示层出了问题。更可靠的诊断方式是同时记录 math.IsNaN(k)、len(m) 以及插入来源。

快速修复：在写入边界拒绝 NaN

如果 NaN 没有业务含义，最稳妥的做法不是事后清理，而是在键进入 map 之前拒绝。把检查封装到唯一写入口，可避免调用方遗漏。

package scorecache

import (
    "errors"
    "math"
)

func Put(m map[float64]string, key float64, value string) error {
    // NaN 不能成为稳定可回查的 map 键，直接在边界拒绝。
    if math.IsNaN(key) {
        return errors.New("map 键不能是 NaN")
    }

    m[key] = value
    return nil
}

math.IsNaN 比 key != key 更直观，也更容易让代码审查者理解意图。若输入来自多个入口，应在数据模型或仓储层统一约束，而不是只在某个 HTTP 处理函数里检查。

修复优先级：阻止新问题，再清理旧数据

已有 NaN 键时：clear 与重建各有边界

如果整个 map 都可以重置，并且项目使用 Go 1.21 或更高版本，直接调用 clear(m)。它会删除所有条目，不依赖逐个键再次相等，因此能够处理 NaN 键。官方说明见 https://pkg.go.dev/builtin#clear。

// Go 1.21+：允许整体丢弃缓存时，clear 是最直接的清理方式。
clear(m)
fmt.Println(len(m)) // 0

如果必须保留正常键，就创建新 map，并在遍历时直接使用循环给出的值，而不是再写 old[k] 查一次。过滤掉 NaN 后，让旧 map 等待垃圾回收：

func withoutNaN(old map[float64]string) map[float64]string {
    clean := make(map[float64]string, len(old))

    for key, value := range old {
        // range 已经给出了当前条目的 value，不要再用 old[key] 回查。
        if math.IsNaN(key) {
            continue
        }
        clean[key] = value
    }

    return clean
}

// 用过滤后的新 map 替换旧引用。
m = withoutNaN(m)

这种重建法要在业务允许的同步边界内执行。若 map 被多个 goroutine 访问，仍需由互斥锁或单线程所有权保护；内置 map 的 NaN 问题不会改变其并发安全规则。

需要保留 NaN 时：把浮点值编码成稳定整数键

有些业务必须区分“结果是 NaN”和“没有结果”。这时不要直接使用 NaN 作为浮点键，可以把键类型改为 uint64，并给所有 NaN 一个统一表示。普通值使用 math.Float64bits，同时把正零与负零规范成同一个键，以保持原先浮点相等语义。

package stablekey

import "math"

var canonicalNaN = math.Float64bits(math.NaN())

func FloatKey(value float64) uint64 {
    // 所有 NaN 统一映射到一个可相等、可删除的整数键。
    if math.IsNaN(value) {
        return canonicalNaN
    }

    // float64 比较认为 +0 与 -0 相等，因此也统一它们。
    if value == 0 {
        return 0
    }

    return math.Float64bits(value)
}

如果业务反而需要保留不同 NaN 载荷，可以不做统一映射，直接使用位表示；但这会让语义更复杂，必须在接口文档中明确。多数缓存、聚合和去重场景更适合“所有 NaN 归为一类”。

和旧方案对比：不要把逐键删除当成通用清空

采用风险与上线检查

把 map[float64]T 改成 map[uint64]T 会影响序列化、日志和对外接口，不能只改内部声明。还要确认零值规范化、NaN 是否合并、无穷大是否允许，以及历史数据如何迁移。若只是修复缓存，入口拦截通常比全量改键更小；若 NaN 是合法业务状态，稳定键编码更清晰。

上线前至少覆盖四个测试：普通浮点键能写入和删除；NaN 在拒绝模式下返回明确错误；稳定键模式下重复 NaN 会覆盖同一条目；包含 NaN 的旧 map 经 clear 或重建后长度符合预期。监控侧再增加一次 map 长度和 NaN 输入计数，就能及时发现回归。

相关问题

用同一个 nan 变量为什么仍然找不到？

因为比较的是浮点值语义，不是变量身份。NaN 与自身执行 == 仍为假。

遍历拿到 key 后再 delete 可以吗？

不可靠。遍历能交出已存储的键，但 delete 仍需按相等语义再次匹配，NaN 条目可能继续存在。

重新赋值一个空 map 与 clear 有什么区别？

若只有当前变量持有引用，重新赋值也能丢弃旧 map；若其他代码仍持有原 map 引用，它们不会看到这个替换。clear 会原地清空同一个 map。