pagehide 事件才是 sendbeacon 的正确触发点，需判断 event.persisted === false 时调用；data 必须为指定类型，推荐 blob 或 urlsearchparams；严格遵守 64kb 限制并检查返回值；仅支持同源，服务端需幂等处理。
pagehide 事件才是 sendBeacon 的正确触发点
直接在 unload 或 beforeunload 里调用 navigator.sendBeacon()，大概率发不出去——尤其在 Safari、iOS Safari 和启用 bfcache 的 Chrome 中，unload 常被跳过或截断执行。
真正稳定可靠的入口是 pagehide，它在页面真正不可见时触发（包括关闭、跳转、刷新、进入后台），且所有现代浏览器都支持。但必须加一层判断：
- 检查
event.persisted === false：为true表示页面进了往返缓存（bfcache），并未真正卸载，此时通常不该发埋点 - 只在
event.persisted === false时调用sendBeacon，避免误报“离开”行为 - 别同时监听
pagehide和unload—— 它们执行时机冲突，反而增加失败概率
传错 data 类型会导致静默失败
navigator.sendBeacon() 对 data 参数类型极其严格：只接受 ArrayBuffer、ArrayBufferView、Blob、DOMString、FormData 或 URLSearchParams。传 JS 对象（如 { event: 'exit' }）或未序列化的数据，会直接失败，且不报错。
常见错误写法：navigator.sendBeacon('/log', { event: 'exit' }) → 返回 false，但开发者可能没检查返回值就以为发出去了。
推荐做法：
- 用
JSON.stringify()转成字符串，再包装成Blob（服务端按text/plain解析）：new Blob([JSON.stringify(data)], { type: 'application/json' }) - 或用
URLSearchParams（适合键值对）：new URLSearchParams({ event: 'exit', duration: '12345' }) - 避免直接传
JSON.stringify(data)字符串——虽能成功入队，但服务端若按application/json解析会出错
64KB 硬限制和返回值必须检查
navigator.sendBeacon() 单次请求有明确的 64KB（65536 字节）硬限制，且整个 Beacon 队列共享该预算。超限会直接返回 false，不抛异常、不警告。
返回 true 仅表示数据成功入队，不代表服务器收到；返回 false 才说明被拒（原因可能是跨域、URL 无效、类型不支持、或超限）。
务必检查返回值并做轻量兜底：
- 若
navigator.sendBeacon(url, data) === false，可降级用fetch()（需接受弱网下可能丢数据） - 或拆分数据：比如把大日志切片，只上报关键字段（停留时长、退出原因、最后操作）
- 别依赖
sendBeacon传大体积数据（如截图 base64、完整 DOM 快照）——它不是为此设计的
同源限制和服务端配合不可少
navigator.sendBeacon() 遵守同源策略，目标 url 必须与当前页面同源。跨域请求会直接失败（返回 false），且无法携带自定义 headers（如 Authorization）。
这意味着：
- 埋点接口必须部署在同域下，或配置 CORS（但注意：CORS 不适用于
sendBeacon，它不发预检请求，也不读响应） - 服务端不能依赖 header 鉴权，得靠 token 放 query 或 body 里
- 服务端需做好幂等处理——因为浏览器可能重试（尤其在弱网下），也可能因进程终止导致“已入队但未发出”，造成重复或丢失
最易被忽略的一点：sendBeacon 不提供任何网络层反馈。你永远不知道请求是否真的发了出去，也不知道 HTTP 状态码。前端能做的只是保底入队，其余全靠服务端日志 + 幂等 + 客户端采样补漏。
