WebSocket埋点失灵主因是主线程阻塞、内存泄漏、未采样、错误静默等；需用Web Worker解析、流式解码、分片上报、心跳兜底、动态采样。
WebSocket 实时上报埋点数据不是“开了连接就能发”，主线程卡顿、内存泄漏、未采样打点、错误静默丢失——这些才是线上监控失灵的真正原因。
onmessage 中直接 JSON.parse() 会阻塞渲染
高频埋点消息（如每秒数条用户行为）若在 onmessage 回调里同步 JSON.parse() + 校验 + 上报，会显著拖慢主线程，尤其在低端 Android 设备上可能引发页面掉帧甚至卡死。
- 用
Web Worker解析：将原始event.data（字符串或ArrayBuffer）传入 Worker，解析后只返回精简对象（如{type, ts, uid}） - 对二进制帧优先使用
TextDecoder流式解码，避免整包转字符串再JSON.parse() - 若必须在主线程处理，加
if (performance.now() - lastRenderTime > 16) requestIdleCallback(handleMsg)控制调度
send() 前不校验 payload 大小会导致连接被服务端强制关闭
多数 WebSocket 服务端（如 ws 库、Spring WebSocket）默认单帧上限为 1MB。前端若未经压缩就上报完整用户操作快照（含 DOM 路径、截图 base64），极易触发 close code 1009 (message too big)。
- 发送前检查：
const len = typeof data === 'string' ? new TextEncoder().encode(data).length : data.byteLength - 超 64KB 自动分片：拆成多个
{type: "log_chunk", seq: 1, total: 3, payload: "..."}帧 - 关键字段白名单过滤：上报前删掉
document.body.innerHTML、localStorage全量 dump 等高危字段
未实现连接状态兜底，错误日志永远收不到
onerror 事件不保证触发（Chrome 中部分网络中断场景下静默失败），且 onclose 的 event.code 无法区分是主动关闭还是异常断连。
将一个或多个 UI 原型图、线框图、产品截图或设计稿转换为标准化、可直接交付的 PRD 风格文档，供产品、设计、前端和测试共同使用。适用于 Codex 需要分析 PC 网页、桌面端、移动端、响应式页面、独立弹窗、表单、表格、看板、数据大屏或多页面流程截图，还原页面结构与交互，强制套用固定文档模板，抽取跨页面共享规则，或把一组原型沉淀为单页规范文档加整体业务流程文档的场景。不适用于纯视觉审美点评、代码实现、接口设计、埋点方案、竞品分析或无 UI 输入的业务需求创作。
立即学习“前端免费学习笔记（深入）”；
- 启动心跳检测：
setInterval(() => ws.send(JSON.stringify({ping: Date.now()})), 30000)，超时未收到pong视为连接异常 - 监听
beforeunload和visibilitychange，在页面卸载/切后台前强制 flush 缓存中的埋点队列 - 所有上报逻辑包裹
try/catch，并在catch中 fallback 到navigator.sendBeacon()或 localStorage 持久化
采样率硬编码为 100% 会让监控系统自己成为性能瓶颈
全量上报不仅压垮前端内存（尤其长连接维持数分钟以上），更会导致服务端 Kafka 消费延迟飙升，最终埋点数据大面积丢失。
- 动态采样：按设备类型分级，
if (/(iPhone|Android)/.test(navigator.userAgent)) Math.random() - 关键事件不过滤：如
error、unhandledrejection、network_online等必须 100% 上报 - 采样开关支持远程配置：从
/api/config拉取{sampling: {click: 0.05, pageview: 0.1, error: 1}}，避免发版更新
真正难的不是连上 WebSocket，而是让每一次 send() 都可控、可溯、不拖慢用户。连接建立只是开始，后续的帧大小控制、错误兜底、采样策略和解析调度，任何一个环节松动，整套实时监控就形同虚设。
