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、后台冻结、进程回收……这些机制在不同设备上组合出现，最终决定你看到的“可靠”，其实是分层兜底的结果。