浮点数不能稳定作为HashMap的key，因其不满足相等性可判定和哈希值一致性要求：IEEE 754导致精度丢失与舍入误差，使数学相等的数二进制不同，equals()和hashCode()均不匹配，查找必然失效。
浮点数变量不能稳定作为 HashMap 的 key，根本原因在于它无法满足哈希结构对键的两个刚性要求：相等性可判定 和 哈希值一致性。看似相同的 1.0 和 1.0000001，在内存中是两个不同二进制模式，equals() 返回 false，hashCode() 也不同——HashMap 就会把它们当成两个完全无关的 key。
浮点数的“相等”在计算机里本就不成立
IEEE 754 标准下，float/double 用有限位数表示无限精度的小数，很多十进制小数（如 0.1、0.2）根本无法精确存储。运算过程还会累积舍入误差。结果就是：
- 数学上相等的两个实数，二进制表示可能不同
- == 比较不可靠，Float.equals() / Double.equals() 也依赖原始位模式，不作容差判断
- NAN 是特例：NAN != NAN，连自己都不等于自己，更不可能当 key
HashMap 查找失效的真实过程
当你执行 map.get(1.0) 时，HashMap 实际做两件事：
- 调用
1.0.hashCode()算出桶位置 - 在该桶内遍历节点，对每个 key 调用
key.equals(1.0)
如果之前存的是计算得来的 0.3 + 0.7（实际可能是 1.0000001），它的 hashCode 和 equals 都与字面量 1.0 不匹配——查找直接失败，不是“没找到”，而是“压根没去那个桶里找”。
替代方案不是没有，但各有代价
真需要以实数值为逻辑 key，可考虑以下方式，但需权衡场景：
-
转成字符串：比如
String.format("%.6f", x)，简单但丢失数值语义，排序/范围查询困难 -
使用 BigDecimal：传字符串构造（
new BigDecimal("1.0")），重写 equals/hashCode 可保障一致性；但对象开销大，不适合高频读写 -
缩放取整：若业务允许误差，例如保留 3 位小数，就用
(long)(x * 1000)当 key，本质转为 long，高效可靠 - 换数据结构：需要区间或近似匹配时，别硬套 HashMap，改用 TreeMap（按值排序）或自定义索引结构
语言层面也在堵这个漏洞
不是所有语言都默许你踩坑：
- Rust 直接禁止 float 类型实现
Eqtrait，编译不过 - Go 允许 float 做 map key，但 NAN 会生成多个独立 key，
2.4和2.4000000000000004被视为不同键 - Java 虽不禁止，但文档和最佳实践明确警告：Double/Float 作为 key 属于反模式
这个问题不难理解，但极易被忽略——尤其在坐标、时间戳、归一化系数等场景下，表面看全是“干净数字”，背后却埋着命中失败的隐患。
