高性能数组去重需依数据特征选策略：有唯一键用Map查重（O(n)、省内存）；无键但结构固定慎用JSON.stringify（限10万条）；纯非负整数集中范围用位图；超大数据须分块或流式处理。
高性能场景下避免数组去重时间复杂度过高，关键不是选“最短代码”，而是根据数据特征匹配合适的数据结构和执行策略。小数据用 Set 没问题，但百万级对象或整数，盲目套用会卡死或爆内存。
有唯一键时：用 Map + 字段查重（O(n)，省内存）
90% 的业务数据带自然 ID（如 id、sku、userId）。这时别序列化，直接用 Map 存键值：
- 遍历一次，用
map.has(key)判断是否已存在，O(1)查找 - 空间只占去重后数量，比 JSON.stringify 节省数倍内存
- 键缺失可组合生成，例如
[item.a, item.b].join('|') - 比普通 Object 安全：不污染原型链，不隐式转数字键
无唯一键但结构固定：慎用 JSON.stringify（限 ≤10 万条）
适用于日志快照、表单数据等无 ID 但字段顺序一致的对象：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 必须确保属性顺序固定，否则
{a:1,b:2}和{b:2,a:1}序列化结果不同 - 每个对象都要转字符串，10 万条可能吃掉 500MB+ 内存
- 超量请改用自定义哈希（如 MurmurHash 简化版）或分块处理
纯非负整数且范围集中：用位图（Uint8Array / Uint32Array）
比如状态码（0–255）、设备类型 ID（1–65535）这类场景：
- 判断
n是否存在 → 查bytes[Math.floor(n/8)]的第n%8位 - 内存占用仅为 Set 的 1/8 左右；浏览器可用
new Uint8Array(size) - 不适用于稀疏大范围（如 0–2³²），此时考虑 Roaring Bitmap 或分段位图
超大数据（如 300 万+）：必须流式或分块处理
一次性加载进内存极易触发 V8 堆限制（默认约 1.4GB），即使算法再优也扛不住：
- 用
for循环代替filter/map，避免创建中间数组 - 每处理 5 万–10 万条后，用
setTimeout(..., 0)让出主线程 - 服务端优先交由数据库去重（如 PostgreSQL 的
DISTINCT ON或临时表）
