如何设计前端监控 SDK？sendBeacon 能保证日志不丢吗？
先理解原理和示例，再练习完整口述与追问。
回答要点
分错误类型捕获；版本与上下文关联；采样、批量、去重、脱敏；生命周期触发上报；Beacon 入队不等于服务端确认。
原理拆解
监控先定义需要回答的问题，再采集数据。运行时异常用 error 事件，资源加载失败需要在合适的捕获阶段监听并识别事件目标；未处理 Promise 拒绝用 unhandledrejection，框架错误边界或全局错误处理补充组件信息。请求失败应区分网络失败、HTTP 状态与业务错误，不能把 fetch 只在网络失败时拒绝误认为所有非 2xx 都会抛错。
日志关联 release、页面、时间、请求 ID、必要的操作轨迹与 Source Map；对 token、手机号、表单和 URL 参数脱敏，限制单条大小、队列上限和频率，避免 SDK 自身异常递归上报。可以定时或批量发送，并在 visibilitychange 变为 hidden 等合适时机尝试提交，不能把所有逻辑都压在不稳定的 unload 上。
sendBeacon 返回 true 仅代表浏览器接受数据进入发送队列，不能证明服务器收到、持久化或处理成功。它通常发送 POST，不提供普通响应回调，自定义请求能力受限；队列和 keepalive 请求存在预算，跨域也仍受请求模式、内容类型与 CORS 等约束。失败可以保留有上限的本地队列在后续会话补传，使用事件 ID 服务端去重，并结合明确的响应确认统计送达率；离线、进程终止或存储清理仍可能丢失。关键交易结果必须由业务服务端记录，不能依赖前端埋点充当唯一凭证。
参考：MDN sendBeacon。
示例与推演
SDK 队列累计到阈值或页面变 hidden 时批量发送，Beacon 返回 false 则保留有上限队列；返回 true 仍不立即记为“服务器已保存”。若后续有确认机制，可按事件 ID 去重补传。资源 error 与脚本运行 error 的 target 信息不同，捕获与归类要分别实现。
易错点
日志去重、采样和脱敏同样重要。用用户访问的完整 URL、表单或 Cookie 作日志可能泄露敏感信息。
参考回答可直接练习口述
监控先定义需要回答的问题，再采集数据。运行时异常用 error 事件，资源加载失败需要在合适的捕获阶段监听并识别事件目标；未处理 Promise 拒绝用 unhandledrejection，框架错误边界或全局错误处理补充组件信息。请求失败应区分网络失败、HTTP 状态与业务错误，不能把 fetch 只在网络失败时拒绝误认为所有非 2xx 都会抛错。