如何设计一套基于 Beacon API 的极端情况下前端日志“最后一眼”收集方案

navigator.sendBeacon是“最后一眼”日志唯一可靠选择，因其被规范明确保证页面卸载后仍尽力发送，不阻塞流程、不依赖事件循环，且兼容主流现代浏览器；但仅支持POST，payload须为Blob/FormData等合法类型，不可直接传字符串或JSON对象。

为什么 navigator.sendBeacon 是“最后一眼”日志的唯一可靠选择

页面即将卸载（如用户关闭标签页、刷新、跳转）时，常规 fetch 或 XMLHttpRequest 极大概率被浏览器中止，日志直接丢失。而 navigator.sendBeacon 是唯一被规范明确保证「即使页面已不可见，仍会尽力发送」的机制——它不依赖事件循环，不阻塞卸载流程，且在大多数现代浏览器中（Chrome 39+、Firefox 31+、Safari 11.1+、Edge 79+）稳定可用。

注意：它只支持 POST 方法，且 payload 必须是 ArrayBuffer、Blob、FormData 或 URLSearchParams 类型；不能是普通字符串或 JSON 对象，否则会静默失败。

如何构造合法且兼容的 Beacon 日志 payload

直接传 JSON.stringify(logData) 会触发类型错误，因为字符串不是允许类型。必须显式转换为 Blob 或 URLSearchParams：

• 推荐用 new Blob([JSON.stringify(logData)], { type: 'application/json' }) —— 兼容性好，服务端接收时 Content-Type 明确，解析无歧义
• 若后端只认 application/x-www-form-urlencoded，可用 new URLSearchParams({ data: JSON.stringify(logData) })，但需注意 URL 编码长度限制（一般 ≤2048 字符）
• 避免用 FormData：它在卸载阶段某些 Safari 版本中可能失效，且服务端需额外处理 multipart 解析
• payload 体积建议控制在 64KB 内：过大会被部分浏览器截断，且增加发送失败概率

Beacon 上报前必须做的三件事

Beacon 不是“扔出去就完事”的黑盒，漏掉任一环节都可能导致日志发不出或内容残缺：

立即学习“前端免费学习笔记（深入）”；

• 必须在 beforeunload 或 pagehide 事件中调用，且不能是异步回调（比如 setTimeout(() => sendBeacon(...), 0)）——事件上下文一旦退出，Beacon 就失效
• 必须检查 navigator.sendBeacon 是否存在，旧版 IE 和部分 WebView 不支持，需 fallback 到 image 方案（new Image().src = '/log?data=...'），但注意 URL 长度和编码安全
• 日志数据必须在事件触发前就准备好：不要在 beforeunload 里临时计算 getPerformanceMetrics() 或读取 localStorage，这些 I/O 可能来不及完成

容易被忽略的边界问题：页面快速跳转与多 Beacon 竞争

用户连续点击两个链接（A → B → C），beforeunload 在 A 触发，pagehide 在 B 触发，但浏览器对同一页面只允许一次 Beacon 发送。如果 A 页面未发完就跳到 B，B 的 Beacon 会覆盖 A 的请求，导致 A 的“最后一眼”丢失。

解决思路不是加锁，而是收敛行为：

• 只在 pagehide 中发 Beacon（比 beforeunload 更可靠，且能捕获缓存导航）
• 用 document.hidden + visibilitychange 配合判断是否真要离开当前域（排除标签页切换等伪卸载）
• 关键日志（如 JS 错误、支付失败）应在发生时立即尝试 Beacon，不等到卸载——卸载只是兜底，不是主通道

真正难处理的是单页应用中路由跳转不触发卸载的情况，此时“最后一眼”根本不存在；这种场景必须靠主动打点 + 定期 flush，Beacon 只负责收真正的终局。