Map比对象更适合缓存容器，因其键支持任意类型（含DOM节点、函数等引用）、严格保留插入顺序、size属性O(1)获取长度、无原型污染风险；Set去重和查存在为O(1)哈希查找，远快于数组O(n)线性查找。
Map 为什么比对象更适合当缓存容器？
当你需要把 DOM 节点、React 组件实例、函数或任意对象当“键”来存数据时， 数组的 不是“更高级”，而是“非它不可”。对象和数组在这些地方会出错或不可靠： 立即学习“Java免费学习笔记（深入）”； 真正容易被忽略的点是语义明确性：写 Object 会立刻失效——因为 obj[node] 实际触发 node.toString()，所有 "[object HTMLDivElement]"，导致数据覆盖。Map 没这问题，它认的是引用本身。
map.set({id: 1}, 'data') 和 map.set(() => {}, 'fn') 都合法且互不干扰for (const [k, v] of map) 总是按添加顺序返回，而 Object.keys() 对数字字符串键（如 "2"、"10"）会自动升序排列
map.size（O(1)），不用每次调用 Object.keys(obj).length（生成新数组，O(n)）map.get('constructor') 不会误匹配原型方法；obj.constructor 却可能被覆盖或继承干扰Set 去重和查存在，为什么比数组
includes() 快得多？includes()、indexOf()、filter() 全是 O(n) 线性查找；Set.prototype.has() 是平均 O(1) 的哈希查找。10 万条用户 ID 中判断某个 ID 是否已存在，set.has(id) 几乎无感，arr.includes(id) 可能卡顿明显。
[...new Set(arr)] 或 Array.from(new Set(arr))，一行搞定，且初始化即完成去重set.has(x)，别写 arr.includes(x) 或 arr.indexOf(x) > -1
new Set([{a:1}, {a:1}]) 存两个，因每次 {} 是新引用；要用同一对象引用才能命中Set 不支持索引访问：set[0] 是 undefined；要取第 n 个值，得先转数组：[...set][n]
哪些场景必须用 Map/Set，不能硬套对象或数组？
const nodeCache = new Map(); nodeCache.set(divEl, { expanded: true }) —— 用 Object 就全变成 "[object HTMLDivElement]"
const pendingRequests = new Set(); if (!pendingRequests.has(url)) { pendingRequests.add(url); /* 发请求 */ }
add/delete 频繁 + 需快速 has 判断 + 插入顺序重要 → Set 比 filter 或 findIndex 稳定高效const allowedActions = new Set(['read', 'edit', 'delete']); if (allowedActions.has(action)) { ... } —— 比 ['read','edit'].includes(action) 更快更语义清晰JSON 序列化和遍历要注意什么坑？
Map 和 Set 都不支持 JSON.stringify() 直接序列化——它们不是 plain object，也没有可枚举的自有属性。
JSON.stringify([...myMap]) 得到 [["k1","v1"],["k2","v2"]]；还原时写 new Map(JSON.parse(str))，不是 new Map(JSON.parse(str)[0])
for (const [k, v] of myMap) 或 myMap.entries() 返回的是迭代器，内存友好；Object.entries() 每次都返回新数组const [[firstKey, firstVal]] = myMap; —— Object 不支持这种写法Map/Set 底层哈希实现比 Object 属性动态分配、Array 线性扫描更稳定new Map()，别人立刻知道这是动态键值关系；写 new Set()，就知道这个集合必须唯一。而 const cache = {} 或 const list = []，永远需要读注释或上下文才能确认意图。
