sendBeacon 在 unload 中易丢数据，因该事件在 Safari/iOS 和 bfcache 下常被跳过；应改用 pagehide 并校验 event.persisted === false；返回 true 仅表示入队成功，不保证送达；仅支持 ArrayBuffer、Blob、FormData 等特定类型，传错静默失败。
能，但必须用对时机、数据类型和事件源，否则大概率发不出去。
为什么 unload 事件里调 sendBeacon 还是会丢数据
unload 是最常被误用的入口点。它在某些浏览器（尤其是 Safari 和部分 iOS 版本）中已被严重限制：页面一旦开始卸载，事件处理函数可能被直接跳过或中断执行。更关键的是，如果用户快速关闭标签页或触发 bfcache（往返缓存），unload 根本不触发。
推荐改用 pagehide 事件，并检查 event.persisted：
- 若
event.persisted === true，说明页面进了 bfcache，没真正关闭，通常不该发信标 - 若
event.persisted === false，才是真实卸载，此时调用navigator.sendBeacon()最稳妥 - 别只监听
unload，也别同时监听两个事件试图“双保险”——它们执行时机冲突，反而增加失败概率
sendBeacon 返回 true 就代表服务器收到了吗
完全不是。navigator.sendBeacon() 只表示数据成功加入浏览器的后台发送队列，返回 true 仅说明入队成功；返回 false 才说明因跨域、URL 无效、data 类型不支持等原因被拒之门外。
它**不提供任何网络层反馈**，也不支持设置超时、重试或自定义 Headers。这意味着：
- 你无法知道请求是否真的发出去了（比如网络已断）
- 无法拿到 HTTP 状态码或响应体，所以不能做服务端校验或错误分类
- 如果后端接口偶发 502/503，前端完全无感知
实际做法是：前端只做轻量级保底上报（如停留时长、关闭原因），服务端需配合幂等设计 + 日志兜底，避免因重复或丢失导致统计偏差。
哪些 data 类型能用，哪些会静默失败
navigator.sendBeacon() 对 data 参数类型有硬性要求，传错类型不会报错，而是直接返回 false，且控制台无提示。
合法类型只有：ArrayBuffer、ArrayBufferView（如 Uint8Array）、Blob、DOMString（即字符串）、FormData、URLSearchParams。
常见踩坑点：
- 直接传普通对象（如
{ event: "close" }）→ 失败，必须先JSON.stringify() - 传
JSON.stringify()后的字符串 → 可行，但注意编码：中文需确保 UTF-8，否则服务端收到乱码 - 传
FormData→ 可行，但字段值不能是文件（File对象），否则部分浏览器拒绝入队 - 传
Blob→ 推荐用于大一点的结构化数据，例如new Blob([JSON.stringify(data)], { type: "application/json" })
移动端后台发送经常失效，怎么缓解
Android 和 iOS 浏览器在页面进入后台（比如切到其他 App 或锁屏）后，会主动暂停或延迟 Beacon 发送，尤其在低电量模式下。这不是 bug，而是系统级节电策略。
能做的有限但实用：
- 把关键指标尽量压缩：去掉冗余字段，用短 key（如
t代替time_spent），控制总大小在 8KB 内（iOS Safari 实测较稳的阈值） - 避免在
visibilitychange隐藏时才触发 —— 此时可能已晚，优先靠pagehide抓住最后窗口 - 不要依赖单次 Beacon：对高价值行为（如表单草稿、支付中断），应在页面内就做增量同步，关闭前只补最后状态
真正不可靠的从来不是 API，而是假设“一次调用就能覆盖所有终端状态”。bfcache、后台冻结、进程回收……这些机制在不同设备上组合出现，最终决定你看到的“可靠”，其实是分层兜底的结果。
