JS数组去重需避开五类反模式：改原数组、误判相等、顺序错乱、对象失效、性能崩盘；应优先用Set或filter+indexOf等保序纯函数方案，按需选择SameValueZero语义、字段映射或哈希表优化。
JS 数组去重看似简单，但实践中常踩几类典型反模式：改原数组、误判相等、顺序错乱、对象失效、性能崩盘。避开它们不靠死记硬背，关键在理解每种写法背后的机制和边界。
别直接修改原数组（比如用 splice 遍历删除）
用双层循环 + splice 边遍历边删，容易因索引塌陷漏掉元素，还污染原始数据。尤其在函数式场景或状态管理中，副作用会引发难以追踪的 bug。
- 改用纯函数方式：新建数组收集唯一项，不碰原数组
- 若必须就地去重，先 reverse 遍历再删，或用 filter 返回新数组
- 真实项目里，优先考虑语义清晰、无副作用的方案，比如 Set 或 filter + indexOf
别依赖 === 判断所有类型（NaN、-0、对象全失效）
indexOf、includes、filter + 自定义比较 默认走严格相等（===），导致 NaN !== NaN，-0 === 0，两个内容相同的对象永远不重复——这不是“去重失败”，是逻辑本就不支持。
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 需要正确处理 NaN？选 Set，它内部用 SameValueZero 算法，能识别 NaN 相等
- 要区分 -0 和 +0？Set 同样支持（SameValueZero 区分二者）
- 对象/数组去重？不能靠值比较，得提取唯一标识，比如用
JSON.stringify(item)（仅限简单结构）或按 key（如item.id）映射
别先排序再相邻去重（顺序丢失 + 多余开销）
有人写 arr.sort().filter((v, i) => v !== arr[i-1])，结果原顺序全乱，且排序本身是 O(n log n)，比必要去重慢得多。
- 除非业务明确要求升序输出，否则不要引入 sort
- 保序是默认需求，Set、filter + indexOf、reduce + includes 都天然保持首次出现顺序
- 大数据量时，排序成本可能远超去重本身，尤其当数组已部分有序
别对对象数组盲目套用基本类型方法
直接把对象数组丢进 [...new Set(arr)] 或 filter((v, i) => arr.indexOf(v) === i)，每个对象都是不同引用，结果等于没去重。
- 先确认去重依据：是整个对象深比较？还是某个字段（如 id、name）？
- 按字段去重推荐 Map：用
new Map(arr.map(item => [item.id, item]))，再取Map.values() - 需深比较？避免 JSON.stringify（性能差、undefined/function 丢失），改用库如 lodash 的
uniqBy或手写递归比较
别在万级数据上用 O(n²) 方法（如双循环或 indexOf 嵌套）
indexOf 在每次迭代中都要从头扫描，1 万条数据 ≈ 1 亿次比较，浏览器卡顿甚至崩溃。
- 基础类型数组，无脑用
Array.from(new Set(arr))：O(n)，稳定高效 - 需兼容老环境？用对象哈希表：
const seen = {}; arr.filter(x => !(x in seen) && (seen[x] = true)) - Map 比普通对象更安全（支持任意键类型，包括对象、NaN），适合复杂场景
