单页应用关闭时如何可靠上报状态

单页应用在页面关闭时如何可靠上报用户状态？答案是使用 `sendBeacon`——它能在卸载前异步发出请求，不阻塞关闭流程，远比 `fetch` + `beforeunload` 可靠；但必须严格满足条件：仅支持 POST、请求体须为 Blob/FormData 等二进制类型、同源或正确配置 CORS，且务必在 `pagehide`（优先）和 `beforeunload` 中调用并检查返回值；前端需预构造轻量数据、避免字符串直传、合理生成去重 ID，后端则必须实现幂等接收与短时窗口去重，才能真正将零散、延迟、重复的 beacon 请求，还原为可信的用户行为终点——这不仅是技术细节的堆砌，更是前后端协同保障数据真实性的关键闭环。

sendBeacon 能否在页面卸载时可靠触发

能，但仅限于满足特定条件的请求：必须是 POST 方法、请求体为 ArrayBuffer、Blob、FormData 或 URLSearchParams 之一，且目标 URL 必须同源（或已通过 CORS 显式允许）。浏览器会在页面卸载前异步发出该请求，不等待响应，也不阻塞关闭流程——这是它比 fetch + beforeunload 更可靠的根本原因。

常见错误现象：sendBeacon 返回 false 却没检查；传入字符串（如 JSON.stringify(obj)）而非 Blob；跨域未配 Access-Control-Allow-Origin: * 导致静默失败；在 pagehide 之后才调用（此时可能已无上下文）。

• 务必在 beforeunload 或 pagehide 事件中调用，优先用 pagehide（兼容性更好，且能捕获安卓后台进程被杀场景）
• 调用后立即检查返回值：if (!navigator.sendBeacon(url, blob)) { /* fallback logic */ }
• 避免依赖 JSON.stringify 直接传参，应封装为 Blob：new Blob([JSON.stringify(data)], {type: 'application/json'})

如何构造符合 sendBeacon 要求的请求体

sendBeacon 不接受普通对象或字符串，只认二进制类载体。最稳妥的是 Blob，它天然支持任意序列化格式，且浏览器内部处理开销低。若后端要求 application/x-www-form-urlencoded，可用 URLSearchParams；若需上传文件字段或混合类型，FormData 是唯一选择（但注意：部分旧版 Safari 对 FormData 在 sendBeacon 中支持不稳定）。

性能影响很小——Blob 构造是同步且轻量的，不触发额外内存拷贝；但若数据量超过几 MB，可能因浏览器限制被截断（Chrome 限制约 64KB–128KB，Firefox 约 256KB），需提前截断或压缩。

• 推荐写法：const blob = new Blob([JSON.stringify({ts: Date.now(), route: location.pathname, ...state})], {type: 'application/json'})
• 避免写法：navigator.sendBeacon('/log', JSON.stringify(data)) → 静默失败
• 若需带 header（如认证 token），sendBeacon 不支持自定义 header，只能把 token 放 query 或 body 里

为什么不能只靠 beforeunload，而要监听 pagehide

beforeunload 在 Chrome/Firefox 中已被限制为仅允许同步操作，且在安卓 PWA 或 iOS Safari 中常被跳过（尤其用户从地址栏直接关闭标签页）；pagehide 则覆盖更广：包括用户切换标签、按 Home 键退到后台、系统回收内存等场景，且事件触发时机更早、更稳定。

容易踩的坑是监听了 beforeunload 却漏掉 pagehide，导致安卓端上报率骤降 40%+；另一个问题是未区分 persisted: true（页面被缓存，非真正关闭），此时不应上报“退出”状态。

• 必须同时绑定：window.addEventListener('beforeunload', handler) 和 window.addEventListener('pagehide', handler)
• 在 pagehide 回调中检查 event.persisted === false 再执行上报，否则会误报“后台存活”为“关闭”
• 不要在 handler 中执行耗时计算（如深克隆整个 store），应在页面生命周期早期预计算好待上报数据

服务端如何识别并容忍 sendBeacon 的“不可靠性”

浏览器不等待响应，所以服务端无法反馈成功/失败；且同一页面可能因快速刷新或异常关闭触发多次 sendBeacon，造成重复数据。后端不能假设“一次关闭=一次请求”，而应设计幂等接收逻辑。

关键点在于客户端必须提供可去重标识：比如用 performance.timeOrigin + 页面首次加载时间戳生成一个 session-level ID，或用 crypto.randomUUID()（注意兼容性）生成 page ID。服务端收到后，基于该 ID 做 5 分钟内去重（Redis SETEX），并记录原始时间戳用于对齐真实关闭时刻。

• 客户端示例字段：{page_id: 'a1b2c3d4', ts: 1717023456789, event: 'page_unload', state: {...}}
• 服务端必须忽略 HTTP 状态码，只确保 2xx 响应体为空（减少传输开销），且响应头含 Access-Control-Allow-Origin: *
• 别在日志里打印 “beacon received” 就算完事——要落地到可观测链路：记录 page_id、接收时间、解析是否成功、是否去重

真正的难点不在前端调用，而在服务端能否把零散、延迟、重复的 beacon 请求，还原成可信的用户行为终点。这个环节一旦漏掉幂等或超时窗口，后续所有分析都会漂移。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。