能，sendBeacon可在页面卸载时可靠触发，但须满足POST方法、使用Blob等二进制载体、同源或CORS允许等条件；应监听pagehide事件并检查返回值，服务端需幂等处理。
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 请求，还原成可信的用户行为终点。这个环节一旦漏掉幂等或超时窗口，后续所有分析都会漂移。
