后端大数据去重应优先用Set处理基本类型数组，对象数组按字段用Map去重，超5万条需分片或Web Worker，禁用JSON.stringify深比较。
后端返回的大量数据去重，核心是“不增加额外负担、不破坏原始顺序、不误删合法重复”，不能简单套用前端小数组那一套。尤其当数据量上万、含对象或嵌套结构时，选错方法会导致卡顿、内存溢出或逻辑错误。
优先用 Set 处理基本类型数组
如果后端返回的是纯数字、字符串、布尔值组成的扁平数组（比如用户 ID 列表、标签名数组），Set 是最优解：速度快、代码少、保序性好。
- 直接写：[new Set(data)] 或 Array.from(new Set(data))
- 它底层基于哈希表，时间复杂度是 O(n)，比 filter + indexOf 的 O(n²) 高效得多
- 注意：1 和 "1" 被视为不同值，这是正确行为；若需强制类型归一（如全转字符串再比），得先 map 处理
对象数组按字段去重，用 Map 最稳
真实场景中，后端返回的往往是对象数组（如用户列表、订单记录）。这时不能直接用 Set，因为 {} !== {}。推荐用 Map 按唯一字段（如 id、code）做键来判重。
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 示例：按 id 去重
const unique = Array.from(new Map(data.map(item => [item.id, item])).values()); - 优势：Map 键支持任意类型，不会把 1 和 "1" 混淆；且能精准保留每个 id 对应的最后一条（或改用 !map.has(item.id) 保留第一条）
- 比 reduce + includes 更快，也比双重循环安全得多
大数据量时避免阻塞主线程
若数据超过 5 万条，即使用了 Set 或 Map，同步执行仍可能让页面卡顿。可考虑分片处理或 Web Worker：
立即学习“Java免费学习笔记（深入）”；
- 简单分片：用 setTimeout 或 requestIdleCallback 分批处理，每批 2000 条，留出渲染时间
- 更彻底方案：把去重逻辑移入 Web Worker，完全不占用 UI 线程
- 不推荐：在 for 循环里频繁 push 到新数组（内存分配开销大），或用 splice 原地删（数组塌陷+性能差）
慎用 JSON.stringify 做对象深比较
有人会想：把每个对象 JSON.stringify() 后再用 Set 去重。这看似通用，但隐患明显：
- 属性顺序不同会导致字符串不同（{a:1,b:2} 和 {b:2,a:1} 不等）
- 函数、undefined、Symbol、Date、RegExp 会被忽略或转成 null，造成误判
- 性能差：序列化本身开销大，数据越大越慢
- 真需要深比较，应明确字段清单，用 Map + 字段拼接键（如 `${item.id}-${item.status}`）
