sendbeacon 不适合直接用于编辑器实时埋点，因为它仅在页面卸载时可靠触发，而编辑行为持续发生；频繁调用会被浏览器静默丢弃，且不支持自定义请求头、无响应反馈、payload 限制严格。
为什么 sendBeacon 不适合直接用于编辑器实时埋点
因为 navigator.sendBeacon 只在页面卸载（beforeunload、pagehide、unload）时才可靠发送，而编辑行为是持续发生的——用户敲字、删改、选中、粘贴，这些动作根本等不到页面关闭才上报。强行在每次 input 或 keydown 中调用 sendBeacon，浏览器会静默丢弃绝大多数请求（规范明确要求：仅允许在卸载阶段调用）。
常见错误现象：Failed to execute 'sendBeacon' on 'Navigator': sendBeacon() with non-GET requests is only supported in unload handlers，或更隐蔽的——没报错但数据完全收不到。
- 它不是“离线可用”的万能方案，而是“卸载时强制发出”的保底机制
- 它不支持自定义请求头（如
Authorization）、不返回 Promise、无法监听响应 - 它的 payload 限制在 64KB 左右，且必须是
ArrayBuffer、Blob或FormData，不能直接传 JSON 字符串
真正可行的离线编辑埋点架构：三段式协同
编辑器埋点要兼顾实时性、可靠性、离线容灾，必须分层设计：
-
在线时：用
fetch（带重试 + 节流）主动上报编辑片段（如每 3 秒聚合一次变更） -
网络中断时：将未发送的事件写入
localStorage或IndexedDB（推荐后者，容量大、支持事务） -
页面卸载前：用
navigator.sendBeacon尽力发送最后一批缓存数据（作为兜底）
关键点在于：把 sendBeacon 当作「最后一搏」，而不是主力通道。它只负责把本地缓存里尚未发出的数据，在用户关页/跳转前，尽力推一次。
如何用 sendBeacon 发送离线缓存的编辑数据
假设你已将编辑事件序列存为 localStorage.getItem('edit_events')（JSON 字符串），卸载前需转换格式再发送：
function flushOfflineEvents() {
const events = localStorage.getItem('edit_events');
if (!events) return;
try {
const blob = new Blob([events], { type: 'application/json' });
// 注意：URL 必须是同源 endpoint，且服务端需支持接收 raw body
const success = navigator.sendBeacon('/api/v1/beacon', blob);
if (success) {
localStorage.removeItem('edit_events');
}
} catch (e) {
// sendBeacon 失败不可重试，只能放弃
}
}
window.addEventListener('beforeunload', flushOfflineEvents);
容易踩的坑：
- 服务端必须能解析 raw
application/json请求体（Node.js Express 需配app.use(express.raw({ type: 'application/json' }))） - 不要用
JSON.stringify后直接传字符串——sendBeacon会把它当文本发送，MIME 类型不对，后端可能解析失败 - 避免在
pagehide中做复杂逻辑，部分浏览器（尤其 iOS Safari）会限制执行时间
编辑器场景下必须额外处理的细节
富文本编辑器（如 Slate、ProseMirror、Quill）的变更粒度远比 input 元素复杂，直接监听 input 事件会漏掉剪贴板、拖拽、菜单操作等行为：
- 优先监听编辑器自身的变更钩子（如 ProseMirror 的
dispatchTransaction、Slate 的onOperation） - 记录操作类型（
insert、delete、format）、光标位置、选区范围、时间戳，而非原始 HTML 或 Markdown（体积大、难比对） - 本地缓存前做轻量压缩：例如将连续的
insert合并为一个批次，用JSON.stringify前先JSON.stringify(events, null, 0)去空格 - IndexedDB 缓存需加版本控制和清理策略，否则长期使用后会撑爆存储配额
最常被忽略的是：卸载时的 sendBeacon 并不保证送达，它只是“发出去了”。真正的可靠性来自前端缓存 + 后端幂等写入 + 定期同步校验。别让它背本不属于它的责任。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
