处理百万级以上数组去重，首选唯一键+map（o(1)判断、省内存），其次json.stringify（限≤10万条且属性顺序固定），整数可用位图，超大数据须分块或流式处理。
处理海量数据（比如百万级以上）的数组去重，不能只靠 Array.from(new Set(arr)) 这类写法——它在小数据时简洁，在大数据时容易内存爆掉或卡死主线程。关键不是“能不能去重”，而是“用什么结构、按什么逻辑、在什么前提下做”。
优先用唯一键 + Map 做 O(1) 判断
90% 的业务对象都有自然唯一标识，比如 id、sku、userId。这是最快最省内存的方式：
- 用
Map存已出现的键值，filter时查是否存在，时间复杂度 O(n)，空间 O(去重后数量) - 比
Object更安全，避免原型链污染和数字键隐式转换问题 - 若键可能缺失，可组合多个字段生成哈希串，如
[item.a, item.b].join('|')
没有唯一键时慎用 JSON.stringify
当对象结构一致但无 ID（如日志片段、表单快照），可用序列化作为临时哈希依据：
- 必须确保对象属性顺序固定（否则
{a:1,b:2}和{b:2,a:1}序列化结果不同） - 性能开销大：每个对象都要转字符串，100 万对象可能吃掉 1GB+ 内存
- 建议仅用于 ≤10 万条、单对象 ≤1KB 的场景；超量请改用自定义键或分批处理
基础类型整数去重考虑位图（Bitmap）思路
如果数据是范围明确的非负整数（例如用户行为事件中的状态码 0–255、设备类型 ID 1–65535），位图比 Set 节省 8 倍以上内存：
- 用
Uint8Array或Uint32Array模拟位数组，n是否存在 → 查第Math.floor(n/8)字节的第n%8位 - Node.js 中可配合
Buffer.alloc()分配紧凑内存；浏览器中可用new Uint8Array(size) - 不适用于稀疏大范围（如 0–2³²），此时应选 Roaring Bitmap 类库或分段策略
超大数据量必须流式或分块处理
一次性加载 300 万对象进内存，即使算法再优也容易触发 V8 堆限制（默认约 1.4GB）。实际应：
- 用
for循环代替高阶函数（filter/map），减少中间数组创建 - 每处理 5 万–10 万条后
setImmediate（Node）或setTimeout(..., 0)（浏览器）让出主线程 - 服务端可结合数据库去重（如 PostgreSQL 的
DISTINCT ON或临时表CREATE TEMP TABLE ... ON COMMIT DROP）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
