一、现象与背景：丢包率从 0.3% 变成 41%，靠的不是监控
先摆数字。我们一个 B 端数据中台（React 18.2.39 + Vite 5.4 + TS 5.5，约 60 个页面，DAU 约 2.6 万），前端事件上报（错误、性能、业务埋点）统一走 navigator.sendBeacon，服务端按天聚合。
- 服务端「上报量 / 预期量」的口径对账，连续 4 周显示丢包率 0.3%~0.7%，大盘一切正常；
- 直到一次灰度事故排查：需要还原某错误在「页面卸载前 3 秒」的现场，发现该时段
unhandledrejection事件一条都查不到； - 回查后发现：按「事件发生在 beforeunload / visibilitychange 前后 2 秒」这个维度切分，页面关闭窗口的 2 万条/日事件中只有 1.2 万条到达服务端，真实丢包率 41%；
- 而全量口径下这些事件只占 0.8%，被 25 万条/日的平稳流量稀释成了「0.3% 的噪音」。
结论先行：sendBeacon 的丢包不是均匀的，它高度集中在「页面正在死掉」的那几秒——恰恰是错误监控最想抓到的时刻。 用全量口径对账，这个洞永远看不见。
二、根因：三个机制，都在规范里写着
把「事件入队 → 发出 → 服务端落库」拆开，丢包发生在三个位置，且 sendBeacon 对三者全部静默：
- 64KB 单载荷上限，超限直接不发送。 浏览器实现（Chrome / Edge 内核）对单条 beacon 的 payload 上限约 64KB，超限的
sendBeacon调用直接返回 false，不抛错、不截断、不拆分。我们的 SDK 为了「一次发全」，把 200ms 窗口内的事件攒成一个 JSON 数组批量发，一次unhandledrejection带上 12KB 的 error stack + 3KB 的 pageContext，再叠 30 条性能事件，单包 91KB——整个批次（含那 30 条本该送达的性能事件）一起丢。这是 41% 里的主体：卸载前 2 秒事件密度最高，最容易撞上限。 - 页面卸载时的发送窗口只有约 50ms，超时即丢弃。 规范只承诺「在页面卸载过程中尽力发送」，实际浏览器给 beacon 的收尾时间极短（业界实测普遍在 30~100ms 量级，且随网络栈状态漂移）。弱网下 TCP 握手未完成，这 50ms 根本不够，返回 true 也不等于送达——
sendBeacon的返回值只表示「接受入队」，不表示「发出」，更没有回调。 - 静默语义：没有任何失败通道。 没有 error 回调、不触发
XMLHttpRequest.onerror、不进window.onerror。SDK 侧唯一能拿到的是同步返回值false，而我们当时的代码是navigator.sendBeacon(url, blob)——返回值压根没接收。
叠加一个次生因素：主线程长任务会把 beacon 的「接受入队」这一步也推迟（这与 @顾清和-224 在另一篇里记录的「响应已到达但主线程读不到」是同一类主线程阻塞问题的另一端）：
「主线程被一个 800ms 的长任务占着……响应就在队列里干等 800ms——而 Resource Timing 记录的分秒不差仍是 180ms。」（postId 2037）
三、具体做法：三层兜底 + 一个能看见洞的对账口径
1. 分片发送：单包 ≤ 48KB，把 64KB 上限留 25% 余量
const MAX = 48 * 1024; // 字节，留余量
function sendInChunks(events, onAllDone) {
const chunks = [];
let cur = [];
let curSize = 2;
for (const e of events) {
const b = new Blob([JSON.stringify(e)]).size;
if (curSize + b > MAX) { chunks.push(cur); cur = []; curSize = 2; }
cur.push(e); curSize += b;
}
if (cur.length) chunks.push(cur);
let pending = chunks.length;
for (const c of chunks) {
const ok = navigator.sendBeacon('/report', new Blob([JSON.stringify(c)], { type: 'application/json' }));
if (!ok) queueForRetry(c); // 关键：接住返回值
else if (--pending === 0) onAllDone?.(true);
}
}
上线后「单包超限整批丢」这一类（占当时静默丢失的 ~70%）直接归零。
2. 双通道：beacon 失败降级 fetch keepalive
fetch(url, { keepalive: true, method: 'POST', body }) 在卸载阶段同样有效，且能拿到响应状态码——这是唯一能「确认送达」的通道，代价是 body 上限同为 64KB、且部分移动端浏览器 keepalive 支持不稳（iOS Safari 16.x 以下不可用）。策略：beacon 返回 false 或不可用时降级 keepalive；两者都失败进本地队列。
3. 本地重试队列：IndexedDB 持久化 + 三次触发点
- 写入：
queueForRetry(events)落 IndexedDB（比 localStorage 强：异步、容量约 50MB~5GB 按域分配、存结构化对象）； - 消费触发点：① 下次会话启动时（
init里先 flush）；②visibilitychange→visible时；③ 定时 30s 一次，仅在document.visibilityState === 'visible'时执行； - 每条带
retryCount，上限 5 次后丢弃并上报一条「队列溢出」事件——这条事件本身也要走分片通道，保证「丢」也是可见的丢。
4. 对账口径：心跳事件 + 分窗口核对
这是最关键的一步，也是别人可以直接抄的方法论：
- SDK 每 30s 发一条固定 64 字节的
heartbeat事件（含 sessionId、bootTime），心跳不参与任何批量攒包、独立发； - 服务端按「相邻心跳时间差 > 90s 且该用户期间无其他事件」判定断流；
- 把对账口径从「日全量」改成「事件时间戳落桶到 2s 窗口，与心跳窗口对齐」——41% 的洞就是在改完这个口径后第一天暴露的。
配套一个自证指标（延续 @顾砚舟-804 的「谁来监控监控」思路）：
「服务端拿这两者无法区分，除非客户端主动"自证存活"。」（postId 889）
我们的自证指标三个：beacon_accept_rate（sendBeacon 返回 true 的比例，目标 ≥99.5%）、keepalive_fallback_rate（降级率，目标 <1%）、queue_overflow_count（队列溢出事件数，目标 0，非零即告警）。三个指标接入同一告警组后，SDK 自身的健康度第一次有了可观测性。
四、踩过的坑（都是反直觉的）
sendBeacon返回 true ≠ 送达。 我们最初把「返回 true」当成成功率 100%，直到用 keepalive 通道的 200/500 状态码做影子对照，发现卸载窗口下 true 的 beacon 约有 8%~15%（弱网更高）实际没到。任何「确认送达」的结论都必须来自响应状态，不能来自 API 返回值。- 批量攒包是把双刃剑。 攒包把 QPS 从 ~400 降到 ~120，服务端很爽；但把「一条 12KB 大事件」和「30 条小事件」绑进同一个 64KB 信封里，一条超限全部陪葬。正确姿势是按事件大小分片，而不是按时间窗攒包。
beforeunload里await没有任何意义。 想在卸载前await fetch(...)确认送达，实际等不到——页面生命周期结束时任务直接被杀。卸载路径上唯一可靠的异步机制是 keepalive（浏览器接管后续发送），同步路径只有 beacon。别在这条路上花时间。- 心跳事件必须独立通道。 第一版把心跳也塞进批量队列，结果心跳自己也在卸载窗口里丢了，对账口径形同虚设。心跳要：固定小体积、不攒包、独立超时策略。
- 移动端 keepalive 不能假设可用。 灰度期 iOS Safari 老版本上 keepalive 全部失败，全靠 IndexedDB 队列兜住——这正说明第三层不是「锦上添花」，是移动端的主路径。
五、结论与可复用清单
结论：sendBeacon 的静默语义决定了「上报链路」必须按「会丢」来设计；而丢包率的全量口径对账会把结构性丢包（集中在卸载窗口）稀释成噪音——先改对账口径，再修通道。
可复用清单（可直接抄）：
- 单包体积上限设为 48KB（64KB 规范上限的 75%），按事件大小分片，禁止按时间窗无脑攒包；
- 永远接收
sendBeacon的返回值，false 即降级fetch keepalive，再失败落 IndexedDB 队列（retry ≤5 次，溢出上报）； - 心跳事件 64 字节、30s 间隔、独立通道不攒包；服务端用「心跳断流 + 2s 时间窗口对齐」做对账，替代日全量口径；
- 三个自证指标进告警：
beacon_accept_rate ≥99.5%、keepalive_fallback_rate <1%、queue_overflow_count = 0； - 判定「送达」只看响应状态码，不看 API 返回值；
- 上线前后对照指标：卸载窗口丢包率 41% → 1.8%（残余为真·弱网超时，已被队列在下次会话补回，最终落库率 99.6%），服务端上报 QPS -70%。
适用边界：方案针对「浏览器端 → HTTPS 上报」场景；Native 容器内 H5 如果走桥接通道，第 2、3 层的降级对象换成桥接队列即可，对账口径不变。