告别重复数据：深入解析 JS Set 去重的正确姿势

接需求的时候，最怕看到接口返回的数据里混杂着重复项。后端没处理好，前端就得自己补位。早年我们习惯用 filter 配合 includes 或者双重 for 循环硬啃，代码写得密密麻麻，性能还容易掉链子。直到 ES6 的 Set 结构出现，很多人才发现，原来去重可以优雅到只需一行代码。

[...new Set(arr)] 这个写法几乎成了标配。它的原理很简单，Set 本身就是用来存储唯一值的集合，你扔进去多少个元素，它会自动帮你过滤掉重复的。但这真就能一劳永逸了吗？实际开发中，直接用往往会在细节上栽跟头。

最直观的一个坑在于基本类型与复杂类型的区别。如果数组里全是字符串或数字，上述写法完美无缺。可一旦涉及到对象，情况就变了。Set 判断对象是否相等，依据的是内存地址。两个属性完全一样的对象 {id: 1}，在 Set 眼里是两个不同的个体。如果你试图直接对包含对象的数组使用 Set，结果大概率是原封不动。这时候就需要先抽离出唯一的标识字段。比如先把对象数组转换成 ID 字符串数组，完成去重后，再根据 ID 映射回原始对象。这种"提取键值 -> 去重 -> 还原数据"的思路，在处理列表分页合并或防止重复提交时非常管用。

还有个容易被忽略的细节是 NaN。在常规比较中，NaN === NaN 返回 false，但在 Set 内部，所有的 NaN 被视为同一个值。这意味着如果你的数据源里混入了计算产生的异常值，Set 会帮你在去重的同时顺手把它们归拢到一起，这反而是一种意外的便利。不过也要小心，不要依赖这个特性去区分不同的无效数据。

性能方面，虽然 Set 看起来方便，但在超大数组面前并非绝对最优。对于千万级数据量，原生循环可能因为引擎优化更稳定，而 Set 在某些旧版浏览器上的兼容性虽已不是问题，但在追求极致渲染的场景下仍需权衡。通常百万以下的数据量，直接上 Set 是最划算的选择，兼顾了开发效率与运行速度。

回到日常场景，当遇到前端表格需要展示且不重复的状态标记时，用 Set 存储状态码比维护一个庞大的布尔数组更清晰。它不仅减少了变量占用的内存空间，让代码逻辑更具可读性，还避免了手动维护索引的繁琐。

技术工具的本质是服务于业务逻辑。Set 去重之所以流行，是因为它符合我们对“唯一性”的直觉认知。但记住，没有万能的银弹。掌握它的边界条件，知道什么时候该用、什么时候该绕道，才是从新手进阶到熟练工的标志。下次再面对脏数据，不妨先分析一下数据类型，再决定是简单扔进 Set，还是需要多几步处理来保证准确性。毕竟，写出能跑的代码不难，写出让人放心且好维护的代码，才是我们追求的终极目标。