sendBeacon用法及优化技巧

navigator.sendBeacon 虽被广泛视为页面关闭前发送埋点数据的“可靠方案”，实则仅承诺“尽力尝试”而非“确保送达”——受主线程终止、浏览器后台时限（≤500ms）、跨域预检失败、请求体格式限制（必须用 Blob/FormData 而非裸字符串）及用户强关行为等多重因素影响，常出现 sendBeacon 返回 true 却服务端零接收的尴尬局面；真正落地需组合 visibilitychange 与 beforeunload 双事件捕获、sessionStorage 标记防重漏、Blob 封装避预检、同源或合规跨域配置，并配合服务端幂等设计、trace_id 关联与本地缓存回传机制，才能将“最后一搏”转化为可信赖的终态数据保障。

sendBeacon 为什么在页面卸载时「看似可靠」但实际常失败

因为 navigator.sendBeacon 并不保证送达——它只保证「尝试发送」，且浏览器会在页面卸载过程中异步发起请求，但一旦主线程被终止（如强制关闭、进程杀掉、系统休眠），底层 HTTP 请求可能根本没发出，或发出去但没收到响应就中断了。Chrome 和 Firefox 对未完成的 beacon 有极短的后台运行窗口（通常 ≤ 500ms），超出即丢弃。

常见错误现象：sendBeacon 返回 true，但服务端完全收不到日志；或只收到部分埋点（比如只收到「进入页」，没收到「离开页」）。

• 不是所有浏览器都完整支持：Safari 在 iOS 14.5+ 才修复了卸载前 beacon 被静默丢弃的问题
• 请求体必须是 ArrayBuffer、Blob 或 FormData，不能直接传 JSON.stringify(obj) 字符串（会触发 CORS 预检，而卸载时预检必然失败）
• 目标 URL 必须同源，或服务端明确允许跨域（Access-Control-Allow-Origin: *），否则请求根本不会发出

如何构造一个真正能落地的 sendBeacon 调用

关键不是“调用”，而是让数据可序列化、请求可抵达、服务端可识别为「终态埋点」。必须绕过 JSON 字符串直传、避免预检、压缩体积、并预留 fallback 信号。

实操建议：

• 用 new Blob([JSON.stringify(data)], {type: 'application/json'}) 包装数据，而非字符串字面量
• URL 必须同源；若需跨域，服务端需返回 Access-Control-Allow-Origin: * 且 Access-Control-Allow-Methods: POST
• 禁用 Content-Type 头（sendBeacon 不允许设置请求头），所以不要试图加 headers 参数
• 数据尽量精简：去掉冗余字段，控制在 64KB 以内（部分旧版 Edge 对 blob size 有限制）

示例：

const data = { event: 'page_exit', time: Date.now(), url: window.location.href };
const blob = new Blob([JSON.stringify(data)], { type: 'application/json' });
navigator.sendBeacon('/api/log', blob); // ✅ 正确
// navigator.sendBeacon('/api/log', JSON.stringify(data)); ❌ 错误：触发预检，卸载时失败

页面卸载时机太短？加一层 visibilitychange + beforeunload 双保险

beforeunload 本身不能发网络请求（现代浏览器已禁止），但它可以触发同步逻辑；visibilitychange 则能在标签页失焦/最小化时提前捕获「可能即将关闭」的信号。两者结合，能显著提升终态数据捕获率。

实操建议：

• 监听 visibilitychange，当 document.visibilityState === 'hidden' 且 performance.navigation?.type === 1（即刷新）时，暂不发 beacon；但如果是首次隐藏且无后续交互，3s 后主动触发一次 sendBeacon
• 在 beforeunload 中仅做最后兜底：检查是否已发过 beacon，若未发，立即调用 sendBeacon（注意：这里调用仍可能被截断，但比纯靠 unload 更早）
• 用 sessionStorage 标记是否已发送，避免重复或遗漏：比如设置 sessionStorage.setItem('beacon_sent', '1')，并在每次发送前校验

后端如何识别和容忍 sendBeacon 的不确定性

服务端不能假设每个 sendBeacon 请求都一定到达，也不能依赖响应结果做状态判断——因为前端根本收不到响应。必须把「终态埋点」设计成幂等、可补、带上下文的事件。

实操建议：

• 每个 beacon 请求带唯一 trace_id 和 page_id（由前端生成并持久化在 sessionStorage 中），便于服务端去重或关联会话
• 接收端对 /api/log 做无响应体快速返回（HTTP 204），避免因响应延迟拖慢卸载流程
• 对「页面退出」类事件，服务端可结合客户端上报的 visibilityState、wasDiscarded（来自 pagehide 事件）、以及前后端时间戳差值，判断是否可信
• 保留客户端本地日志缓存机制：若 sendBeacon 连续失败（可通过 performance.getEntriesByType('navigation') 检测异常跳转），下次打开页面时尝试回传（需用户授权且非敏感数据）

最易被忽略的一点：sendBeacon 的可靠性高度依赖用户行为模式——频繁手动关闭标签页的用户，其终态数据丢失率远高于自然浏览至超时离开的用户。别把它当成实时上报通道，它只是「尽力而为的最后一搏」。

今天关于《sendBeacon用法及优化技巧》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！