map对nan和-0的键判定遵循samevaluezero算法：所有nan被视为同一键导致覆盖，+0与-0被强制等价，虽符合规范但会掩盖语义差异，需用字符串或对象封装规避。
map 对 nan 和 -0 的键判定遵循 ecmascript 规范中的 samevaluezero 算法，不是普通 ===，但也不是完全自定义逻辑。识别它们的边界表现，关键在于理解“相等”何时成立、何时掩盖差异、以及哪些操作会暴露隐含限制。
NaN 作为键：表面一致，实则无区分能力
所有 NaN 值在 Map 中被视为同一键，无论来源（0/0、Math.sqrt(-1)、Number("abc")），只要被用作键，就会相互覆盖：
-
map.set(NaN, "first"); map.set(NaN, "second");→ 最终只保留"second" -
map.get(NaN)能取到值，但无法反向确认该值对应的是第几次 set 的 NaN -
Array.from(map.keys())中最多出现一个NaN，且无法用===安全比对，需用Number.isNaN()检测
-0 与 +0：严格等价，但语义可分离
Map 明确将 -0 和 +0 视为相同键，这是规范行为（非 bug）：
-
map.set(+0, "positive zero"); map.get(-0)→ 正确返回"positive zero" -
Object.is(+0, -0)返回false，但 Map 内部不使用Object.is，而是 SameValueZero（其中+0 === -0为 true） - 若业务需区分正负零（如温度、方向、金融符号位），Map 不适合直接建模；应改用字符串键（
"+0"/"-0"）或包装对象（{ value: 0, sign: "-" }）
如何主动识别这些边界是否已影响逻辑
不要等到出错才检查。可在初始化后或关键路径中插入轻量探测：
- 检查 NaN 键是否已被覆盖：
const nanKeys = Array.from(map.keys()).filter(Number.isNaN); if (nanKeys.length > 1) { /* 实际不可能，说明数据构造有误 */ } - 验证 -0/+0 是否被意外合并：
map.set(+0, "a"); map.set(-0, "b"); console.log(map.size); // 输出 1，而非 2 - 遍历时注意键类型不可靠：
for (const key of map.keys()) { if (key === 0) { /* 匹配 +0 和 -0，但无法得知原始符号 */ } }
替代方案建议
当 NaN 或 -0 的“零相等”特性与业务语义冲突时，优先绕过而非对抗：
- NaN 场景 → 改用
'NaN'字符串、Symbol('MISSING')或{ type: 'NaN', origin: 'parse-fail' } - -0/+0 场景 → 使用带符号字符串键：
map.set(String(value), ...)，或封装成{ raw: value, sign: Math.sign(value) || (Object.is(value, -0) ? -1 : 0) } - 通用原则：Map 的键设计应以“可预测、可调试、可序列化”为前提，避免依赖底层算法的特殊例外
