Set 和 Map 在前端开发中的性能核心优势是 “高频增删查操作（O (1) 时间复杂度）” ，显著优于数组（O (n)）和对象（部分场景接近但灵活度不足）；但在小数据量下，与数组、对象的性能差异不明显，代码简洁度可优先考虑。下面结合前端实际场景，从「操作性能对比」「影响性能的因素」「实用建议」三方面讲透。
一、核心性能对比（Set/Map vs 数组 / 对象）
前端开发中，查询、新增、删除、遍历 是最常用的四类操作，性能差异主要体现在这四类操作上（时间复杂度越低，性能越好）：
| 操作类型 | Set vs 数组 | Map vs 对象 |
|---|---|---|
| 查询（是否存在 / 取值） | Set.has(x)：O(1)数组.indexOf (x)/includes (x)：O (n) | Map.get(key)：O(1)对象.obj [key]：O (1)（键为字符串 / Symbol 时）但对象无 “判断键是否存在” 的原生 O (1) 方法（key in obj 也 O (1)，但 Map.has 更直观） |
| 新增 | Set.add(x)：O(1)数组.push (x)：O (1)（尾部新增），但去重需先查（O (n)） | Map.set(key, val)：O(1)对象.obj [key] = val：O (1) |
| 删除 | Set.delete(x)：O(1)数组.splice (index,1)：O (n)（删除后需重排） | Map.delete(key)：O(1)delete obj [key]：O (1)，但会残留空属性（性能无差，语义略差） |
| 遍历 | Set.forEach/for...of：O(n)数组.forEach：O (n)（性能接近） | Map.forEach/for...of：O(n)对象 for...in（需过滤原型）：O (n)（性能接近，但 Map 顺序稳定） |
二、前端场景下的性能表现（实操结论）
理论复杂度之外，结合浏览器引擎优化（V8 等），实际开发中性能差异有明确的「场景边界」：
1. 小数据量（≤50 条）：性能差异可忽略，选 “代码简洁” 的
比如表单标签（3-5 个）、少量按钮状态（10 个以内），此时 Set/Map 和数组 / 对象的性能几乎没差别 ——优先用数组（[]）和对象（{}），因为语法更简洁（如 obj.key 比 map.get(key) 写起来快） 。
示例：小数据量用对象更简洁
javascript
运行
// 没必要用 Map（数据量小，性能无差）
const btnStatus = { btn1: false, btn2: true };
// 比 Map 写法简洁：const btnStatus = new Map([['btn1', false], ['btn2', true]]);
2. 中大数据量（≥100 条）：高频增删查用 Set/Map，优势明显
当数据量超过 100 条，且需要「频繁查询（如判断是否存在）、删除（如批量去重）」时，Set/Map 的 O (1) 性能会显著拉开差距 —— 数组的 indexOf/splice 会因 “遍历整个数组” 导致性能下降，数据量越大，差距越明显。
前端典型场景：
- 接口返回 1000 条商品列表，需去重（Set 比数组
filter+indexOf快 10 倍以上）； - 批量上传 100 个文件，记录已上传 ID（Set.has 比数组.includes 快）；
- 接口缓存 100 + 条数据（Map.get 比对象循环查询快，且支持复杂键）。
性能测试示例（浏览器控制台可直接运行）：
javascript
运行
// 测试：大数据量下 Set.has vs 数组.includes
const size = 10000; // 1万条数据
const arr = Array.from({ length: size }, (_, i) => i);
const set = new Set(arr);
// 测试数组.includes（O(n)）
console.time('array-includes');
for (let i = 0; i < size; i++) {
arr.includes(i);
}
console.timeEnd('array-includes'); // 输出：~20ms（不同浏览器略有差异）
// 测试 Set.has（O(1)）
console.time('set-has');
for (let i = 0; i < size; i++) {
set.has(i);
}
console.timeEnd('set-has'); // 输出：~1ms（差距明显）
3. 遍历性能：Set/Map 与数组接近，Map 顺序更稳定
遍历操作（forEach/for...of）中，Set/Map 的性能和数组几乎持平（都是 O (n)），但有两个差异：
- Set/Map 遍历是「按插入顺序」的，Map 比对象遍历更稳定（对象遍历会优先排数字键，顺序不可控）；
- 数组遍历支持更多便捷方法（
map/filter），语法更灵活 —— 如果遍历后需要转换数据，数组更顺手；如果只是单纯遍历键值对，Map 更直观。
4. 引用类型的性能：无额外开销，但需注意 “去重失效”
Set/Map 存储引用类型（对象、数组）时，性能和存储基本类型（数字、字符串）一致（都是 O (1) 操作），但不会自动去重（因为引用地址不同）—— 这是逻辑问题，不是性能问题。
示例：Set 存对象，性能没问题但去重失效
javascript
运行
const set = new Set();
const obj1 = { id: 1 };
const obj2 = { id: 1 }; // 和 obj1 引用不同
set.add(obj1);
set.add(obj2);
console.log(set.size); // 2（性能上 add 是 O(1)，但逻辑上没去重）
三、影响前端性能的关键因素
-
数据量是核心：小数据量（≤50）性能差异可忽略，大数据量（≥100）Set/Map 优势才凸显；
-
操作类型决定优劣：
- 高频「查询是否存在」「删除任意元素」→ 选 Set/Map；
- 高频「尾部新增」「遍历转换」→ 选数组；
- 简单键值对（字符串键）「取值」→ 选对象（语法简洁，性能接近 Map）；
-
浏览器差异极小：现代浏览器（Chrome、Firefox、Edge）对 Set/Map 的优化已非常成熟，性能表现基本一致，无需担心兼容性带来的性能问题；
-
持久化开销：Set/Map 不能直接存 localStorage（需转数组 / 对象），序列化 / 反序列化会有少量性能开销，但这是 “存储方式限制”，不是 Set/Map 本身的性能问题。
四、前端性能优化实用建议
- 小数据量、简单场景：用数组 / 对象（语法简洁，性能足够）；
- 大数据量、高频增删查：用 Set/Map（O (1) 性能，避免数组遍历耗时）；
- 缓存场景（接口缓存、临时状态） ：用 Map（支持复杂键，查询快，顺序稳定）；
- 去重、判断存在场景：用 Set（比数组
filter+indexOf简洁又高效）； - 遍历需转换数据：用数组（
map/filter等方法更便捷）； - DOM 元素绑定数据：用 Map（键为 DOM 元素，无
data-*字符串转换开销，性能更好）。
