前端日志上报这事儿做不好是真头疼。你线上出了个偶发bug想看用户操作路径结果最后几步的日志死活没上来排查链路断在半路或者你明明在埋点代码里写了上报用户反馈我就是点了按钮没反应后台却连这条点击记录都没收到。调查起来发现十有八九都出在三个地方用户当时网络很烂、用户刚好断网了、用户操作完就直接关了页面。我今天就把这块的完整思路讲清楚——从根因分析到一套可以直接落地的代码骨架再到我用工具模拟弱网、断网、秒关页的实测结果一次给你讲全。内容适合正在做前端监控、埋点上报的开发者也适合那些写业务代码时顺带接上报需求的同学。1. 日志上报为什么那么容易丢三个典型场景的丢包根因很多同学一上来就写fetch(/log, { data })用着挺顺手一到线上就开始丢数据。不是fetch不好而是你没有想过一个问题日志上报这个场景和数据请求在本质上就不是一回事。业务请求丢了用户会立刻发现日志请求丢了没有任何人知道只有在事后排查时才悔之晚矣。所以第一步不是写代码而是把丢包到底发生在哪这件事拆清楚。1.1 弱网场景TCP重传的代价和请求超时弱网环境比如地铁上、电梯里、地下车库、偏远地区的3G网络下带宽不稳定、丢包率高TCP为了保证可靠性会反复重传。这时候你发出的HTTP请求可能一直处于pending状态迟迟得不到响应。问题在于绝大多数上报代码都用fetch或XMLHttpRequest它们默认是有超时时间的超时之后请求就被中断。而在弱网下请求可能在超时边缘被卡住——明明服务端已经收到了但响应迟迟回不来前端认为是失败了Enter会重发结果服务端收到一堆重复数据。反过来也可能请求根本没到服务端前端以为发了实际进了黑洞。更隐蔽的一点是弱网状态下用户的网络质量是波动的。某个时间点网络差5秒后可能就好了。如果你在上报代码里做了失败就丢弃或者失败就立即重试那么大量日志会在网络抖动期间被浪费掉。正确的思路是把日志先落到本地等服务端确认收到再删除确认失败的话就留在本地等下一次机会。1.2 断网场景请求发出即坠机navigator.onLine还不可靠断网场景比弱网更极端。用户进电梯信号直接消失用户开了飞行模式用户在移动端切换WiFi的瞬间网络处于空白期。这个状态下发出请求几乎是必丢的。但真正坑人的是navigator.onLine这个API。它只表示浏览器当前是否认为有网络连接但它判断依据只是网络接口是否存在并不是真的发了一个探测包。你连上了路由器但路由器本身断网navigator.onLine依然返回true。所以指望靠它来判断是否断网再决定是否上报完全不靠谱。正确姿势是监听两个事件offline和online。浏览器在确认网络断开时会触发offline事件恢复时触发online事件。你可以在这些事件里切换上报策略——offline时把所有日志堆积到本地队列online时立刻把队列里的数据全部flush出去。需要注意的是这个在线/离线事件在部分旧版浏览器和WebView里触发时机比较滞后所以事件只是一个辅助信号核心兜底还是服务端确认机制。1.3 关页场景浏览器根本不给你机会三种场景里最容易被忽视、也最容易造成最后一条日志丢失的就是用户直接关页面。想想看用户最常怎么离开页面关闭标签页、刷新、跳转到其他域名、在手机上直接Home键切后台然后杀掉App。这些操作触发的是页面生命周期结束浏览器会清理这个页面所有的异步资源。你用fetch发出去的请求、甚至setTimeout里的逻辑都可能根本来不及执行完毕。fetch在页面销毁时会被直接中断这是浏览器行为不是你代码能挽回的。很多人在beforeunload事件里发同步XHR想借着同步请求强制把日志送出去。同步XHR确实能阻塞页面销毁一小段时间但浏览器现在对同步XHR的限制度很大主线程卡顿、弹窗警告而且移动端浏览器经常忽略这个阻塞。就算请求发出去了快速切断的网络也会在连接建立前就被打断。总之关页场景必须用专门的机制来解决这个后面单独讲。2. 关页上报的正解sendBeacon与visibilitychange双保险关页丢日志这个问题行业里已经有一个公认的最优解navigator.sendBeacon()。它是一个专门为页面卸载时发送数据设计的API。2.1 sendBeacon为什么是首选sendBeacon(url, data)做的事情很简单把一个数据包交给浏览器剩下的由浏览器负责发送。这个API的特别之处在于它不要求页面继续存活而是利用浏览器层的机制把数据发送出去页面销毁不影响发送结果它不会影响页面卸载性能是异步的不阻塞用户它对短小的数据非常可靠是关页上报的首选方案。需要注意sendBeacon有一定限制数据量一般建议控制在64KB以内实际浏览器实现可能略大但不建议赌并且只支持POST。如果你有大量日志要上报不能指望一个Beacon全塞进去应该合并成小批次。用户关页时塞几KB的日志是没问题的。另一个细节是sendBeacon的Content-Type默认是text/plain或者application/x-www-form-urlencoded不能直接传JSON对象。所以我通常把日志数组JSON序列化之后再传字符串服务端按文本解析即可。function sendByBeacon(logs) { const payload JSON.stringify(logs); navigator.sendBeacon(/api/log/batch, payload); }如果sendBeacon返回false数据量大或浏览器不支持再降级到其他方案。2.2 降级方案动态图片和同步XHR谁更靠谱老一批的前端监控库用的是1x1 GIF图片上报也就是new Image().src /api/log?data...。图片请求不阻塞页面加载而且就算不做DOM插入浏览器也会正常发出请求。但图片请求是GET方式URL长度限制大约2KB到8KB各浏览器不同和Beacon的POST方式没法比。在关页场景里图片请求能发出去的概率比fetch要高但依然不是100%可靠。有人说那用同步XHR不就得了实测结果是在Chrome里同步XHR确实会阻塞unload一小段时间给请求留出一定发送窗口但代价是用户体验变差——页面卡顿、浏览器可能有性能警告而且在移动端Safari里经常不生效。我的建议是Beacon优先Image兜底同步XHR尽量不用除非你确认旧内核WebView必须靠它。2.3 捕获所有关页路径pagehide、visibilitychange、beforeunload的配合很多人只写了beforeunload但页面还有好几种非传统离开的方式用户切后台不销毁页面只是不可见、移动端浏览器杀掉后台页面、前进后退缓存bfcache等。它们不一定触发beforeunload。行业内推荐的最佳实践是pagehide事件它在页面被销毁或进入bfcache时都会触发兼容性也OK。同时要注意visibilitychange当document.visibilityState变成hidden时意味着用户已经看不到页面了此时是发送日志的黄金窗口——如果用户切后台这个事件一定会触发如果用户直接关闭页面这个事件在beforeunload/pagehide之前触发。所以关页上报的正确姿势是function flushOnLeave() { const logs queue.drain(); if (!logs.length) return; if (navigator.sendBeacon) { navigator.sendBeacon(/api/log/batch, JSON.stringify(logs)); } else { const img new Image(); img.src /api/log?data encodeURIComponent(JSON.stringify(logs)); } } document.addEventListener(visibilitychange, () { if (document.visibilityState hidden) { flushOnLeave(); } }); window.addEventListener(pagehide, flushOnLeave);这里有个顺序问题要注意visibilitychange先触发pagehide在后所以flushOnLeave必须是幂等的第一次调用就把队列抽空第二次调用进来发现没数据直接返回即可。2.4 服务端配合Beacon接口要特殊处理响应Beacon的发送是浏览器后台完成的前端根本拿不到响应体。所以服务端接收Beacon时不能按普通业务接口的逻辑来做——比如要求在响应里返回业务码、要求前端校验响应等这对Beacon来说都是白扯。服务端要做的是快速返回200不做过重逻辑把请求体原样保存解析JSON日志数组后直接入库或送消息队列接口单独挂一个路径和生产业务接口隔离避免占用Tomcat连接池。很多团队忽略Beacon接口的响应速度服务端处理慢了浏览器可能认为Beacon失败而重试造成重复。实际经验是这个接口应该比普通接口更轻量记录日志不需要事务、不需要实时返回明细丢了再补、异步落地都行。3. 断网弱网的第一道防线本地暂存与离线队列关页问题解决了接下来是断网和弱网。核心思路就一条日志先写本地确认服务端收到后再删否则一直留着待重试。这就是一个预写日志 确认删除的队列模型和数据库的WAL预写日志思路很像。3.1 存储选型localStorage vs IndexedDB别选错用途前端本地存储最常见的两个候选是localStorage和IndexedDB。localStorage优点API简单、同步读写编码上省事、兼容性好到离谱、容量约为5MB。缺点只能存字符串读和写会同步阻塞主线程数据量大了以后会有明显的性能损耗而且不支持事务。IndexedDB优点容量大通常几百MB甚至更多、异步读写不阻塞UI、支持索引和事务。缺点API上手成本高不过用idb这类库封装后也不复杂。日志上报这个场景我的建议很直接如果单条日志小、量不大每天几千到几万条每条几百字节用localStorage完全够代码简单出问题好排查如果日志量大每次操作都带payload、截图、性能数据用IndexedDB否则5MB很容易爆很多成熟方案是双模混合高频小日志用localStorage大体积用IndexedDB。我自己的项目里默认选localStorage因为日志队列在正常情况下是空的发完就删只有断网时才会一直累积容量压力其实不大。真正需要担心的反而是如果你的日志常驻本地不清理localStorage里堆积几千条每次同步写入都会卡一下主线程。3.2 队列设计批量合并、节流与压缩日志队列的本质是一个数组入队就是pushflush的时候一次性取出来。但直接一个数组裸奔有很多问题第一要合并。每一条日志都单独发一个HTTP请求在弱网下是灾难。正确做法是定时器批量日志先入队每5秒或者积满50条时合并成一个批次发送。这样一来断网场景下堆积的也是合并后的批次而不是几百个待发请求。第二要节流。高频事件mousemove、scroll、页面性能数据产生的埋点可能是每秒几十条。直接入队会把队列撑爆。常见做法是前端采样率阈值比如同一个类型的事件1秒内最多记录1条或者按10%概率采样。第三要考虑压缩。如果日志量大或者要传的内容是明文字符串堆在一起可以考虑pako这类库对JSON字符串做deflate压缩压缩后再base64编码传输。实测下来对于重复字段多的日志压缩率能到70%以上这能显著减少弱网下的传输时间和Beacon的大小限制压力。3.3 重试与指数退避别在弱网恢复瞬间雪崩队列里的日志flush失败后什么时候重试这个问题处理不好就是在给自己挖坑。假设用户断网5分钟你每分钟尝试flush一次每次发100条数据5分钟里就有500条积压。等网络恢复的那一刻如果所有人都立刻flush服务端可能瞬间被打爆。这也是日志上报系统常见的断网恢复雪崩。所以重试一定要带退避策略。我的做法是用指数退避基础间隔从1秒开始失败一次间隔翻倍最多退避到5分钟。网络恢复时触发online事件可以立即尝试一次但不保证一定成功只有收到服务端ACK确认才认为这个批次彻底发出去了。let retryDelay 1000; const MAX_RETRY_DELAY 5 * 60 * 1000; async function flushQueue() { const batch queue.drain(); if (!batch.length) return; try { const ok await sendBatch(batch); if (ok) { retryDelay 1000; // 继续尝试下一个批次 flushQueue(); } else { queue.unshift(batch); scheduleRetry(); } } catch (e) { queue.unshift(batch); scheduleRetry(); } } function scheduleRetry() { setTimeout(flushQueue, retryDelay); retryDelay Math.min(retryDelay * 2, MAX_RETRY_DELAY); }注意一个细节queue.unshift(batch)是把批次放回队头保证日志顺序不被打乱。业务上报场景顺序不一定重要但如果你有用户操作时间线的需求顺序错乱会影响排查。3.4 队列容量与清理策略localStorage爆了怎么办所有存储方案都有上限localStorage 5MB、IndexedDB也可能被浏览器清理。日志队列不能无限制积压否则新日志进不来老日志占满空间。我的策略是分三层入队时检查容量如果localStorage剩余空间不足或条目数超过上限比如5000条直接丢弃队列里最老的批次或者把最老的批次标记为降级丢弃按优先级淘汰错误日志、异常日志优先级高永远最先发性能采样、用户行为细粒度日志优先级低空间不足时先丢低优先级时效性淘汰日志队列里的数据超过24小时还没发出去基本可以认为永远也发不出去了要么网络持续断要么服务端已经挂了这时候再留着意义不大做一次过期清理。function cleanUpIfNeeded() { let raw localStorage.getItem(LOG_KEY); let queue raw ? JSON.parse(raw) : []; const now Date.now(); queue queue.filter(item now - item.timestamp MAX_AGE); queue queue.slice(-MAX_QUEUE_SIZE); localStorage.setItem(LOG_KEY, JSON.stringify(queue)); }4. 上报链路的可靠性设计ACK、序号与防重复把日志发出去了不代表就是不丢。你想想你发了一个批次服务端收到了但响应在弱网下丢失了前端不知道于是重试服务端又会收到一遍同样的日志。这就从丢包变成了重复包。对日志系统来说重复虽然不像丢失那么致命但重复日志会污染统计数据比如你统计页面报错次数一条错误被记了三次数据就失真了。所以完整的不丢包方案必须包含服务端的去重。4.1 前端生成日志序号服务端判重实操里最常用也最简单的方案是给每条日志或者每个批次生成一个唯一的log_id。前端每次生成日志时带上client_time客户端时间戳、client_seq一个自增序号、和随机串拼接出来的唯一ID。服务端收到日志后拿这个唯一ID去查是否已经处理过处理过就直接丢弃。function generateLogId() { return ${Date.now()}_${Math.random().toString(36).slice(2, 10)}_${seq}; }如果日志量大服务端每次查库判重会影响写入性能可以考虑用Redis布隆过滤器或者批量判重。如果是小型系统用内存里的LRU缓存记录最近处理过的log_id也行注意做好过期清理。4.2 ACK确认机制前端如何知道真的收到了前端想知道日志有没有发成功不能只看HTTP状态码。原因是HTTP 200只能说明服务端接收了请求不代表服务端把这个批次写入成功了比如服务端可能返回200后异步处理异步处理失败数据就丢了。对日志系统来说接收即成功通常就够了因为日志不是交易数据丢失一条不会影响业务正确性。所以我在服务端返回的响应体里包含一个ack_id字段表示服务端已经成功接收了哪个批次。前端收到ACK后才把对应批次从队列里删掉。如果前端收到200但没有ack_id那说明服务端处理有问题前端应该保留队列等待下次重试。const res await fetch(/api/log/batch, { method: POST, body: JSON.stringify({ batch_id, logs }), }); const data await res.json(); if (res.ok data.ack_id batch_id) { // 真正删除本地队列 queue.remove(batch_id); }这个ACK机制还有一个好处它能暴露服务端的真实处理能力。如果服务端经常不返回ACK你就能尽早发现日志通道的健康问题。4.3 服务端幂等设计重复日志的最佳处理姿势日志系统的服务端幂等处理和业务系统不太一样。业务系统通常要求同一请求只处理一次日志系统因为量大逐条判重的成本可能不划算所以通常会做批次级幂等同一个batch_id只接受第一次完整写入后续重复请求直接忽略。我在服务端采用的策略是这样的日志写入采用批量插入幂等表的方式。表里有个唯一索引batch_id插入时如果冲突就跳过批次内部的日志加上log_id唯一键重复插入时使用INSERT OR IGNOREMySQL是INSERT IGNOREPostgreSQL是ON CONFLICT DO NOTHING对特别重要的错误日志单独做逐条判重确保统计准确。这样做的好处是前端代码可以大胆重试不用纠结是不是重复了。网络不好就重发发了N次服务端也只会记录一次。前端逻辑一下子就简单了许多。5. 一整套可落地的实现方案与实测记录前面原理和设计讲了不少这里给出一套相对完整的代码骨架和实测结论可以直接抄作业后改造。5.1 核心代码骨架一个轻量的日志上报器我这里给一个基于localStorage队列 sendBeacon关页兜底 指数退避重试的完整实现。不依赖任何框架浏览器直接可用。class Logger { constructor(options {}) { this.url options.url || /api/log/batch; this.storageKey options.storageKey || log_queue; this.batchSize options.batchSize || 50; this.flushInterval options.flushInterval || 5000; this.maxQueueSize options.maxQueueSize || 5000; this.currentBatch []; this.timer null; this.inFlight false; this._init(); } _init() { // 定时批量发送 this.timer setInterval(() this.flush(), this.flushInterval); // 网络恢复时立刻尝试发送 window.addEventListener(online, () { this.flush(); }); // 关页时用beacon兜底 document.addEventListener(visibilitychange, () { if (document.visibilityState hidden) this.flush(true); }); window.addEventListener(pagehide, () this.flush(true)); window.addEventListener(offline, () { // 切到离线状态把当前批量数据入库避免丢失 this._persistBatch(); }); // 页面加载时尝试清理过期数据并发一次 this._loadQueue(); this.flush(); } log(level, message, extra {}) { this.currentBatch.push({ log_id: ${Date.now()}_${Math.random().toString(36).slice(2, 10)}_${(this._seq (this._seq || 0) 1)}, level, message, extra, ts: Date.now(), url: location.href, ua: navigator.userAgent, }); if (this.currentBatch.length this.batchSize) { this._persistBatch(); this.flush(); } } _persistBatch() { if (!this.currentBatch.length) return; try { const old this._loadQueue(); old.push(...this.currentBatch); // 按容量截断 const trimmed old.slice(-this.maxQueueSize); localStorage.setItem(this.storageKey, JSON.stringify(trimmed)); this.currentBatch []; } catch (e) { // 存储满了或序列化失败直接丢弃当前批 this.currentBatch []; } } _loadQueue() { try { return JSON.parse(localStorage.getItem(this.storageKey)) || []; } catch (e) { return []; } } _drain() { const queue this._loadQueue(); const batch queue.splice(0, this.batchSize); if (!batch.length) return null; localStorage.setItem(this.storageKey, JSON.stringify(queue)); return batch; } async flush(isLeaving false) { if (this.inFlight) return; this._persistBatch(); const batch this._drain(); if (!batch || !batch.length) return; if (isLeaving) { // 离场场景用 beacon 一次性发尽可能多的数据 try { navigator.sendBeacon(this.url, JSON.stringify(batch)); } catch (e) { // beacon失败就退回图片上报 const img new Image(); img.src ${this.url}?data${encodeURIComponent(JSON.stringify(batch))}; } return; } // 正常场景用 fetch 超时 ACK this.inFlight true; try { const controller new AbortController(); const timeoutId setTimeout(() controller.abort(), 8000); const res await fetch(this.url, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ batch_id: this._currentBatchId(), logs: batch }), signal: controller.signal, }); clearTimeout(timeoutId); if (res.ok) { // 已经发送成功批次已 drain 删除无需再处理 this._retryDelay 1000; } else { // 失败把批次放回队列头部 this._prependBatch(batch); this._scheduleRetry(); } } catch (e) { // 网络异常 / abort同样放回队列 this._prependBatch(batch); this._scheduleRetry(); } finally { this.inFlight false; } } _prependBatch(batch) { try { const old this._loadQueue(); const merged [...batch, ...old]; localStorage.setItem(this.storageKey, JSON.stringify(merged.slice(-this.maxQueueSize))); } catch (e) { // 失败就直接丢保证主流程不受影响 } } _scheduleRetry() { clearTimeout(this.timer); const delay Math.min(this._retryDelay || 1000, 5 * 60 * 1000); this.timer setTimeout(() { this._retryDelay (this._retryDelay || 1000) * 2; this.flush(); }, delay); } } const logger new Logger(); logger.log(info, user clicked button, { btn: #pay, page: checkout });这段代码的调度逻辑是正常情况靠定时器每5秒批量发一次发送失败就放回队列头部用指数退避重试网络恢复事件会打断退避立即flush用户切后台或关页时用sendBeacon把当前所有数据一次性打出去。核心状态都在localStorage里即使页面被杀下次打开也能继续发送。跑通这个骨架后再看两个细节。第一个是_drain()取批次后就立即从localStorage里删除了如果fetch失败再放回去。这个先删后发的设计可能会让你担心万一fetch发了但服务端收到了、只是响应丢了放回去的数据就会被重复发送。但没关系前面说过服务端做了batch_id/日志ID的幂等重复发送不会产生重复数据。宁重勿丢是日志上报的基本方针。第二个是_currentBatchId()我这里偷懒没实现。实际推荐用当前队列里第一条日志的log_id作为batch_id这样天然保证同一个批次重试时batch_id不变服务端就能正确去重。5.2 用DevTools和Fiddler实测三种场景代码写完之后我花了一个下午用Chrome DevTools和Fiddler做了实测。测试环境是本地起的Node服务前端用一个模拟用户连续点击按钮的页面每点击一次产生一条日志。场景一弱网。Chrome DevTools的Network面板里设成Slow 3G每个请求延迟大约1.6秒、带宽极低。这个场景下fetch请求几乎都处于pending状态8秒超时后一批日志被放回队列等待重试。观察发现指数退避的重试时间从1秒逐步变成2秒、4秒在第5次重试后网络状态好转批次成功发出。结论弱网下日志没有丢只是延迟了。关键是fetch必须带超时否则请求会一直悬挂队列会越积越多。场景二断网。我直接断掉WiFi让页面进入离线状态。此时所有fetch请求立即失败日志批量堆积在localStorage里。接着手动触发window.dispatchEvent(new Event(online))代码立即开始flush批次恢复发送。实测中由于Chrome离线模式下fetch会立刻reject所以不用等超时堆积速度很快但都稳定保存在localStorage里页面刷新后数据还在。结论断网场景真正考验的是持久化能力localStorage可用IndexedDB当然更稳。场景三关页。我在页面打开后的第3秒直接关闭标签页此时日志队列里有20条未发送数据。关页的瞬间visibilitychange触发flush(true)调用sendBeacon。服务端日志显示这20条数据在页面关闭后约0.5秒收到。我又模拟了在页面中点击跳转到另一个域名的情况pagehide触发同样生效。结论sendBeacon是关页场景下唯一能稳定把数据送出去的方案。注意如果不用sendBeacon用fetch的话关页后数据100%丢失。我还做了一组对照组把flush(true)里的sendBeacon换成普通fetch。结果是服务端完全没有收到这批日志因为页面已经被销毁fetch请求永远没有到达服务端。这个对照实验足够说明问题了。5.3 实测中踩到的几个坑和最终的避坑清单一个下午的测试踩了大概五个坑我觉得每一个都值得写下来坑1localStorage在隐私模式下写入会抛异常。Safari隐私模式、Chrome无痕模式下往localStorage里写数据会直接抛QuotaExceededError。用户隐私模式下访问页面日志系统直接崩溃了不行。处理方式就是try-catch包住所有存储读写失败时退化为纯内存队列不做持久化保证页面主功能不受影响。坑2sendBeacon传JSON对象是隐式转成[object Object]。我之前在上面代码里用的是JSON.stringify(batch)后直接传正确。但如果你图省事直接传对象服务端收到的就是一个没有任何日志内容的字符串排起错来非常迷惑。注意Beacon的Content-Type默认是text/plain服务端解析时要按文本处理。坑3visibilitychange的触发时机比想象中早。用户切换Tab到后台时visibilityState变为hidden此时页面还活着网络也还在。如果你在hidden时就把队列全清空了会有在后台期间新产生的日志没有渠道发出因为页面已不可见后续事件可能不再触发。所以flush(true)只应该发当前已有的数据不应该把后续新日志的入队逻辑也禁用掉。坑4服务端响应慢了前端仍会判定失败。我在Node服务端故意加了2秒延迟模拟慢响应结果前端8秒超时没触发但页面关闭时Beacon请求还没结束Chrome在关页时可能丢弃它。后来我优化服务端把这个日志接口改成收到请求后立即返回200异步批量写入Beacon可靠性明显提升。日志接口的服务端代码永远不要把业务逻辑放在响应之前。坑5批量报告里的日志量不要贪多。刚开始我想用sendBeacon一次传1MB的数据结果Chrome直接返回false数据没发出去。后来我把批次控制在64KB以内同时用压缩才稳定过关。发日志不是拉流量小批次高频发比大批次偶发发要靠谱得多。结合上面的实测我把最终的方案总结成一张决策表方便你对照自己的场景选型场景上报方式失败处理可靠性页面正常存活fetch 超时 ACK入队重试指数退避高可确认页面进入后台sendBeacon无需处理浏览器保证尽力送达较高页面关闭/跳转sendBeacon / Image兜底基本无法重试靠服务端幂等高断网本地队列暂存online后flush自动重试退避高但延迟弱网合并小批次 超时控制超时重试退避高但延迟localStorage不可用内存队列降级丢弃不做持久化中如果你做的是纯前端小团队项目不需要服务端做全套ACK和幂等的话至少也要保证三个阶段不出错本地存储、批量发送、Beacon兜底。有了这三层95%以上的丢日志问题都能解决。剩下的5%就是服务端的重复数据清洗和极端的网络场景那部分等量上来了再慢慢优化不迟。最后再分享一个我个人的习惯任何上报系统上线前我都会做一次关页面断网的破坏性测试就是故意不清理网络、故意秒关页然后用服务端日志核对实际收到的数据和前端产生的数据量是否一致。这个测试每次都能发现一两个预想不到的问题。你现在手头有现成的上报模块的话建议也拿它试一把我猜你那个看起来稳定的系统大概率也能查出几个隐藏的丢包点。 前端日志上报不丢失：弱网、断网、关页场景的完整解决方案
前端日志上报这事儿做不好是真头疼。你线上出了个偶发bug想看用户操作路径结果最后几步的日志死活没上来排查链路断在半路或者你明明在埋点代码里写了上报用户反馈我就是点了按钮没反应后台却连这条点击记录都没收到。调查起来发现十有八九都出在三个地方用户当时网络很烂、用户刚好断网了、用户操作完就直接关了页面。我今天就把这块的完整思路讲清楚——从根因分析到一套可以直接落地的代码骨架再到我用工具模拟弱网、断网、秒关页的实测结果一次给你讲全。内容适合正在做前端监控、埋点上报的开发者也适合那些写业务代码时顺带接上报需求的同学。1. 日志上报为什么那么容易丢三个典型场景的丢包根因很多同学一上来就写fetch(/log, { data })用着挺顺手一到线上就开始丢数据。不是fetch不好而是你没有想过一个问题日志上报这个场景和数据请求在本质上就不是一回事。业务请求丢了用户会立刻发现日志请求丢了没有任何人知道只有在事后排查时才悔之晚矣。所以第一步不是写代码而是把丢包到底发生在哪这件事拆清楚。1.1 弱网场景TCP重传的代价和请求超时弱网环境比如地铁上、电梯里、地下车库、偏远地区的3G网络下带宽不稳定、丢包率高TCP为了保证可靠性会反复重传。这时候你发出的HTTP请求可能一直处于pending状态迟迟得不到响应。问题在于绝大多数上报代码都用fetch或XMLHttpRequest它们默认是有超时时间的超时之后请求就被中断。而在弱网下请求可能在超时边缘被卡住——明明服务端已经收到了但响应迟迟回不来前端认为是失败了Enter会重发结果服务端收到一堆重复数据。反过来也可能请求根本没到服务端前端以为发了实际进了黑洞。更隐蔽的一点是弱网状态下用户的网络质量是波动的。某个时间点网络差5秒后可能就好了。如果你在上报代码里做了失败就丢弃或者失败就立即重试那么大量日志会在网络抖动期间被浪费掉。正确的思路是把日志先落到本地等服务端确认收到再删除确认失败的话就留在本地等下一次机会。1.2 断网场景请求发出即坠机navigator.onLine还不可靠断网场景比弱网更极端。用户进电梯信号直接消失用户开了飞行模式用户在移动端切换WiFi的瞬间网络处于空白期。这个状态下发出请求几乎是必丢的。但真正坑人的是navigator.onLine这个API。它只表示浏览器当前是否认为有网络连接但它判断依据只是网络接口是否存在并不是真的发了一个探测包。你连上了路由器但路由器本身断网navigator.onLine依然返回true。所以指望靠它来判断是否断网再决定是否上报完全不靠谱。正确姿势是监听两个事件offline和online。浏览器在确认网络断开时会触发offline事件恢复时触发online事件。你可以在这些事件里切换上报策略——offline时把所有日志堆积到本地队列online时立刻把队列里的数据全部flush出去。需要注意的是这个在线/离线事件在部分旧版浏览器和WebView里触发时机比较滞后所以事件只是一个辅助信号核心兜底还是服务端确认机制。1.3 关页场景浏览器根本不给你机会三种场景里最容易被忽视、也最容易造成最后一条日志丢失的就是用户直接关页面。想想看用户最常怎么离开页面关闭标签页、刷新、跳转到其他域名、在手机上直接Home键切后台然后杀掉App。这些操作触发的是页面生命周期结束浏览器会清理这个页面所有的异步资源。你用fetch发出去的请求、甚至setTimeout里的逻辑都可能根本来不及执行完毕。fetch在页面销毁时会被直接中断这是浏览器行为不是你代码能挽回的。很多人在beforeunload事件里发同步XHR想借着同步请求强制把日志送出去。同步XHR确实能阻塞页面销毁一小段时间但浏览器现在对同步XHR的限制度很大主线程卡顿、弹窗警告而且移动端浏览器经常忽略这个阻塞。就算请求发出去了快速切断的网络也会在连接建立前就被打断。总之关页场景必须用专门的机制来解决这个后面单独讲。2. 关页上报的正解sendBeacon与visibilitychange双保险关页丢日志这个问题行业里已经有一个公认的最优解navigator.sendBeacon()。它是一个专门为页面卸载时发送数据设计的API。2.1 sendBeacon为什么是首选sendBeacon(url, data)做的事情很简单把一个数据包交给浏览器剩下的由浏览器负责发送。这个API的特别之处在于它不要求页面继续存活而是利用浏览器层的机制把数据发送出去页面销毁不影响发送结果它不会影响页面卸载性能是异步的不阻塞用户它对短小的数据非常可靠是关页上报的首选方案。需要注意sendBeacon有一定限制数据量一般建议控制在64KB以内实际浏览器实现可能略大但不建议赌并且只支持POST。如果你有大量日志要上报不能指望一个Beacon全塞进去应该合并成小批次。用户关页时塞几KB的日志是没问题的。另一个细节是sendBeacon的Content-Type默认是text/plain或者application/x-www-form-urlencoded不能直接传JSON对象。所以我通常把日志数组JSON序列化之后再传字符串服务端按文本解析即可。function sendByBeacon(logs) { const payload JSON.stringify(logs); navigator.sendBeacon(/api/log/batch, payload); }如果sendBeacon返回false数据量大或浏览器不支持再降级到其他方案。2.2 降级方案动态图片和同步XHR谁更靠谱老一批的前端监控库用的是1x1 GIF图片上报也就是new Image().src /api/log?data...。图片请求不阻塞页面加载而且就算不做DOM插入浏览器也会正常发出请求。但图片请求是GET方式URL长度限制大约2KB到8KB各浏览器不同和Beacon的POST方式没法比。在关页场景里图片请求能发出去的概率比fetch要高但依然不是100%可靠。有人说那用同步XHR不就得了实测结果是在Chrome里同步XHR确实会阻塞unload一小段时间给请求留出一定发送窗口但代价是用户体验变差——页面卡顿、浏览器可能有性能警告而且在移动端Safari里经常不生效。我的建议是Beacon优先Image兜底同步XHR尽量不用除非你确认旧内核WebView必须靠它。2.3 捕获所有关页路径pagehide、visibilitychange、beforeunload的配合很多人只写了beforeunload但页面还有好几种非传统离开的方式用户切后台不销毁页面只是不可见、移动端浏览器杀掉后台页面、前进后退缓存bfcache等。它们不一定触发beforeunload。行业内推荐的最佳实践是pagehide事件它在页面被销毁或进入bfcache时都会触发兼容性也OK。同时要注意visibilitychange当document.visibilityState变成hidden时意味着用户已经看不到页面了此时是发送日志的黄金窗口——如果用户切后台这个事件一定会触发如果用户直接关闭页面这个事件在beforeunload/pagehide之前触发。所以关页上报的正确姿势是function flushOnLeave() { const logs queue.drain(); if (!logs.length) return; if (navigator.sendBeacon) { navigator.sendBeacon(/api/log/batch, JSON.stringify(logs)); } else { const img new Image(); img.src /api/log?data encodeURIComponent(JSON.stringify(logs)); } } document.addEventListener(visibilitychange, () { if (document.visibilityState hidden) { flushOnLeave(); } }); window.addEventListener(pagehide, flushOnLeave);这里有个顺序问题要注意visibilitychange先触发pagehide在后所以flushOnLeave必须是幂等的第一次调用就把队列抽空第二次调用进来发现没数据直接返回即可。2.4 服务端配合Beacon接口要特殊处理响应Beacon的发送是浏览器后台完成的前端根本拿不到响应体。所以服务端接收Beacon时不能按普通业务接口的逻辑来做——比如要求在响应里返回业务码、要求前端校验响应等这对Beacon来说都是白扯。服务端要做的是快速返回200不做过重逻辑把请求体原样保存解析JSON日志数组后直接入库或送消息队列接口单独挂一个路径和生产业务接口隔离避免占用Tomcat连接池。很多团队忽略Beacon接口的响应速度服务端处理慢了浏览器可能认为Beacon失败而重试造成重复。实际经验是这个接口应该比普通接口更轻量记录日志不需要事务、不需要实时返回明细丢了再补、异步落地都行。3. 断网弱网的第一道防线本地暂存与离线队列关页问题解决了接下来是断网和弱网。核心思路就一条日志先写本地确认服务端收到后再删否则一直留着待重试。这就是一个预写日志 确认删除的队列模型和数据库的WAL预写日志思路很像。3.1 存储选型localStorage vs IndexedDB别选错用途前端本地存储最常见的两个候选是localStorage和IndexedDB。localStorage优点API简单、同步读写编码上省事、兼容性好到离谱、容量约为5MB。缺点只能存字符串读和写会同步阻塞主线程数据量大了以后会有明显的性能损耗而且不支持事务。IndexedDB优点容量大通常几百MB甚至更多、异步读写不阻塞UI、支持索引和事务。缺点API上手成本高不过用idb这类库封装后也不复杂。日志上报这个场景我的建议很直接如果单条日志小、量不大每天几千到几万条每条几百字节用localStorage完全够代码简单出问题好排查如果日志量大每次操作都带payload、截图、性能数据用IndexedDB否则5MB很容易爆很多成熟方案是双模混合高频小日志用localStorage大体积用IndexedDB。我自己的项目里默认选localStorage因为日志队列在正常情况下是空的发完就删只有断网时才会一直累积容量压力其实不大。真正需要担心的反而是如果你的日志常驻本地不清理localStorage里堆积几千条每次同步写入都会卡一下主线程。3.2 队列设计批量合并、节流与压缩日志队列的本质是一个数组入队就是pushflush的时候一次性取出来。但直接一个数组裸奔有很多问题第一要合并。每一条日志都单独发一个HTTP请求在弱网下是灾难。正确做法是定时器批量日志先入队每5秒或者积满50条时合并成一个批次发送。这样一来断网场景下堆积的也是合并后的批次而不是几百个待发请求。第二要节流。高频事件mousemove、scroll、页面性能数据产生的埋点可能是每秒几十条。直接入队会把队列撑爆。常见做法是前端采样率阈值比如同一个类型的事件1秒内最多记录1条或者按10%概率采样。第三要考虑压缩。如果日志量大或者要传的内容是明文字符串堆在一起可以考虑pako这类库对JSON字符串做deflate压缩压缩后再base64编码传输。实测下来对于重复字段多的日志压缩率能到70%以上这能显著减少弱网下的传输时间和Beacon的大小限制压力。3.3 重试与指数退避别在弱网恢复瞬间雪崩队列里的日志flush失败后什么时候重试这个问题处理不好就是在给自己挖坑。假设用户断网5分钟你每分钟尝试flush一次每次发100条数据5分钟里就有500条积压。等网络恢复的那一刻如果所有人都立刻flush服务端可能瞬间被打爆。这也是日志上报系统常见的断网恢复雪崩。所以重试一定要带退避策略。我的做法是用指数退避基础间隔从1秒开始失败一次间隔翻倍最多退避到5分钟。网络恢复时触发online事件可以立即尝试一次但不保证一定成功只有收到服务端ACK确认才认为这个批次彻底发出去了。let retryDelay 1000; const MAX_RETRY_DELAY 5 * 60 * 1000; async function flushQueue() { const batch queue.drain(); if (!batch.length) return; try { const ok await sendBatch(batch); if (ok) { retryDelay 1000; // 继续尝试下一个批次 flushQueue(); } else { queue.unshift(batch); scheduleRetry(); } } catch (e) { queue.unshift(batch); scheduleRetry(); } } function scheduleRetry() { setTimeout(flushQueue, retryDelay); retryDelay Math.min(retryDelay * 2, MAX_RETRY_DELAY); }注意一个细节queue.unshift(batch)是把批次放回队头保证日志顺序不被打乱。业务上报场景顺序不一定重要但如果你有用户操作时间线的需求顺序错乱会影响排查。3.4 队列容量与清理策略localStorage爆了怎么办所有存储方案都有上限localStorage 5MB、IndexedDB也可能被浏览器清理。日志队列不能无限制积压否则新日志进不来老日志占满空间。我的策略是分三层入队时检查容量如果localStorage剩余空间不足或条目数超过上限比如5000条直接丢弃队列里最老的批次或者把最老的批次标记为降级丢弃按优先级淘汰错误日志、异常日志优先级高永远最先发性能采样、用户行为细粒度日志优先级低空间不足时先丢低优先级时效性淘汰日志队列里的数据超过24小时还没发出去基本可以认为永远也发不出去了要么网络持续断要么服务端已经挂了这时候再留着意义不大做一次过期清理。function cleanUpIfNeeded() { let raw localStorage.getItem(LOG_KEY); let queue raw ? JSON.parse(raw) : []; const now Date.now(); queue queue.filter(item now - item.timestamp MAX_AGE); queue queue.slice(-MAX_QUEUE_SIZE); localStorage.setItem(LOG_KEY, JSON.stringify(queue)); }4. 上报链路的可靠性设计ACK、序号与防重复把日志发出去了不代表就是不丢。你想想你发了一个批次服务端收到了但响应在弱网下丢失了前端不知道于是重试服务端又会收到一遍同样的日志。这就从丢包变成了重复包。对日志系统来说重复虽然不像丢失那么致命但重复日志会污染统计数据比如你统计页面报错次数一条错误被记了三次数据就失真了。所以完整的不丢包方案必须包含服务端的去重。4.1 前端生成日志序号服务端判重实操里最常用也最简单的方案是给每条日志或者每个批次生成一个唯一的log_id。前端每次生成日志时带上client_time客户端时间戳、client_seq一个自增序号、和随机串拼接出来的唯一ID。服务端收到日志后拿这个唯一ID去查是否已经处理过处理过就直接丢弃。function generateLogId() { return ${Date.now()}_${Math.random().toString(36).slice(2, 10)}_${seq}; }如果日志量大服务端每次查库判重会影响写入性能可以考虑用Redis布隆过滤器或者批量判重。如果是小型系统用内存里的LRU缓存记录最近处理过的log_id也行注意做好过期清理。4.2 ACK确认机制前端如何知道真的收到了前端想知道日志有没有发成功不能只看HTTP状态码。原因是HTTP 200只能说明服务端接收了请求不代表服务端把这个批次写入成功了比如服务端可能返回200后异步处理异步处理失败数据就丢了。对日志系统来说接收即成功通常就够了因为日志不是交易数据丢失一条不会影响业务正确性。所以我在服务端返回的响应体里包含一个ack_id字段表示服务端已经成功接收了哪个批次。前端收到ACK后才把对应批次从队列里删掉。如果前端收到200但没有ack_id那说明服务端处理有问题前端应该保留队列等待下次重试。const res await fetch(/api/log/batch, { method: POST, body: JSON.stringify({ batch_id, logs }), }); const data await res.json(); if (res.ok data.ack_id batch_id) { // 真正删除本地队列 queue.remove(batch_id); }这个ACK机制还有一个好处它能暴露服务端的真实处理能力。如果服务端经常不返回ACK你就能尽早发现日志通道的健康问题。4.3 服务端幂等设计重复日志的最佳处理姿势日志系统的服务端幂等处理和业务系统不太一样。业务系统通常要求同一请求只处理一次日志系统因为量大逐条判重的成本可能不划算所以通常会做批次级幂等同一个batch_id只接受第一次完整写入后续重复请求直接忽略。我在服务端采用的策略是这样的日志写入采用批量插入幂等表的方式。表里有个唯一索引batch_id插入时如果冲突就跳过批次内部的日志加上log_id唯一键重复插入时使用INSERT OR IGNOREMySQL是INSERT IGNOREPostgreSQL是ON CONFLICT DO NOTHING对特别重要的错误日志单独做逐条判重确保统计准确。这样做的好处是前端代码可以大胆重试不用纠结是不是重复了。网络不好就重发发了N次服务端也只会记录一次。前端逻辑一下子就简单了许多。5. 一整套可落地的实现方案与实测记录前面原理和设计讲了不少这里给出一套相对完整的代码骨架和实测结论可以直接抄作业后改造。5.1 核心代码骨架一个轻量的日志上报器我这里给一个基于localStorage队列 sendBeacon关页兜底 指数退避重试的完整实现。不依赖任何框架浏览器直接可用。class Logger { constructor(options {}) { this.url options.url || /api/log/batch; this.storageKey options.storageKey || log_queue; this.batchSize options.batchSize || 50; this.flushInterval options.flushInterval || 5000; this.maxQueueSize options.maxQueueSize || 5000; this.currentBatch []; this.timer null; this.inFlight false; this._init(); } _init() { // 定时批量发送 this.timer setInterval(() this.flush(), this.flushInterval); // 网络恢复时立刻尝试发送 window.addEventListener(online, () { this.flush(); }); // 关页时用beacon兜底 document.addEventListener(visibilitychange, () { if (document.visibilityState hidden) this.flush(true); }); window.addEventListener(pagehide, () this.flush(true)); window.addEventListener(offline, () { // 切到离线状态把当前批量数据入库避免丢失 this._persistBatch(); }); // 页面加载时尝试清理过期数据并发一次 this._loadQueue(); this.flush(); } log(level, message, extra {}) { this.currentBatch.push({ log_id: ${Date.now()}_${Math.random().toString(36).slice(2, 10)}_${(this._seq (this._seq || 0) 1)}, level, message, extra, ts: Date.now(), url: location.href, ua: navigator.userAgent, }); if (this.currentBatch.length this.batchSize) { this._persistBatch(); this.flush(); } } _persistBatch() { if (!this.currentBatch.length) return; try { const old this._loadQueue(); old.push(...this.currentBatch); // 按容量截断 const trimmed old.slice(-this.maxQueueSize); localStorage.setItem(this.storageKey, JSON.stringify(trimmed)); this.currentBatch []; } catch (e) { // 存储满了或序列化失败直接丢弃当前批 this.currentBatch []; } } _loadQueue() { try { return JSON.parse(localStorage.getItem(this.storageKey)) || []; } catch (e) { return []; } } _drain() { const queue this._loadQueue(); const batch queue.splice(0, this.batchSize); if (!batch.length) return null; localStorage.setItem(this.storageKey, JSON.stringify(queue)); return batch; } async flush(isLeaving false) { if (this.inFlight) return; this._persistBatch(); const batch this._drain(); if (!batch || !batch.length) return; if (isLeaving) { // 离场场景用 beacon 一次性发尽可能多的数据 try { navigator.sendBeacon(this.url, JSON.stringify(batch)); } catch (e) { // beacon失败就退回图片上报 const img new Image(); img.src ${this.url}?data${encodeURIComponent(JSON.stringify(batch))}; } return; } // 正常场景用 fetch 超时 ACK this.inFlight true; try { const controller new AbortController(); const timeoutId setTimeout(() controller.abort(), 8000); const res await fetch(this.url, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ batch_id: this._currentBatchId(), logs: batch }), signal: controller.signal, }); clearTimeout(timeoutId); if (res.ok) { // 已经发送成功批次已 drain 删除无需再处理 this._retryDelay 1000; } else { // 失败把批次放回队列头部 this._prependBatch(batch); this._scheduleRetry(); } } catch (e) { // 网络异常 / abort同样放回队列 this._prependBatch(batch); this._scheduleRetry(); } finally { this.inFlight false; } } _prependBatch(batch) { try { const old this._loadQueue(); const merged [...batch, ...old]; localStorage.setItem(this.storageKey, JSON.stringify(merged.slice(-this.maxQueueSize))); } catch (e) { // 失败就直接丢保证主流程不受影响 } } _scheduleRetry() { clearTimeout(this.timer); const delay Math.min(this._retryDelay || 1000, 5 * 60 * 1000); this.timer setTimeout(() { this._retryDelay (this._retryDelay || 1000) * 2; this.flush(); }, delay); } } const logger new Logger(); logger.log(info, user clicked button, { btn: #pay, page: checkout });这段代码的调度逻辑是正常情况靠定时器每5秒批量发一次发送失败就放回队列头部用指数退避重试网络恢复事件会打断退避立即flush用户切后台或关页时用sendBeacon把当前所有数据一次性打出去。核心状态都在localStorage里即使页面被杀下次打开也能继续发送。跑通这个骨架后再看两个细节。第一个是_drain()取批次后就立即从localStorage里删除了如果fetch失败再放回去。这个先删后发的设计可能会让你担心万一fetch发了但服务端收到了、只是响应丢了放回去的数据就会被重复发送。但没关系前面说过服务端做了batch_id/日志ID的幂等重复发送不会产生重复数据。宁重勿丢是日志上报的基本方针。第二个是_currentBatchId()我这里偷懒没实现。实际推荐用当前队列里第一条日志的log_id作为batch_id这样天然保证同一个批次重试时batch_id不变服务端就能正确去重。5.2 用DevTools和Fiddler实测三种场景代码写完之后我花了一个下午用Chrome DevTools和Fiddler做了实测。测试环境是本地起的Node服务前端用一个模拟用户连续点击按钮的页面每点击一次产生一条日志。场景一弱网。Chrome DevTools的Network面板里设成Slow 3G每个请求延迟大约1.6秒、带宽极低。这个场景下fetch请求几乎都处于pending状态8秒超时后一批日志被放回队列等待重试。观察发现指数退避的重试时间从1秒逐步变成2秒、4秒在第5次重试后网络状态好转批次成功发出。结论弱网下日志没有丢只是延迟了。关键是fetch必须带超时否则请求会一直悬挂队列会越积越多。场景二断网。我直接断掉WiFi让页面进入离线状态。此时所有fetch请求立即失败日志批量堆积在localStorage里。接着手动触发window.dispatchEvent(new Event(online))代码立即开始flush批次恢复发送。实测中由于Chrome离线模式下fetch会立刻reject所以不用等超时堆积速度很快但都稳定保存在localStorage里页面刷新后数据还在。结论断网场景真正考验的是持久化能力localStorage可用IndexedDB当然更稳。场景三关页。我在页面打开后的第3秒直接关闭标签页此时日志队列里有20条未发送数据。关页的瞬间visibilitychange触发flush(true)调用sendBeacon。服务端日志显示这20条数据在页面关闭后约0.5秒收到。我又模拟了在页面中点击跳转到另一个域名的情况pagehide触发同样生效。结论sendBeacon是关页场景下唯一能稳定把数据送出去的方案。注意如果不用sendBeacon用fetch的话关页后数据100%丢失。我还做了一组对照组把flush(true)里的sendBeacon换成普通fetch。结果是服务端完全没有收到这批日志因为页面已经被销毁fetch请求永远没有到达服务端。这个对照实验足够说明问题了。5.3 实测中踩到的几个坑和最终的避坑清单一个下午的测试踩了大概五个坑我觉得每一个都值得写下来坑1localStorage在隐私模式下写入会抛异常。Safari隐私模式、Chrome无痕模式下往localStorage里写数据会直接抛QuotaExceededError。用户隐私模式下访问页面日志系统直接崩溃了不行。处理方式就是try-catch包住所有存储读写失败时退化为纯内存队列不做持久化保证页面主功能不受影响。坑2sendBeacon传JSON对象是隐式转成[object Object]。我之前在上面代码里用的是JSON.stringify(batch)后直接传正确。但如果你图省事直接传对象服务端收到的就是一个没有任何日志内容的字符串排起错来非常迷惑。注意Beacon的Content-Type默认是text/plain服务端解析时要按文本处理。坑3visibilitychange的触发时机比想象中早。用户切换Tab到后台时visibilityState变为hidden此时页面还活着网络也还在。如果你在hidden时就把队列全清空了会有在后台期间新产生的日志没有渠道发出因为页面已不可见后续事件可能不再触发。所以flush(true)只应该发当前已有的数据不应该把后续新日志的入队逻辑也禁用掉。坑4服务端响应慢了前端仍会判定失败。我在Node服务端故意加了2秒延迟模拟慢响应结果前端8秒超时没触发但页面关闭时Beacon请求还没结束Chrome在关页时可能丢弃它。后来我优化服务端把这个日志接口改成收到请求后立即返回200异步批量写入Beacon可靠性明显提升。日志接口的服务端代码永远不要把业务逻辑放在响应之前。坑5批量报告里的日志量不要贪多。刚开始我想用sendBeacon一次传1MB的数据结果Chrome直接返回false数据没发出去。后来我把批次控制在64KB以内同时用压缩才稳定过关。发日志不是拉流量小批次高频发比大批次偶发发要靠谱得多。结合上面的实测我把最终的方案总结成一张决策表方便你对照自己的场景选型场景上报方式失败处理可靠性页面正常存活fetch 超时 ACK入队重试指数退避高可确认页面进入后台sendBeacon无需处理浏览器保证尽力送达较高页面关闭/跳转sendBeacon / Image兜底基本无法重试靠服务端幂等高断网本地队列暂存online后flush自动重试退避高但延迟弱网合并小批次 超时控制超时重试退避高但延迟localStorage不可用内存队列降级丢弃不做持久化中如果你做的是纯前端小团队项目不需要服务端做全套ACK和幂等的话至少也要保证三个阶段不出错本地存储、批量发送、Beacon兜底。有了这三层95%以上的丢日志问题都能解决。剩下的5%就是服务端的重复数据清洗和极端的网络场景那部分等量上来了再慢慢优化不迟。最后再分享一个我个人的习惯任何上报系统上线前我都会做一次关页面断网的破坏性测试就是故意不清理网络、故意秒关页然后用服务端日志核对实际收到的数据和前端产生的数据量是否一致。这个测试每次都能发现一两个预想不到的问题。你现在手头有现成的上报模块的话建议也拿它试一把我猜你那个看起来稳定的系统大概率也能查出几个隐藏的丢包点。