页面关闭时,如何确保使用navigator.sendBeacon准确上报埋点数据?
- 内容介绍
- 相关推荐
本文共计956个文字,预计阅读时间需要4分钟。
无法依赖` 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 只负责最后一公里的轻量交付。
本文共计956个文字,预计阅读时间需要4分钟。
无法依赖` 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 只负责最后一公里的轻量交付。

