内存受限设备数组去重需避开全量加载，优先用位图处理整数ID、分块流式+指纹集合、布隆过滤器预检、字段哈希+轻量Map，禁用JSON.stringify。
在内存受限设备上做数组去重，核心不是“选哪种方法”，而是“避开全量加载+全量比对”——得用流式处理、位级压缩或外部辅助结构，把空间复杂度压到最低。
用位图（Bitmap）处理整数型重复数据
当数据是 32 位无符号整数（比如 QQ 号、用户 ID、状态码），且取值范围明确（如 0～40 亿），位图是最省空间的方案：每个数字只占 1 bit。40 亿个数仅需约 476MB，远低于直接存数字的 14.9GB。
- 用 Uint8Array 或 ArrayBuffer 手动管理位操作，避免 JS 对象开销
- 查重逻辑就是读对应 bit 位；去重就是设为 1，无需存储原始值本身
- 不支持字符串、负数、浮点数或超范围整数，但对嵌入式 ID 列表、传感器状态码等场景非常贴切
分块流式去重 + 增量写入
当数组太大无法一次性加载进内存（比如从文件、串口或低配 IoT 设备缓存中读取），就别试图“整个数组去重”，改用边读边判、边写边丢的策略：
- 每次只读固定大小的数据块（如 1000 个元素），用 Set 缓存本块内已见值
- 同时维护一个轻量级全局“指纹集合”（如用 Map 存哈希值，或用布隆过滤器做前置快速判断）
- 对每个新元素，先查指纹集合；若未命中，再加入并输出；若命中，跳过
- 结果可实时写入文件、发送到上位机或存入 Flash 小区，不累积内存
用布隆过滤器做快速存在性预检
布隆过滤器用少量内存（比如几 MB）换取极快的“可能存在 / 肯定不存在”判断，适合内存紧张又允许极低误判率的场景：
- 初始化一个固定大小的 BitArray 和多个独立哈希函数
- 插入时，对每个元素算出 k 个位置，全部置为 1；查询时，k 个位置全为 1 才认为“可能存在”
- 它不会漏掉真实存在的元素（无假阴性），但可能把不存在的判成“存在”（假阳性）
- 可配合后续精确校验（如查本地小缓存）使用，大幅减少昂贵比对次数
对象数组去重改用字段哈希 + 轻量 Map
内存受限时，绝对不要用 JSON.stringify——它会临时生成大量字符串，触发频繁 GC，极易 OOM。应改为：
- 提取关键唯一字段（如 id、sku、timestamp），拼接成紧凑字符串键（如
id+"|"+type） - 用 Map 存这些键，value 可设为 true 或计数，不存原对象
- 遍历原数组时，只比对键，匹配则跳过；不匹配则存键并输出当前对象引用
- 若字段本身是大字符串或嵌套结构，先用简单哈希（如 djb2）转成 32 位数字再存，进一步减小内存占用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
