Unchecked runtime.lastError: QUOTA_BYTES quota exceeded一个负责聊天记录本地留存的浏览器扩展跑到第 11 周吐出这行报错之后再没成功写进去过一条新消息。糟糕的地方在于用户毫无察觉——界面照常旧记录还在只有新数据在静默丢失。一家家政公司是怎么把存储层压垮的吉隆坡有家做居家保洁的小公司26 名保洁员480 户长期客户日常两小时上门 RM 130深度清洁 RM 380。所有排班、门禁说明、验收照片都跑在 WhatsApp 上6 个作业群按片区分加上跟客户的一对一单聊。老板 Wendy 一年下来积了差不多 12 万条消息其中 3.4 万条带图片。这些消息不是聊天记录是她的生产资料。她被三件事反复折磨。一是保洁员离职就等于客户流失——阿姨用自己的号跟熟客沟通人一走那户人家下次预约打给谁全看运气。二是客诉举证——客户投诉「浴室镜子没擦」Wendy 需要翻出 3 个月前的验收照片和当时那句「镜柜内侧本次不含」在群聊里往上滚 40 分钟也未必找得到。三是返单提醒每月哪 60 户该做定期清洁全靠她本人记。这类商户的共同点很明确数据量不大不小卡在最难受的位置。几百户客户、十几万条消息、几万张图片上一套字段严整的排班系统嫌重纯靠人肉又已经超出记忆力上限。商户实际怎么把数据攥回自己手里Wendy 的解法分三层。跟客户的单聊按客户名归档导出成带原生气泡排版的 HTML验收照片和文字说明保持在同一份文件里客诉时直接甩整段上下文6 个作业群的成员名单定期导成 Excel保洁员流动的时候能立刻看出哪些熟客号码只存在于某个人的手机里每月返单名单从最近 90 天的活跃对话里筛出来按最末一次服务日期排序。她用的是 WAExport 这类纯客户端运行的浏览器扩展数据全程留在本机不经过任何云端中转。关键变化不是「能导出」而是「持续留存」。一次性导出解决的是当下这份文件Wendy 需要的是后台静默跟进——新消息进来就落到本地随时可以按客户、按日期、按群组切一份出来。而这个「持续」恰恰是把存储层压垮的那件事。chrome.storage.local 的天花板在哪MV3 扩展开发者的第一反应几乎都是chrome.storage.local。API 简单Service Worker 里能直接调配置和数据一把梭。它的容量上限写在常量里chrome.storage.local.QUOTA_BYTES从 Chrome 114 起是 10,485,760 字节也就是 10 MB更早的版本是 5 MB。作为对比chrome.storage.sync只有 102,400 字节单条 8,192 字节那是给用户偏好设置准备的跟消息存档没有关系。12 万条消息平均每条含发送方、时间戳、正文、消息类型、引用关系JSON 序列化后单条 300 到 600 字节总量落在 45 MB 到 70 MB 之间。10 MB 的天花板在第 11 周被撞穿一点都不意外。manifest 里加上unlimitedStorage权限确实能解除这个硬顶但容量问题解除的同时性能问题会立刻接管。先把家底摸清楚两个 API 要一起看// storage-probe.js —— 落盘前先探清两套存储的真实余量exportasyncfunctionprobeStorage(){// 1) chrome.storage.local 的已用量字节。传 null 表示统计全部 keyconstusedBytesawaitchrome.storage.local.getBytesInUse(null);// QUOTA_BYTES 在声明 unlimitedStorage 后依然返回 10MB 这个名义值// 真实上限由浏览器配额系统接管所以它只能当是否接近默认档的参考constnominalQuotachrome.storage.local.QUOTA_BYTES;// 10485760// 2) IndexedDB 走的是 Storage Quota 体系用 StorageManager 估算letquota0,usage0,persistedfalse;if(navigator.storage?.estimate){({quota0,usage0}awaitnavigator.storage.estimate());}if(navigator.storage?.persisted){persistedawaitnavigator.storage.persisted();}return{kvUsedMB:(usedBytes/1048576).toFixed(2),kvNominalMB:(nominalQuota/1048576).toFixed(2),idbUsageMB:(usage/1048576).toFixed(2),idbQuotaMB:(quota/1048576).toFixed(2),// 通常是磁盘可用空间的一大部分persisted,// 是否已置为持久化、免于配额压力驱逐};}navigator.storage.estimate()返回的quota在桌面 Chrome 上往往是几十甚至上百 GB 量级因为它按磁盘剩余空间的比例分配。两套存储根本不在一个数量级上这是选型的起点但远不是全部。真正的杀手是写放大假设不管容量硬把消息数组塞进chrome.storage.local代码大概长这样// ❌ 反面教材每来一条新消息重写整个数组asyncfunctionappendMessageBad(msg){const{messages[]}awaitchrome.storage.local.get(messages);messages.push(msg);awaitchrome.storage.local.set({messages});// 整个数组重新序列化 落盘}这段代码的问题不在语法在复杂度。chrome.storage的值是按 key 整体读写的没有部分更新这回事。已经存了 5 万条第 50,001 条进来时运行时要做的事情是把 5 万条从磁盘读出来 → 反序列化成 JS 对象 → push 一条 → 重新序列化 → 整块写回。单条插入的成本是 O(n)n 条消息全量导入的总成本是O(n²)。还有一层容易被忽略的开销chrome.storage的每次调用都要跨进程。扩展页面或 Service Worker 发起请求经 IPC 送到浏览器进程由那边完成序列化和落盘再回传。一次 6 MB 的set()等于一次 6 MB 的跨进程消息传递。在一台 i5 级别的笔记本上这一次调用的耗时在几百毫秒量级而且随数据量线性上升。序列化方式也有差别。chrome.storage走的是JSON 序列化Date会变成字符串Map、Set、ArrayBuffer、Blob一律存不进去IndexedDB 用的是结构化克隆算法上面这些类型原样保留图片缩略图可以直接以Blob落库不必先转成体积膨胀 33% 的 base64。同样的追加操作换成 IndexedDB 是这样// ✅ 正确姿势主键定位单条写入与库内总量无关constDB_NAMEchat-archive;constDB_VERSION1;functionopenDB(){returnnewPromise((resolve,reject){constreqindexedDB.open(DB_NAME,DB_VERSION);req.onupgradeneeded(e){constdbe.target.result;if(!db.objectStoreNames.contains(messages)){// 用消息自身的稳定 ID 作主键天然幂等重复导入同一条会覆盖而非追加conststoredb.createObjectStore(messages,{keyPath:id});// 复合索引按会话 时间戳查询是导出场景里 90% 的访问模式store.createIndex(by_chat_ts,[chatId,ts],{unique:false});// 单列索引全局按时间范围切片跨会话的日期筛选store.createIndex(by_ts,ts,{unique:false});// 未保存联系人的号码索引用于跨会话去重合并store.createIndex(by_phone,phone,{unique:false});}if(!db.objectStoreNames.contains(media)){// 缩略图单独一张表Blob 体积大跟消息正文放一起会拖慢正文的游标遍历db.createObjectStore(media,{keyPath:msgId});}};req.onsuccess()resolve(req.result);req.onerror()reject(req.error);});}把复合索引[chatId, ts]建对是整个存储层最值钱的一行代码。「导出张女士家 3 月 1 日到 3 月 31 日的全部消息」这种查询靠它可以直接用IDBKeyRange.bound([chat_88, t0], [chat_88, t1])定位到一段连续区间不需要扫全表。放在 KV 存储里同样的需求只能把 12 万条全读进内存再 filter。批量写入把事务当成批处理单元拿到全量历史时逐条put再逐条await是另一个常见陷阱// 批量落库一个事务塞满一批事务本身就是最好的批处理边界asyncfunctionbulkPut(db,storeName,records,batchSize1000){for(leti0;irecords.length;ibatchSize){constchunkrecords.slice(i,ibatchSize);awaitnewPromise((resolve,reject){consttxdb.transaction(storeName,readwrite);conststoretx.objectStore(storeName);// 关键不要 await 每个 put。IDBRequest 是排队执行的// 只等最终的 tx.oncomplete一批 1000 条共享一次事务提交开销for(constrecofchunk)store.put(rec);tx.oncompleteresolve;tx.onerror()reject(tx.error);tx.onabort()reject(tx.error||newError(transaction aborted));});// 让出主线程避免长任务把 UI 卡死大批量导入时肉眼可见awaitnewPromise((r)setTimeout(r,0));}}这里有条 IndexedDB 的硬规则值得单独拎出来事务在微任务队列排空的那一刻自动提交。在事务内部await一个非 IDB 的 Promise比如fetch、chrome.storage.local.get事务会在你回来之前就已经关掉紧接着抛TransactionInactiveError。写批量导入时踩这个坑的概率极高。10,000 条消息的落库耗时事务批处理相比逐条提交能压掉一个数量级而同样这批数据走chrome.storage.local的全量重写路径耗时随批次线性膨胀两者不具备可比性。导出时的内存控制游标而不是 getAll数据进去了导出又是一道坎。store.getAll()一次把 12 万条对象全部实体化到内存配上 3.4 万个缩略图 Blob标签页崩溃只是时间问题。正确做法是用游标边读边写// 按会话 时间范围流式遍历每 500 条回调一次内存占用恒定functionstreamByChatRange(db,chatId,startTs,endTs,onBatch){returnnewPromise((resolve,reject){consttxdb.transaction(messages,readonly);constidxtx.objectStore(messages).index(by_chat_ts);// 复合索引的区间查询锁定单个会话内的一段连续时间constrangeIDBKeyRange.bound([chatId,startTs],[chatId,endTs]);letbuffer[];lettotal0;idx.openCursor(range).onsuccess(e){constcursore.target.result;if(!cursor){if(buffer.length)onBatch(buffer);return;// 游标走完等 tx.oncomplete 收尾}buffer.push(cursor.value);total;if(buffer.length500){onBatch(buffer);buffer[];// 立刻释放引用让 GC 能回收这一批}cursor.continue();};tx.oncomplete()resolve(total);tx.onerror()reject(tx.error);});}游标模式下内存占用只跟批次大小有关跟库里存了多少条无关。500 条一批峰值内存稳定在几 MB导出 12 万条和导出 1 万条的内存曲线几乎重合。配合TransformStream或者分片Blob能一路流到磁盘而不在中途攒出一个巨型字符串。分层才是答案两套存储各干各的选型的结论不是二选一而是按数据特征分层。chrome.storage.local留给小而关键的状态同步水位线、用户配置、导出任务进度、上次成功落库的消息 ID。这类数据的共同特点是体积小几 KB、更新频繁、需要在 Service Worker 里随手读写而且**chrome.storage.onChanged天然是跨上下文广播的**——popup、options 页、content script、Service Worker 同时收到变更通知这套机制 IndexedDB 没有对应物。IndexedDB 承载主体数据消息、联系人、群成员、媒体缩略图。大体量、需要索引、需要范围查询、需要流式读取。// 分层落地主体数据入 IDB水位线入 KV两者用同一个逻辑事务边界串起来constCKPT_KEYsync_checkpoint;asyncfunctionsyncBatch(db,chatId,newMessages){if(!newMessages.length)return;// 1) 主体数据落 IndexedDB幂等主键相同即覆盖断点续传天然安全awaitbulkPut(db,messages,newMessages);// 2) 水位线落 chrome.storage.local体积恒定在几百字节const{[CKPT_KEY]:ckpt{}}awaitchrome.storage.local.get(CKPT_KEY);constlatestnewMessages[newMessages.length-1];ckpt[chatId]{lastId:latest.id,lastTs:latest.ts,updatedAt:Date.now()};awaitchrome.storage.local.set({[CKPT_KEY]:ckpt});}// 任意上下文都能监听到水位线变化用来驱动 UI 进度条chrome.storage.onChanged.addListener((changes,area){if(arealocalchanges[CKPT_KEY]){// changes[CKPT_KEY].newValue 即最新的各会话进度renderSyncProgress(changes[CKPT_KEY].newValue);}});顺序不能反。先写 IndexedDB再更新水位线——中途崩溃的话水位线偏旧只会导致下一轮重复拉取同一批消息而主键幂等保证重复put不产生脏数据反过来先更新水位线崩溃就等于永久丢数据。边界与取舍这套方案有几个必须说清楚的限制。MV3 的 Service Worker 会在空闲 30 秒左右被回收长时间的 IndexedDB 事务扛不住这个生命周期。稳妥做法是把落库放在有页面上下文的地方WhatsApp Web 页面里的 content scriptService Worker 只做调度和状态管理。IndexedDB 在磁盘压力下存在被驱逐的可能。扩展在 manifest 里声明unlimitedStorage后自身 origin 的存储会被豁免但这依赖用户授权该权限不是无条件成立的。写代码时仍应假设「数据可能不在了」导出关键记录时给用户一条明确的落盘路径而不是把浏览器当唯一保险柜。存储层再稳也改变不了这类扩展的运行前提它依赖 WhatsApp Web 网页版环境脱离浏览器的纯移动端场景不在能力范围内。数据提取采用模拟原生行为、不调用异常 API 的方式这降低的是自动化操作触发风控的概率跟「怎么发消息、发什么内容」是两码事账号安全不能只押在工具上。顺带说一句号码相关的能力边界这类工具内置的号码检测仅返回有效或无效两种状态不做更进一步的信息查询。用它做名单初筛够用别当成客户资质核验。收个尾存储选型的判断标准只有一条这份数据要不要被索引、被范围查询、被流式读取。要就进 IndexedDB代价是 schema 设计和事务生命周期的心智负担不要只是几 KB 的状态位就用chrome.storage.local享受它跨上下文广播的便利。混着用不是妥协是正解。现在去翻一下你手上扩展的代码全局搜chrome.storage.local.set。凡是往里塞数组的地方都是潜在的 O(n²) 写放大点——把它们挑出来一个一个搬进 IndexedDB。