根本原因是埋点逻辑与主流程耦合且无容错设计；应改用同源sendBeacon+localStorage补漏+trace_id全链路追踪，禁用fetch await和自定义header，丢包率须按trace_id原子链路统计。
表单提交日志的丢包率高，根本原因不是网络差，而是埋点逻辑与主提交流程耦合且缺乏容错设计——弱网、跳转、关页时 fetch 未响应、sendBeacon 参数超长或跨域失败、GIF URL 拼接错误、target="_blank" 提前释放线程，都会导致关键事件漏报。
为什么 fetch 在 submit 里发出去却没上报成功
浏览器在表单提交后若发生页面跳转或卸载，正在执行的 fetch 请求会被强制终止，哪怕加了 keepalive: true，只要带自定义 header（比如 Authorization 或 X-Trace-ID），跨域时就会触发预检（OPTIONS），而预检失败会导致整个请求根本发不出。
- 必须移除所有自定义 header，只保留
Content-Type（且仅限text/plain、application/json等简单类型） -
keepalive: true仅对同源有效；跨域时需服务端明确返回Access-Control-Allow-Origin: *和Access-Control-Allow-Headers - 不要
await fetch(...)，submit 事件里只能同步调用，否则主线程一走就中断 - 更稳妥的做法是：立刻调用
sendBeacon，fetch仅作补漏（onload 后重试）
sendBeacon 的 payload 格式和同源限制
sendBeacon 是目前唯一能在卸载前大概率发出的机制，但它对数据格式极其敏感：只支持 ArrayBuffer、Blob、FormData 或 URLSearchParams，传字符串会静默失败（控制台无报错）；目标 URL 必须同源，或服务端明确返回 Access-Control-Allow-Origin，否则请求直接丢弃。
- 构造 payload 推荐用
new URLSearchParams({ event: 'form_submit', form_id: 'login', ts: Date.now() })，避免手拼 query string 出错 - 不要把整个表单 JSON 塞进去——实际限制约 64KB，但旧安卓 WebView 可能只支持 16KB，建议压缩后控制在 32KB 内
- 服务端接收时，需按
text/plain或application/x-www-form-urlencoded解析，不能默认当成 JSON - Chrome 80+ 已禁用
beforeunload中的异步操作，别在那里塞fetch或setTimeout
如何用 localStorage 补漏 + onload 重试
即使用了 sendBeacon，仍可能因网络瞬断、服务端不可达或 payload 被截断而失败。真正的容错靠的是持久化 + 延迟重试：把未确认上报的事件存进 localStorage，等页面重新加载（load 事件）后再尝试发送，并加 TTL 防止堆积。
立即学习“前端免费学习笔记（深入）”；
- 每次上报前生成唯一
trace_id，写入localStorage时带上时间戳和序列号（如pending_log_abc123_0） window.addEventListener('load', () => { /* 扫描 localStorage 中未上报项，逐条 sendBeacon */ })- 重试超过 3 次或距生成时间 > 24h 的条目自动清理，避免无限堆积
- 注意：
localStorage是同步 API，大量写入会卡主线程，建议批量合并再存
丢包率该怎么算才真实
丢包率不能按 PV 或 UV 算，那只是“页面被访问了多少次”，和“日志是否发出”无关。必须基于原子事件链路聚合，例如从 click → form_validate → form_submit → backend_success，每一步都打上同一个 trace_id，再在服务端按 trace_id 统计各环节到达率。
- 前端每个关键节点（按钮点击、校验通过、submit 触发、fetch/sendBeacon 调用）都要打点并带上同一
trace_id - 服务端收到后，用
trace_id关联所有事件，缺失任意一环即记为该链路丢包 - 避免用客户端时间戳做排序——不同设备时钟偏差大，优先依赖服务端打点顺序
- 真实丢包率 = （缺失最终 success 事件的 trace_id 数） / （发出 click 事件的 trace_id 总数）
最容易被忽略的是：你看到控制台没报错，不代表 sendBeacon 成功了；你看到服务端收到了日志，也不代表用户真的完成了提交——中间任何一个环节断掉，整条链路就失效。得靠 trace_id 把前端行为和服务端响应串成一条可验证的线，别的都只是幻觉。
