Beacon API 适合「尽力而为」型前端统计上报，如页面停留时长、跳出率、异常前最后行为，但不保证必达；因底层异步卸载发送、无响应反馈、不支持重试、受限于浏览器策略与设备环境。
Beacon API 适合做前端统计上报吗
适合，但仅限于「尽力而为」型统计场景——比如页面停留时长、跳出率、异常发生前的最后行为。它不是为强一致性上报设计的，别指望它保证每条数据必达。
关键原因在于 navigator.sendBeacon() 的底层机制：它把请求交给浏览器在页面卸载（unload / beforeunload）或标签页关闭时异步发出，且不等待响应。这意味着：
- 请求可能被浏览器直接丢弃（如用户强制 kill 进程、系统断电、Chrome 在后台限制 Beacon）
- 无法拿到 HTTP 状态码或响应体，没法重试或 fallback
- 不触发 fetch 的
AbortSignal，也不走 Service Worker 的 fetch 事件（Chrome 从 94+ 开始部分支持，但 Safari 仍不支持）
为什么 HTML 页面统计上报容易丢失
不是 Beacon 特有，而是所有「卸载阶段上报」都面临相同风险。根本矛盾在于：用户行为（关页、跳转、刷新）和上报动作存在天然竞争关系。
常见丢失链路：
立即学习“前端免费学习笔记（深入）”；
-
beforeunload里调用fetch()→ 浏览器会中断请求（fetch 不支持卸载阶段） - 用
XMLHttpRequest+open(..., false)同步请求 → 已被现代浏览器禁用，抛InvalidAccessError - 依赖
visibilitychange+hidden状态发普通请求 → 若页面已进入 pagehide 或被冻结（如 iOS Safari 后台 tab），请求大概率失败 - Beacon 发送后立即触发
pagehide→ 部分安卓 WebView 或低内存设备会直接终止 Beacon 传输
Beacon 的实际使用要点与坑
想让 Beacon 尽量“多活几条”，得绕开默认直觉写法：
- 必须用
POST方法，且Content-Type只能是text/plain、application/x-www-form-urlencoded或multipart/form-data；application/json会静默失败（浏览器不支持序列化 JSON 到 Beacon body） - 不要等
visibilitychange到hidden才发 Beacon —— 应在pagehide事件中立即调用navigator.sendBeacon(url, data)，因为pagehide是最后一个可靠可监听的生命周期钩子 - data 推荐用
URLSearchParams构造，避免手动拼字符串出错：const params = new URLSearchParams(); params.append('event', 'leave'); params.append('duration', String(performance.now() - startTime)); navigator.sendBeacon('/log', params); - 服务端要容忍重复请求（Beacon 可能因网络重传机制被发多次），也别校验
Origin或Referer头——这些头在 Beacon 中可能为空或被浏览器剥离
什么情况下不该用 Beacon 做统计
当你的统计字段涉及用户身份、付费行为、转化归因等强业务语义时，Beacon 就不该是主力通道。
- 登录态上报：Beacon 请求不会携带第三方 Cookie（尤其 Safari ITP、Chrome 125+ 的 Partitioned Cookies），
Set-Cookie响应头也无效 - 需要实时反馈的埋点：比如“按钮点击后立刻展示成功 toast”，不能等 Beacon 返回（它根本不返回）
- 上报体积 > 64KB：Chrome 对 Beacon payload 有隐式限制，超大会静默截断（实测约 64–128KB 不等，无标准）
- 需兼容 IE 或旧版 Android Webview：Beacon 在 IE 全系不支持，Android 4.4 WebView 也不支持
真正稳定的统计链路，得靠「主动上报 + 卸载兜底」双模式：核心行为走带重试的 fetch，页面离开前用 Beacon 补漏。漏掉的那 5%～15%，往往就是最难复现的用户路径断点——这点得提前和产品、数据同学对齐预期。
