Map和Set在查找、插入、删除上平均时间复杂度均为O(1)，比Object和Array在动态增删、任意类型键/值、有序遍历等场景下更高效；但静态配置或需JSON序列化时Object更适用。
Map 和 Set 在查找、插入、删除操作上平均时间复杂度都是 O(1)，比 Object 和 Array 在多数动态场景下更高效——但这不是绝对优势，关键看你怎么用、数据量多大、键或值的类型是什么。
Map 比 Object 快在哪？
Object 的属性访问看似快，但只在键是字符串且已知存在时才稳定；一旦涉及动态键（比如对象、函数、NaN）、频繁增删、或需要准确计数和遍历顺序，Map 就明显胜出：
- 键支持任意类型：
{id: 1}和{id: 2}可分别作 Map 的两个独立键，而 Object 会全变成"[object Object]"冲突 -
map.size是常数时间获取长度；Object 得靠Object.keys(obj).length或手动计数，开销随键数增长 - 严格按插入顺序迭代；Object 的遍历顺序在混合数字键和字符串键时不可靠（比如
{b: 1, 10: 'x', a: 2}的 keys 可能返回['10', 'a', 'b']） - V8 对 Map 做了哈希表专项优化，避免 Object 隐藏类切换和原型链查找带来的性能抖动
Set 比 Array.includes() 和 Object 模拟集合快在哪？
数组去重或存在性判断，是高频低效区。Set 的设计就是为解决这个：
-
set.has(value)平均 O(1)；arr.includes(value)是 O(n) 线性扫描，10 万条数据查一次可能卡顿 - 不会类型强制转换：Object 模拟
obj[value] = true时，0、false、""、undefined全转成空字符串""，导致误判；Set 保留原始值语义（0 !== false，NaN === NaN在 Set 中被正确视为唯一） - 去重 10 万条 ID：
[new Set(arr)]比arr.filter((v, i) => arr.indexOf(v) === i)快 50 倍以上
什么时候别硬换？Map/Set 不是万能加速器
它们快，但有适用边界。盲目替换反而增加冗余：
- 静态配置、需 JSON 序列化的场景（如 API 请求参数、本地存储），Object 更直接；Map/ Set 不能直接
JSON.stringify，得先转成数组或对象 - 需要索引访问（比如
arr[5]）、切片、排序等操作，Array 仍是首选；Set 没索引，Map 没位置概念 - 数据量极小（
- 要附着元数据到 DOM 节点且不延长生命周期？选
WeakMap，不是 Map；WeakMap 不支持遍历、无 size、键只能是对象
简单对比速查表
以下场景中，推荐优先考虑 Map 或 Set：
- 缓存请求参数对象 → 用 Map（键是对象，不序列化）
- 维护用户黑名单 ID 列表 → 用 Set（
blacklist.has(id)安全又快） - 组件实例 ↔ 渲染状态映射 → 用 Map（键是组件引用，不污染原型）
- 从接口拉取的标签列表去重 → 用 Set（
new Set(tags)一行搞定） - 实现 LRU 缓存 → Map（利用其插入顺序 +
keys().next()快速淘汰最老项）
