sendBeacon仅保证数据入队而非送达，真正提升成功率需选对事件（如pagehide且event.persisted为false）、构造合规数据（URLSearchParams/Blob/字符串）、避开浏览器限制（禁用耗时操作、控制64KB内、前置序列化）。
不能靠 navigator.sendBeacon 本身“确保可靠上报”，它只保证数据入队，不保证送达；真正能提升成功率的，是选对事件、构造合规数据、避开浏览器执行限制。
为什么在 unload 里调用 sendBeacon 还是发不出去
因为 unload 在 Safari、iOS 和 bfcache 场景下常被跳过或中断执行，浏览器根本不给 JS 执行机会。Chrome 80+ 之后更会直接冻结上下文，同步阻塞或长任务（比如 JSON.stringify 大对象）会导致调用直接失效。
- 优先监听
pagehide，并检查event.persisted === false：为true表示进了往返缓存（bfcache），页面没真关，通常不该发 - 避免同时监听
beforeunload和pagehide：两者时机冲突，反而增加竞态失败概率 - 不要在事件回调里做耗时操作：如
alert()、while循环、awaitPromise，浏览器只给 ≤100ms 的异步窗口
哪些 data 类型能用，哪些会静默失败
navigator.sendBeacon 对参数类型有硬性要求，传错类型不报错，只返回 false，且控制台无提示。
- ✅ 安全可用：
URLSearchParams（推荐）、Blob（显式指定type）、DOMString（即字符串） - ⚠️ 慎用：
FormData—— 旧版 Safari 中失败率高，且服务端需解析 multipart boundary - ❌ 不支持：
Object、Array、undefined、含循环引用的对象 —— 直接传会静默失败 - 若用 JSON 字符串，建议包装成
Blob：new Blob([jsonStr], { type: 'application/json' })，否则后端收到的是text/plain类型
如何让后端正确接收并避免解析失败
sendBeacon 不发送自定义请求头，Content-Type 完全由浏览器根据数据类型自动设置，后端必须按对应方式解析。
- 用
URLSearchParams→ 浏览器设为application/x-www-form-urlencoded→ 后端按表单解析（req.body或req.form） - 用
Blob且type: 'application/json'→ 后端需读取原始 body 并 JSON.parse - 用纯字符串 → 默认
text/plain→ 后端不能按 JSON 自动解析，否则报错 - 跨域目标 URL 必须同源，或后端配置
Access-Control-Allow-Origin: *且仅允许简单请求（无预检）
64KB 限制和兜底兼容怎么处理
Chrome 实测上限约 256KB，但 Safari 和旧 Android 更严，建议单次控制在 64KB 内；超出则静默丢弃。
- 字段精简：用短 key（
pg代替page）、时间戳用毫秒整数、去掉空值和冗余字段 - 提前序列化：在页面活跃期就完成聚合与
JSON.stringify，卸载时只调sendBeacon - 降级方案：检测
!navigator.sendBeacon时，改用new Image().src = url + '?' + params（仅 GET，适合极简日志） - 别依赖返回值做重试：返回
true只代表入队成功，网络断开、服务端 502 等完全无感知
最易被忽略的一点：你认为“数据大所以发不出”，其实问题往往出在“数据还没准备好就到了卸载时刻”——采集、压缩、序列化必须前置，sendBeacon 只负责最后一公里的轻量交付。
