map 和 set 不是语法糖，而是解决 object/array 在键类型、去重、遍历、性能上的根本缺陷；map 支持任意类型键且无原型污染，set 基于 samevaluezero 去重并保序，但二者不支持 json 序列化且兼容性受限。
Map 和 Set 不是语法糖，也不能简单当成“升级版对象/数组”来用；它们解决的是传统 Object 和 Array 在键类型、去重逻辑、遍历顺序、性能边界上的根本缺陷。
Map 为什么不能用普通对象替代：键类型与原型干扰
JavaScript 对象的键只能是字符串或 Symbol，而 Map 允许任意类型（包括对象、函数、null、NaN）作为键。更关键的是，Object 会继承 Object.prototype 上的属性（如 toString），导致 for...in 遍历时污染，或 hasOwnProperty 判断失准。
实操建议：
- 当需要以 DOM 元素、React 组件实例、类实例为 key 缓存数据时，必须用
Map，否则对象会自动 toString() 成[object Object] - 避免用
{}模拟字典时写obj.__proto__ = null来规避原型污染——这治标不治本，且破坏可读性 -
Map的size是自有属性，无需手动计数；Object.keys(obj).length无法反映不可枚举属性
Set 如何比 filter + indexOf 去重更可靠
Array.from(new Set(arr)) 是目前最简洁、语义最清晰的数组去重方式，它基于 SameValueZero 算法比较元素，能正确识别 NaN === NaN（而 indexOf 和 includes 在早期引擎中对 NaN 返回 false）。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 不要用
arr.filter((v, i) => arr.indexOf(v) === i)去重：时间复杂度 O(n²)，且在稀疏数组或含undefined/NaN时行为不稳定 -
Set自动忽略重复值，但不会改变原始插入顺序——这点和new Map([...entries]).keys()一致，适合需要保序的场景 - 若需深比较去重（如对象数组），
Set无能为力，得配合JSON.stringify或自定义 key 生成逻辑，这不是Set的设计目标
什么时候不该强行替换：兼容性与语义成本
不是所有对象/数组都该被替换成 Map/Set。比如配置项、响应式数据结构（Vue 的 reactive({})）、JSON 序列化目标，仍应优先用普通对象——Map 和 Set 无法被 JSON.stringify 直接处理，且 Vue/React 的响应式系统对它们的支持有限或需额外包装。
实操建议：
-
浏览器兼容性要求覆盖 IE11？
Map/Set需要 polyfill（如 core-js），而对象/数组天然支持 - 用
Map存储大量键值对（>10k）时，V8 引擎下其查找性能略优于对象，但初始化开销更高；小规模数据差异可忽略 - 别为了“时髦”把
{ status: 'loading' }改成new Map([['status', 'loading']])——语义错位，协作成本陡增
真正容易被忽略的是：Map/Set 的迭代器默认不可 JSON 序列化，且它们的 toString() 输出不具调试友好性（Map {}、Set {}），线上日志里看不出内容。调试时得主动展开或调用 Array.from(map.entries())。
