场景开场老陈在深圳做跨境货代团队连他在内 4 个人服务 60 多个海外代理和直客。他的生意几乎全跑在 WhatsApp 上客户发来询价他回运价订舱确认后建一个专属群把发货人、收货人、报关行一并拉进去船公司一发 ETD、ETA 变动他截图甩进群提单、装箱单、商业发票全在聊天里来回传。一个活跃 shipment 群每天产出 200 到 400 条消息他同时盯着 30 多个群。两年下来老陈的 WhatsApp 攒下 18 万条消息、9000 多张单证图片、600 多个群成员号码。去年带他的徒弟离职把客户群全退了老陈这才慌了神——这些聊天记录是他对每个客户运价偏好、特殊要求的全部记忆丢了只能从零摸起。他想把全部聊天一次性导出来备份点完导出按钮Chrome 标签页直接白屏崩溃。问题不在网络也不在账号而是浏览器内存根本装不下这一次的导出。解决路径老陈后来用上了 WAExport —— 一款在浏览器本地运行的 WhatsApp 导出插件 —— 把每日询价、订舱、单证消息持续备份到本机不依赖任何云端。它的思路不是先把所有数据抓进内存再一把导出而是边读边写。具体步骤很直接打开插件的备份中心选好要导出的账号和时间范围它从 WhatsApp Web 的本地数据库用游标逐条读取消息每读出一条就立刻转成一行 CSV 或一段 HTML 写进磁盘读完即弃绝不囤积。导出的文件按客户、按群、按时间分门别类老陈要找某个代理去年 9 月的清关要求几秒钟就能翻到。该扩展内置极简号码检测仅返回有效或无效状态帮他在导入通讯录前快速筛掉死号。整条链路模拟原生操作不调用会触发风控的异常接口数据 100% 留在他自己的机器上。技术剖析为什么先全量读进内存再导出会崩先算一笔账。WhatsApp Web 把消息存在浏览器的 IndexedDB 里每条消息是一个 JSON 对象含发送者、时间戳、正文、媒体引用、转发标记等字段。18 万条消息平均每条序列化后约 800 字节光对象本身就有 140 MB。可真正吃内存的不是这个是导出时你还把它们拼成一个巨大的字符串再交给Blob构造。V8 引擎对单个字符串有硬上限约 2^29 - 24 个字符接近 5.37 亿字符。一旦拼接后的字符串逼近这个量级或者更现实地在你那台只有 4 GB 内存、JS 堆上限约 2 GB 的笔记本上标签页就会触发 “Aw, Snap” 内存崩溃。还有个隐蔽的坑是 base64通过data:URL 下载的导出路径会把体积膨胀 33%本就紧张的内存直接爆掉。核心解法一游标拉取逐条消费。别用getAll()一次性把整张表搬进内存改用IDBCursor一边遍历一边处理每条记录处理完就交给垃圾回收// 用游标从 IndexedDB 逐条拉取避免一次性 getAll 撑爆内存asyncfunction*streamMessages(db,storeName){consttxdb.transaction(storeName,readonly);conststoretx.objectStore(storeName);letcursorawaitstore.openCursor();while(cursor){// 每次只持有当前这一条记录上一轮的引用在此之后被 GC 回收yieldcursor.value;cursorawaitcursor.continue();}}// 调用方边读边写内存里永远只有一条消息forawait(constmsgofstreamMessages(db,message)){awaitwriter.write(serializeRow(msg));}核心解法二用 File System Access API 的 WritableStream 流式落盘。拿到用户授权后showSaveFilePicker返回的文件句柄能拿到一个真正的可写流数据像水管一段段流进磁盘写完后内存里的那段即可丢弃。CSV 还要注意开头先写 UTF-8 BOM否则 Excel 打开中文全是乱码// 通过 File System Access API 拿到可写流分块写入磁盘asyncfunctionexportCsvStream(rows){consthandleawaitwindow.showSaveFilePicker({suggestedName:whatsapp-export.csv,types:[{description:CSV,accept:{text/csv:[.csv]}}],});constwriterawaithandle.createWritable();// 第一行写 BOM保证 Excel 正确识别 UTF-8awaitwriter.write();letbuffer;forawait(constrowofrows){bufferescapeCsv(row)\n;// 攒够 64 KB 再落盘一次兼顾 IO 次数与内存占用if(buffer.length64*1024){awaitwriter.write(buffer);buffer;}}if(buffer)awaitwriter.write(buffer);awaitwriter.close();}核心解法三Blob 分片别先拼成巨串。当运行环境拿不到 FSA比如某些浏览器或插件后台上下文只能走chrome.downloads.download用 Blob URL 下载时关键区别在怎么造这个 Blob。把几万行先join()成一个 200 MB 的字符串再new Blob([str])等于在内存里同时存在两份数据。正确做法是把每一块留在独立的字符串或 Blob 里用new Blob(chunks)把分片数组交给浏览器——Blob 构造接收数组时不会立刻把各片拼成连续内存只有真正读取时才按需展平// 错误先 join 成巨串内存峰值翻倍constgiantlines.join(\n);consturlURL.createObjectURL(newBlob([giant]));// 正确保留分片数组Blob 内部以分片列表持有避免二次拷贝constchunks[];letpart;for(constlineoflines){partline\n;if(part.length1024*1024){// 每 1 MB 切一片chunks.push(part);part;}}if(part)chunks.push(part);constblobnewBlob(chunks,{type:text/csv;charsetutf-8});awaitchrome.downloads.download({url:URL.createObjectURL(blob),filename:whatsapp-export.csv});上面三段合起来构成一条带背压的流水管线游标负责小口吃进可写流或分片 Blob 负责细水长流地吐出中间缓冲区设了上限消息再多也只是时间问题不再有内存雪崩。序列化这种纯计算活儿最好丢进 Web Worker主线程只管 UI不会因为卡顿被浏览器判为无响应// 主线程把逐条序列化交给 Worker自己不阻塞constworkernewWorker(./serialize.worker.js);forawait(constmsgofstreamMessages(db,message)){worker.postMessage({type:row,msg});}worker.postMessage({type:flush});// serialize.worker.js只做 CPU 密集的转义与拼行self.onmessage(e){if(e.data.typerow){self.postMessage({type:csv,csv:escapeCsv(e.data.msg)});}};边界与取舍流式方案不是银弹。File System Access API 目前主要覆盖 Chromium 系浏览器Firefox 和 Safari 的支持仍不完整这类环境下只能退回分片 Blob 加下载的折中路径用户得手动点一次保存。分片大小也要权衡块太小 IO 次数爆炸块太大又回到内存峰值问题64 KB 到 1 MB 通常是甜区。老陈那 18 万条消息换成流式导出后峰值内存从接近崩溃降到几十 MB导出的 CSV 他用 Excel 打开一目了然。值得提醒的是该工具做的是本地提取与备份它降低的是导出行为本身触发异常风控的概率不保证账号在任何违规群发下都安然无恙——备份归备份营销群发该守的规矩还得守。
