JS数组去重方法性能对比：Set、Map与Filter谁更快

一、核心结论：三类方案性能梯队与数据量级表现

为了直观评估不同去重方案的运行开销，我们在标准 V8 执行环境（Node.js / 现代浏览器）中，对包含 30% 重复基础值（数值与短字符串）的随机数组进行了对比评测。不同量级下的典型表现如下表所示：

从数据可以看出，在千级以内的小规模数组中，三者的绝对耗时均在 2 毫秒以下，用户交互几乎无法感知其差别。然而一旦规模扩大至 10 万级，filter + indexOf 的耗时便直接飙升至十余秒，导致浏览器主线程严重冻结或 Node.js 服务事件循环阻塞；而 Set 与 Map 依旧维持在几十毫秒的平稳区间内。

二、三种去重方案的代码实现与运行机制

为什么执行速度会出现如此悬殊的差距？核心原因在于底层引擎所采用的数据结构和查找算法机制截然不同。

1. Set 集合去重：原生的 O(N) 哈希构建

使用 ES6 引入的 Set 配合扩展运算符（Spread Operator）或 Array.from 是目前业界最通用的数组去重语法：

// 方式 A：展开运算符（最精简）
const uniqueWithSet = arr => [...new Set(arr)];

// 方式 B：Array.from（语义明确）
const uniqueWithSetFrom = arr => Array.from(new Set(arr));

底层原理：Set 内部基于哈希表（Hash Set）实现。当通过迭代器向 Set 添加元素时，V8 引擎通过哈希函数直接计算元素所落入的哈希桶位置。判断元素是否已存在只需均摊 O(1) 的查表操作。将包含 $N$ 个元素的数组完整推入 Set，仅需执行 $N$ 次哈希定位，总时间复杂度严格维持在 O(N)。

2. Map 键值过滤：带业务语义的 O(N) 映射

Map 去重通常通过 filter 或遍历单次维护一个哈希字典，常用于根据某一业务主键进行过滤：

// 对象数组按 id 字段去重
function uniqueByMapKey(arr, keyName) {
  const seen = new Map();
  return arr.filter(item => {
    const val = item[keyName];
    if (seen.has(val)) {
      return false;
    }
    seen.set(val, true);
    return true;
  });
}

底层原理：Map 同样采用哈希字典，seen.has() 与 seen.set() 均为均摊 O(1) 操作。整个数组仅被遍历一次，外层循环 $N$ 次，内部查表 $N$ 次，因而总体复杂度同样是 O(N)。由于每次迭代需要额外进行属性访问（item[keyName]）和函数闭包调用，其绝对耗时比原生的 Set 略慢 30%~50%，但远快于二次方复杂度的算法。

3. filter + indexOf：双层嵌套的 O(N²) 扫描

在 ES6 普及前，这是前端最常见的去重实现：

// 传统 indexOf 过滤
const uniqueWithFilter = arr => arr.filter((item, index) => arr.indexOf(item) === index);

底层原理：filter 本身是一个长度为 $N$ 的外层线性循环；在每一次迭代中，arr.indexOf(item) 又会从数组索引 0 开始向后逐个比对，直到找到第一个相等元素。对于第 $k$ 个元素，indexOf 最多需要比对 $k$ 次。总比对次数近似为 $1 + 2 + \dots + N = rac{N(N+1)}{2}$，属于典型的二次方级别 O(N²)。数据规模每扩大 10 倍，运算量便暴增 100 倍。

三、性能基准测试设计与复现代码

为了避免外界测试因 JIT 编译未完成、内存垃圾回收干扰或测试样本偏颇产生失真，设计性能基准测试时需要遵循标准化流程。

读者可将以下完整测试脚本保存为 benchmark.js，使用 Node.js（建议 v16+）直接运行，亲自验证各项耗时：

// benchmark.js：数组去重性能测试基准脚本
const { performance } = require('perf_hooks');

// 1. 生成可控测试数据（指定数据规模与重复率）
function createTestData(size, duplicateRate = 0.3) {
  const uniqueCount = Math.floor(size * (1 - duplicateRate));
  const pool = Array.from({ length: uniqueCount }, (_, i) => `item_${i}`);
  const result = new Array(size);
  for (let i = 0; i < size; i++) {
    const randIndex = Math.floor(Math.random() * uniqueCount);
    result[i] = pool[randIndex];
  }
  return result;
}

// 2. 去重算法定义
const algorithms = {
  'Set 原生去重': arr => [...new Set(arr)],
  'Map 辅助去重': arr => {
    const map = new Map();
    const res = [];
    for (let i = 0; i < arr.length; i++) {
      const val = arr[i];
      if (!map.has(val)) {
        map.set(val, true);
        res.push(val);
      }
    }
    return res;
  },
  'Filter+indexOf': arr => arr.filter((item, idx) => arr.indexOf(item) === idx)
};

// 3. 隔离测量函数
function measure(fn, data, iterations = 10) {
  // 预热环境
  for (let i = 0; i < 3; i++) {
    fn(data.slice(0, 500));
  }

  const times = [];
  for (let i = 0; i < iterations; i++) {
    const start = performance.now();
    const output = fn(data);
    const end = performance.now();
    times.push(end - start);
  }

  // 剔除最高值与最低值后计算均值
  times.sort((a, b) => a - b);
  const trimmed = times.length > 2 ? times.slice(1, -1) : times;
  const avg = trimmed.reduce((sum, v) => sum + v, 0) / trimmed.length;
  return avg.toFixed(3);
}

// 4. 阶梯运行与报告
function runSuite() {
  const sizes = [1000, 10000, 50000];
  console.log('=== JavaScript 数组去重基准测试 ===\n');

  for (const size of sizes) {
    console.log(`[测试规模: ${size.toLocaleString()} 项]`);
    const data = createTestData(size, 0.35);

    for (const [name, fn] of Object.entries(algorithms)) {
      // 5万规模下 filter+indexOf 耗时极长，限制迭代次数
      const iters = (size >= 50000 && name.includes('Filter')) ? 2 : 10;
      const cost = measure(fn, data, iters);
      console.log(`  - ${name.padEnd(16)}: ${cost} ms`);
    }
    console.log('');
  }
}

runSuite();

四、常见认知误区与边界条件辨析

在实际工程讨论中，关于数组去重常出现几类看似合理、实则存在隐患的说法。理解这些细节能够避免在生产环境中踩坑。

误区一：“数据量小的时候用哪个都一样，没必要纠结”

为什么看似合理：当数据项只有几十个时，filter + indexOf 的执行耗时确实在 0.1 毫秒以下，完全不会造成前台掉帧。

修正与边界：这种观点忽略了数据规模的不可控增长。前端应用中的列表往往来自后端分页或动态导入，如果数据源未做截断或用户导入了万行 Excel，写在核心渲染链路中的 O(N²) 代码将立刻演变为界面假死的主因。统一团队规范优先使用 Set，不仅开发心智负担低，而且具备对输入规模激增的天然弹性。

误区二：“Set 能搞定所有类型的去重”

为什么看似合理：在处理数字、字符串等原始类型时，new Set() 表现完美，代码极为优雅。

修正与边界：Set 内部使用的是 SameValueZero 判定算法。对于引用类型（对象、数组），它比较的是对象的内存引用地址，而非内部数据结构。

• 两个完全同名同值的对象 { id: 1 } 与 { id: 1 }，若引用地址不同，Set 会认定为不同元素，两者均会被保留。
• 特例表现：NaN 在常规 === 判定中 NaN !== NaN，但在 Set 中会被视作相同元素并成功去重；+0 与 -0 同样会被视作相同元素。

误区三：“用普通对象字面量（Object）缓存比 Map 更快”

为什么看似合理：在 ES5 时代，常使用普通对象 const obj = {} 来模拟哈希表（obj[item] = true），其语法轻量。

修正与边界：普通对象的 Key 会被隐式强制转换为字符串，这会导致严重的数据误并：数值 1 与字符串 '1' 会共用 '1' 这个键而发生错误去重。此外，普通对象带有 toString、valueOf 等原型链属性，若数组中包含 '__proto__' 等字符串键名，容易引发不可预期的原型污染或取值异常。现代 V8 引擎中 Map 针对哈希键查找专门做了底层高度优化，不仅能安全区分任意数据类型，在吞吐量上也更加稳定。

五、选型指南与工程实践建议

综合性能表现、代码可读性与安全性，在工程开发中建议遵循以下决策逻辑：

1. 基础类型数组（数字、字符串、布尔）：坚决首选 [...new Set(arr)]
   代码最少、意图最明确、时间复杂度 O(N)，能够应对从几十到百万级的各类规模。
2. 业务对象数组按主键去重：使用 Map 辅助过滤
   通过 seen.has(item.id) 判断，兼顾了 O(N) 的执行速度与按特定业务键筛选的灵活性。若需要保留“最后出现的项”而非“首次出现的项”，可以使用常规从后往前的单层循环或结合 reduceRight。
3. 多属性深度相等的对象去重：规范化序列化后再走 Set 或哈希
   如果确实需要判断对象全部字段内容相等，可使用 JSON.stringify 进行排序规范化键名后再做哈希比对。但需注意深层序列化本身伴随较大 CPU 开销，应避免在高频渲染帧内对巨型数据调用。