Map和Set在动态键、任意类型键值、频繁增删、去重等场景下比Object和Array更高效，因底层哈希优化、严格插入顺序、O(1)查找及类型安全相等判断；WeakMap/WeakSet仅适用于弱引用元数据场景。
Map 和 Set 在键值查找、插入、删除操作上确实比普通对象更高效，但“更高效”只在特定场景成立——关键看你要存什么、怎么查、数据量多大。
Map 为什么比 Object 更适合动态键名的键值对
Object 的键只能是字符串或 Symbol，而 Map 允许任意类型（包括对象、函数、NaN）作键；更重要的是，Object 的属性遍历顺序不保证（尤其在旧引擎中），而 Map 严格按插入顺序迭代。
更实际的影响是：当你频繁增删键时，V8 对 Map 做了专门优化，其内部哈希表结构避免了 Object 那种隐藏类切换和原型链查找开销。
-
Object查找obj[key]在 key 是字符串时很快，但若 key 来自someObj.toString()或arr.join()，隐式转换 + 属性存在性检查（hasOwnProperty）会拖慢 -
Map.get(key)直接走哈希定位，对非字符串 key（如{id: 1}）也稳定 O(1) - 大量动态键（比如缓存请求参数对象）用
Map，别用{ [JSON.stringify(obj)]: value }，后者序列化成本高且易冲突
Set 比 Array.includes() 或 Object 键模拟去重快在哪
数组的 includes() 是 O(n) 线性扫描；用 Object 模拟集合（obj[value] = true）虽能 O(1) 查找，但无法区分 0、false、""、undefined ——它们都会被强制转成字符串 ""。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
Set 同时解决这两问题：底层哈希实现保证 O(1) 平均查找，且保留原始值类型与相等语义（0 === -0，但 NaN !== NaN，而 Set 把 NaN 当唯一值处理）。
- 去重 10 万条 ID？
[...new Set(arr)]比arr.filter((v, i) => arr.indexOf(v) === i)快 50 倍以上 - 判断某用户是否在黑名单？用
blacklistSet.has(userId)，别用blacklistObj[userId] !== undefined（如果 userId 可能是0就会出错） -
Set不支持 JSON 序列化，需要转数组再JSON.stringify([...set])
WeakMap / WeakSet 为什么不能简单替代 Map / Set
它们不阻止垃圾回收——键（WeakMap）或值（WeakSet）是弱引用。这意味着：你无法遍历它们，也无法获取大小（size 属性不存在），更不能用非对象作键（WeakMap 键必须是 object）。
适用场景非常窄：仅当你要「附着元数据到某个对象上，且不希望因此延长该对象生命周期」时才用。比如给 DOM 节点存私有状态，节点被移除后，对应元数据自动消失。
-
WeakMap的键不能是string、number、null，传进去会直接报错：TypeError: Invalid value used as weak map key -
Map和WeakMap不能互相替换：前者可遍历、可序列化、键类型自由；后者轻量但功能受限 - 不要为了“听起来高级”而用
WeakSet存用户列表——用户对象很可能被其他地方强引用，起不到释放效果，反而失去.size和遍历能力
性能实测差异到底有多大（V8 10.x+）
小数据量（
真正影响性能的常被忽略：Object 的属性访问在「已知固定键名」时，V8 会内联缓存（IC），比 Map 的哈希计算还快；但一旦键名动态（obj[unknownKey]），IC 失效，性能反超 Map。
- 固定配置项（
config.mode、config.timeout）用const config = { mode: 'fast', timeout: 5000 }，别强行套 Map - 高频更新的实时数据索引（如 WebSocket 收到的用户在线状态）用
Map，尤其是键来自 API 返回的嵌套对象 - 做算法题时，看到「判断是否存在」「去重」「计数」优先想
Set/Map，不是因为“高级”，而是避免手写 O(n²) 循环
const users = [
{ id: 1, name: 'Alice' },
{ id: 2, name: 'Bob' },
{ id: 1, name: 'Alice Updated' }
];
// ❌ 错误：用对象模拟 Map，id=0 会被覆盖
const userMap = {};
users.forEach(u => userMap[u.id] = u); // 若 u.id 是 0，u.id + '' → ''
// ✅ 正确：Map 保持原始键类型
const userMapSafe = new Map();
users.forEach(u => userMapSafe.set(u.id, u));
// ❌ 错误：数组去重靠 includes，O(n²)
const uniqueIds = [];
users.forEach(u => {
if (!uniqueIds.includes(u.id)) uniqueIds.push(u.id);
});
// ✅ 正确：Set 一行搞定，O(n)
const uniqueIdsFast = [...new Set(users.map(u => u.id))];
真正决定效率的不是“用了 Map 还是 Object”，而是你有没有把键的动态性、值的类型多样性、操作频次和规模纳入设计起点。很多性能问题，其实出在过早抽象或过晚重构上。
