1. 项目概述
做前端的人，尤其是写了好几年业务代码的人，对Map和Set一定不陌生。但我发现一个很有意思的现象：很多同学面试时会背概念，说起"ES6新增了Map和Set，Map是键值对集合，Set是去重集合"头头是道，可真正落到项目里，最常用的数据结构依然是{}和[]，Map和Set常年吃灰。
说实话，这有点浪费。
这两个数据结构不是锦上添花的语法糖，在某些场景下它们能明显提升代码的可读性和性能。我自己是从一次排查线上Bug的经历里真正建立起对它们的好感的——当时有个同事用对象去缓存接口数据，key是字符串拼接的请求参数，结果在某个参数里混进来了__proto__这个字符串，整个缓存对象瞬间被污染，页面白屏了半小时。后来换成Map，同样的逻辑干干净净，问题再没出现过。
这篇文章不打算做枯燥的API罗列。我会直接跳到"什么时候该用Map、什么时候该用Set"这个最实际的问题上，结合项目里的真实场景，把我的踩坑经验和选型方法一次性讲清楚。想系统梳理ES6集合类型的读者，或者工作中常和数据映射、去重逻辑打交道的开发者，应该都能从里面拿到一些能直接用的东西。
1.1 核心需求解析
先把这两个东西的基本定位说清楚。
Map解决的是"键值对映射"的需求，它的本质是一个真正的哈希表实现。和普通对象{}相比，它的键不再被强制转换成字符串，可以是任意类型——对象、数组、函数都能当键。这一个特性就打开了很大的想象空间。
Set解决的是"不重复集合"的需求。它天然保证集合内的元素唯一，同时提供了近乎O(1)的查找和删除能力，这在大量数据场景下比数组的indexOf要快好几个数量级。
一句话概括我的使用原则：需要动态增删键值对、键的类型不固定，优先用Map；需要维护一个唯一集合、频繁判断某个值是否存在，优先用Set。
1.2 为什么对象和数组不够用
聊到Map和Set，很多人的第一反应是：对象和数组不也能干这些事吗？这个疑问我理解，因为从表面上看功能确实有重叠。但在真实的工程场景里，它们各自有很难绕过去的短板。
对象的第一个问题，我已经在上面提到了——键名只能是字符串和Symbol。你如果写obj[true] = 1，引擎会把true转成字符串"true"存起来；写obj[{}] = 2，这个对象会被转成"[object Object]"。这里还有个隐藏的巨大隐患：当键名恰好是"__proto__"、"constructor"这类名字时，对象的行为会变得非常不可预期，甚至直接改变原型的指向，造成原型链污染。
数组的问题在于查询效率。判断一个值是否在数组里，最常用的includes或indexOf都是线性遍历，数组越大，耗时越长。而Set的底层是哈希表，查找的时间复杂度在O(1)，差距在数据量上来之后会非常明显。
这不是我凭空说数据吓人——曾经在一个权限系统里，需要频繁判断用户是否在某个角色组里，角色组有几万个UID，用数组includes一次要几毫秒，换成Set之后单次判断直接降到微秒级别，接口从超时变成秒回。
对象和数组不是不能用，但在这些特定场景下，Map和Set确实是不做第二选的更优解。
2. Map使用场景拆解
2.1 任意类型作为键：真正的哈希映射
Map最区别于普通对象的一点，就是键可以是任意类型，而且严格按引用相等来判断。这一点初看只是语法层面的放宽，实际带来的能力是全方位的。
举例来说，我需要统计页面上不同DOM节点的点击次数，如果用对象来做，必须先给每个节点设一个唯一ID字符串，然后obj[uid]++，操作很笨重。用Map的话不绕弯子，直接拿DOM节点本身当键：
const clickCountMap = new Map(); document.querySelectorAll('.btn').forEach(btn => { btn.addEventListener('click', () => { clickCountMap.set(btn, (clickCountMap.get(btn) || 0) + 1); }); });再比如缓存场景，你有一个由配置对象计算出的结果，后续多次调用时想复用。如果每次都用对象的JSON字符串做key，一旦对象的字段顺序不同，就会导致缓存不命中。用Map的话，直接把这个配置对象当作键存进去，只要传入的是同一个引用，就能命中缓存。
最常见的还是配合函数式编程里的memoization。下面是一个用Map实现的高阶缓存函数：
function memoize(fn) { const cache = new Map(); return function(...args) { const key = args[0]; if (cache.has(key)) { return cache.get(key); } const result = fn(...args); cache.set(key, result); return result; }; }这里args[0]可以是一个对象，换成普通对象缓存就没办法实现。注意cache.has这一行，Map的has方法等价于一个O(1)的哈希查找，在做"存在性判断"时非常顺手，这也是对象做不到的干净接口。
注意：用引用类型做键，用的是引用地址来判断"同一个键"，不是内容深比较。你传两个结构相同但不是同一个引用地址的对象进去，在Map里会被当作两个不同的键，这一点务必记住，否则缓存和统计都会出现难以排查的错误。
2.2 遍历顺序：插入序保证
普通对象即便在现代JavaScript里已经做到字符串键按插入顺序遍历，但整数键和字符串键的遍历顺序和分组规则并不完全统一，很容易让人摸不着头脑。数字键在前，字符串键在后，Symbol键躲在最后，这个顺序在一些业务逻辑里根本不敢依赖。
Map的遍历严格按照插入顺序，先插入的先被遍历到。这个特性在需要记录操作历史、按时间序列处理数据时，天然契合。
Map本身就搭载了三个遍历方法：keys()、values()和entries()，而且它们都返回迭代器，可以被for...of直接消费，配合解构赋值可以写出很简洁的循环体：
const userScores = new Map([ ['张三', 85], ['李四', 92], ['王五', 77] ]); for (const [name, score] of userScores) { console.log(`${name}: ${score}`); }新手比较容易忽略的是迭代器是支持解构的。将userScores直接展开成数组，得到的就是二维数组数组；再配合fromEntries，又能轻松把Map转回普通对象：
const arr = [...userScores]; // [['张三', 85], ['李四', 92], ['王五', 77]] const obj = Object.fromEntries(userScores); // { 张三: 85, 李四: 92, 王五: 77 }这个"Map转对象"的操作在实际开发里很常用——接收到的数据是Map，但后端接口需要JSON对象，一行代码搞定。反过来，Object.entries(obj)配合new Map()也能干净地把对象转成Map：
const map = new Map(Object.entries({ a: 1, b: 2 }));2.3 性能差异要点
很多文章喜欢提Map性能比对象好，这是一个不严谨的说法。严谨的说法是：在"动态增删键值对"的场景下，Map的性能表现稳定；在"静态读写已知属性"的场景下，对象反而更快。
为什么？因为普通对象在创建的时候，引擎（比如V8）会对对象进行所谓的"隐藏类"优化，如果属性结构固定且不变更，访问属性可以直接通过偏移量计算，速度飞快。而一旦你频繁动态添加或删除属性，隐藏类就会失效，引擎不得不退化为字典模式，性能就会下降。Map本身就是一个专门为频繁增删优化的哈希表，不存在这种分发逻辑，所以在高频率的动态操作下，Map能提供更稳定的表现。
有个典型的性能误区：反复在对象上做delete操作。当你在对象上删除属性，引擎没法继续使用隐藏类优化，后面的一切读取都会变慢。而Map专门提供了delete方法，底层设计就是为了应对这类高频增删的场景。
提示：如果你有一个结构固定的对象，只是反复读取它的属性，别换成Map，对象就很好。Map的性能优势体现在动态操作上，不要为了用而用。如果你的代码有严重的性能瓶颈，建议先用开发者工具做性能分析，找到热点再优化，不要盲目替换数据结构。
3. Set使用场景拆解
3.1 数组去重的正确写法
Set最广为人知的用法就是去重，用法特别简短：
const arr = [1, 1, 2, 3, 3, 4, 5, 5]; const unique = [...new Set(arr)]; // [1, 2, 3, 4, 5]一行代码搞定，清晰明了。但这背后有两个细节容易踩坑。
第一个坑是关于对象去重的。new Set(arr)对对象的去重效果，是基于引用相等判断的，两个内容完全相同但引用不同的对象，会被当作不同的元素保留。如果你有这个需求，比如按对象的id字段去重，必须手动写逻辑，例如用Map记录已经出现过的id，再决定是否保留当前项。
第二个坑涉及到NaN。在大多数人的认知里，NaN !== NaN，但Set内部用于判断两个值是否相等的算法比较特殊，它认为NaN等于自身，因此多个NaN会被合并为一个。这个行为其实是符合业务直觉的，毕竟在去重场景里，你几乎不会希望出现两个NaN。
3.2 快速成员判断
去重只是Set的表层用法。更核心的价值在于它的has方法，能提供近乎O(1)的成员判断能力。这是一个我认为被严重低估的场景。
举一个更贴近业务的具体例子。在表格组件里，经常需要支持"选中行"和"全选/全不选"的交互。如果你用一个数组来维护所有选中行的ID，每次判断某行是否被选中都要调用includes，数组越长越慢；而且切换选中状态的时候，增加用push，删除用splice，代码里还要处理索引查找，非常啰嗦。
用Set来维护选中状态就舒服得多：
const selectedIds = new Set(); function toggleSelect(id) { if (selectedIds.has(id)) { selectedIds.delete(id); } else { selectedIds.add(id); } } function isSelected(id) { return selectedIds.has(id); }has判断是否存在，add增加元素，delete删除元素，三个操作全部是O(1)复杂度，性能在大量行数据下也能稳定扛住。代码意图读起来也清晰，不需要额外的注释。
另一个我常遇到的场景是标签体系的白名单校验。比如用户提交一组标签，我们需要过滤掉不在预设白名单里的标签。用Set装白名单，判断速度和非白名单剔除的位置都是一行代码：
const allowedTags = new Set(['tech', 'life', 'work']); const userTags = ['tech', 'random', 'work', 'unknown']; const filtered = userTags.filter(tag => allowedTags.has(tag)); // ['tech', 'work']反过来，如果要找用户上传标签中新增了哪些白名单外的标签，用Set的差集操作思路来做，也非常直观。先把用户标签转换为Set，然后遍历过滤出不在allowedTags中的项即可。
3.3 集合运算模拟
Set提供的另一个实用价值，是可以很方便地模拟集合论中的交集、并集、差集运算。JavaScript原生没有这些API，但用Set和展开语法组合，代码比想象中的还要简洁。
const setA = new Set([1, 2, 3, 4]); const setB = new Set([3, 4, 5, 6]); // 并集 const union = new Set([...setA, ...setB]); // {1, 2, 3, 4, 5, 6} // 交集 const intersection = new Set([...setA].filter(x => setB.has(x))); // {3, 4} // 差集（A - B） const difference = new Set([...setA].filter(x => !setB.has(x))); // {1, 2}这里依赖的是展开运算符会把Set的迭代器结果铺成数组，filter里再做一次哈希判断。交集和差集的复杂度都是O(n)，很高效。
这三个运算组合起来能覆盖不少真实需求。比如权限管理里，一个用户拥有的权限集合和某个角色要求的权限集合之间，不仅可以直接对比是否相等，还能快速算出"缺少哪些权限"（差集）用来提示用户；在两个数据源的ID列表之间求公共部分（交集），也是Data同步场景里的高频操作。
4. WeakMap与WeakSet实战
4.1 内存管理的变化
讲到Map和Set，就绕不开它们各自的"弱引用兄弟"WeakMap和WeakSet。它们和Map/Set最大的区别是：key上的引用是弱引用，不会被垃圾回收机制计入引用计数。
这句话怎么理解？用Map存对象，只要这个Map还活着，被存进去的对象就一直被强引用着，永远不会被回收。这在某些场景会造成内存泄漏。而WeakMap持有的是对象的弱引用，如果程序里除了WeakMap之外，没有任何地方再引用这个对象，垃圾回收器会在合适的时机把它收掉。
但这带来一个限制：WeakMap和WeakSet的key必须是对象，不能是基本类型，且它们没有size属性、不支持遍历。弱引用的对象随时可能被回收，所以遍历没有意义，这是设计取舍。
如果需要用Map存对象且希望它能被垃圾回收释放，应该用WeakMap。反过来说，如果你需要反复遍历查看当前存了哪些键——比如调试时想看看缓存里有什么——那就老老实实用Map，WeakMap做不到。
4.2 私有数据缓存
WeakMap最典型的工程场景就是给对象绑定私有数据，同时又不影响该对象的生命周期。我用一个具体的例子来说明。
假设你需要维护一个"用户在线状态"的模块，每个用户是一个对象，你要记录他的登录时间戳。如果用Map，用户登出后，即使把用户对象置为null，Map里的引用还会把对象强留着，造成无法回收。用WeakMap，登录记录和用户对象的生命周期绑定在一起，用户对象被清除，登录记录也会随之消失：
const loginTimeMap = new WeakMap(); function login(user) { loginTimeMap.set(user, Date.now()); } function logout(user) { loginTimeMap.delete(user); } function getLoginTime(user) { return loginTimeMap.get(user); }代码层面没有区别，但内存上，WeakMap不会成为内存泄漏的源头。类似的场景还有DOM元素和组件状态信息的绑定——组件卸载后，DOM节点消失，相关的状态信息也会被回收，不会因为Map里的残留引用来造成泄漏。
另外，很多优秀的库也把WeakMap用于实现私有字段数据存储。公共API暴露出来的对象身上，不希望调用者能改到内部的敏感字段，就把它存在WeakMap里，以对象实例为key，外部自然无法访问。这也算一种替代Class私有属性的思路。
5. 高频业务场景组合玩法
5.1 数据统计与日志聚合
在实际项目中，Map和Set常常组合在一起用，能解决不少复杂业务问题。我说一个自己处理过的日志分析的case。
有一次需要统计某个接口在一天内被不同用户调用的次数，以及究竟是哪些用户调的。当时原始日志是一行行的记录，每条包含userId和time。我的第一版实现用了两个普通对象分别存计数和用户去重列表，结果因为整体逻辑里加了太多变量，读起来维护的人都头疼。后来统一改成Map+Set组合，代码立刻变得清爽：
const stats = new Map(); // key: userId, value: { count, times: Set } for (const log of logs) { if (!stats.has(log.userId)) { stats.set(log.userId, { count: 0, times: new Set() }); } const record = stats.get(log.userId); record.count++; record.times.add(log.time); }最后只需要遍历stats，就能得到每个用户的调用次数和去重后的调用时间点集合。这个组合的核心思路在于：外层用Map做用户维度的映射，内层用Set做时间点的去重集合，两层各司其职，组成了清晰的存储结构。类似的结构在很多看板、监控类的业务里都适用，例如统计商品维度的订单量（Map），同时去重统计有哪些用户买过（Set）。
5.2 两级缓存模型
另一个我自己在项目里用过多次的模型是"Map+对象存储"的两级缓存。
当数据量较大、每次获取需要做一次较重的计算时，可以使用Map做内存级缓存，同时用一个普通对象做元数据描述。Map保证了按key查找的高效性和遍历的顺序性，而普通对象存一些描述信息，比如创建时间、过期时间、访问计数等，代码的组织比大杂烩清晰不少。
const cache = new Map(); function getProductInfo(productId) { if (cache.has(productId)) { return cache.get(productId); } const info = fetchProductFromRemote(productId); // 模拟远程请求 cache.set(productId, info); return info; }当我们需要给这个缓存加"基建"，比如记录每个产品信息的过期时间，直观做法是把过期时间存在一个平行的Map里，同一个productId同时出现在两个Map中。这种做法功能上没有大问题，但要保证两个Map同步增删，责任分明，稍不留神就会漏一处。
我在实际项目里更喜欢用Map + 对象的方式来包装，把映射关系和元信息收敛在一个结构里，虽然这只是编码习惯上的取舍，但对代码维护来说体验明显更好。你可以在Map的值里直接放一个对象，把"业务数据"和"元信息"都装进去，整体易读性上升一个台阶。
6. 常见问题排查与避坑经验
6.1 对象和Map混用导致的Bug
我见过最频繁的坑，是把改造成Map之后的部分代码遗留成了对象，不同模块之间各用各的，最后在某个公共函数里，一种数据结构被两种方式同时操作，直接乱套。
建议的做法是：在一个模块内，只用一种集合类型；公共工具函数，优先声明清楚入参出参的集合类型。哪怕只是内部小项目，也需要统一规范。特别是在Map和对象转换时要注意，Object.fromEntries(map)从Map生成的对象，键会被强制转成字符串，如果原来是数字键，这一步会丢失数字的类型信息，后续如果又拿它去Map.get(1)，会查不到，因为此刻存在的是字符串"1"。
6.2 Set去重时对象引用陷阱
我在前面的去重小节提到过，Set对对象的去重是基于引用相等。再次强调，因为这是容易在业务里直接导致Bug的点。
举个例子：
const objArr = [{ id: 1 }, { id: 1 }, { id: 2 }]; const uniqueArr = [...new Set(objArr)]; // length 仍是 3如果你期望的结果是两个（id去重），用Set直接去重显然达不到目的。这时候需要用Map按id聚合，再取出值列表：
const map = new Map(objArr.map(obj => [obj.id, obj])); const uniqueArr = [...map.values()]; // [{ id: 1 }, { id: 2 }]这里用map的构造参数一次完成映射，key是id，value是该对象。由于后续相同id的对象会覆盖前面的，天然实现了按id去重，最后用values()取回对象列表。这个写法简洁且不容易踩坑，建议直接收藏。
注意：
values()返回的是迭代器，要拿到数组必须配合展开运算符或Array.from。很多人会忘记这一步，直接返回迭代器被JSON序列化，结果得到一个空对象或者报错，这种问题排查起来非常费时间。
6.3 Map与JSON序列化的坑
Map默认不能被JSON.stringify正确序列化。直接对整个Map执行这个操作，会得到{}。原因是JSON的序列化器不认识Map内部的数据结构，只把它当作一个空对象处理。这在把Map数据发送到后端或者存localStorage时会造成bug（静默丢失数据），很难被发现。
解决方案不麻烦，先转成数组再序列化：
JSON.stringify([...map]); // 序列化成二维数组后端收到之后，再用new Map(data)还原。这比转成普通对象更安全，因为普通对象会丢失键的类型信息。
同样的道理，从服务端拿到的JSON也不能直接new Map(json)，要先走Object.entries(json)变成二维数组。否则构造器拿到的不是可迭代的键值对列表，行为会跟你预期完全不一样。
6.4 扩展小技巧：Map和Set的迭代器善用
最后分享一个我自己平时用得比较多的技巧。因为Map和Set都实现了Symbol.iterator，所以它们能直接用于for...of，也能被展开成数组，还能和解构赋值配合。
比如在需要批量删除Set里某些元素时，完全可以先过滤再重建：
const set = new Set([1, 2, 3, 4, 5]); const filtered = new Set([...set].filter(n => n % 2 === 0)); // {2, 4}Map的批量更新也讲究一次性构造：
const updatedMap = new Map([...map].map(([key, value]) => { return [key, value * 2]; }));不过真正直接用的时候，我不建议图省事而频繁倒腾数组和集合结构。这个转换有一定开销，改动本身也很直观。在性能无所谓的场景里，清晰好看完全没问题；如果数据量大到需要敏感对待性能，还是尽量用原生迭代器方法做增量更新，避免反复内存拷贝。
7. 写在最后的实践建议
从Map和Set这两个结构本身来看，它们不是多么高端的东西。但在工程上，选对数据结构往往比写对算法还要重要——因为数据结构决定了后续代码的写法、可读性、性能边界和内存表现。我自己在带项目或者Code Review的时候，通常会特别留意同事对集合类型的使用，发现该用Set的地方用数组反复includes，或者用对象当Map用还去拼接字符串键，都会顺手改掉。
个人体会比较深的一条是：不要为了用Map而用Map，也不要为了显得高级而去替代已经能正常工作且清晰易懂的对象或数组写法。数据结构的选择只有一个标准——合适。键的动态性、类型的任意性要求下，Map合适；唯一性、快速判断存在性要求下，Set合适；结构固定的共享对象，普通对象完全合适。
这篇文章里所有的例子都是我在真实项目里用过或者帮同事改过的问题，你可以直接拿来当参考。如果有不同的经验或者踩到我没写过的坑，欢迎交流。互相补充，比一个人闷头踩坑高效得多。
