Map键为NaN时深拷贝本身不出错，但因SameValueZero算法将所有NaN视为同一键，导致多次set覆盖、语义混淆及检索不可靠，应避免使用NaN作键，改用字符串/Symbol/对象标识。
Map 键名为 NaN 时，深拷贝过程本身不会“出错”，但原始判定一致性隐患其实不来自拷贝动作，而来自 JavaScript 对 NaN 作为 Map 键的底层行为——Map 内部使用 SameValueZero 算法判断键相等，而该算法规定 NaN === NaN 为 true，这看似合理，却掩盖了关键问题：多个 NaN 键在逻辑上无法区分，且无法被常规方式可靠检索。
为什么 Map.set(NaN, val) 看似正常，却埋下判定隐患
Map 允许 NaN 作为键，且能成功存入：
-
const m = new Map(); m.set(NaN, 'a');—— 执行无报错 -
m.has(NaN)返回true，m.get(NaN)能取到'a' - 但注意：
NaN不是唯一值，它没有身份标识（identity），所有NaN在 SameValueZero 下被视为“同一个键”
深拷贝后，原始判定逻辑可能意外失效
当你用 structuredClone 或其他深拷贝手段复制含 NaN 键的 Map 时：
-
structuredClone正确保留NaN键（因为它是可克隆值），拷贝后clone.has(NaN)仍为true - 隐患在于：若原始代码依赖“不同
NaN实例代表不同语义”，比如：
通过Object.is(NaN, someDynamicValue)判断来源，则拷贝前后这种判断完全失效——因为所有NaN都被归一化处理 - 更隐蔽的是：若原 Map 中曾多次
set(NaN, x)，实际只保留最后一次赋值（键冲突覆盖），而开发者可能误以为每次 set 都新增条目
如何主动识别并规避该隐患
不要等到深拷贝后才发现逻辑异常。应在设计阶段检查：
- 用
Array.from(m.keys()).filter(k => Number.isNaN(k))检查是否存在NaN键，统计数量；若结果长度 > 1，说明已有覆盖，原始数据已失真 - 避免用
NaN表达业务状态（如“未知”“缺失”“计算失败”）；改用字符串标识（'MISSING'）、Symbol 或包装对象（{ type: 'NaN_ERROR' }） - 若必须保留
NaN键，深拷贝后应立即验证：const k = NaN; clone.has(k) && Object.is(clone.get(k), original.get(k))，不能只信has
