需求背景：上报模块要解决的两个矛盾
监控 SDK 有一个特殊约束：它本身不能影响业务，同时又必须尽可能把监控数据送到服务端。如果每一次点击、性能事件、错误都立即发一个请求，会产生大量额外请求；但如果一直缓存在内存里，用户关闭页面或者网络异常时又容易丢数据。所以上报层主要解决两个问题：降低上报成本，以及在异常网络和页面卸载场景下尽可能保证数据送达。
普通监控数据（错误、性能、行为）的特点是事件数量多、单条数据比较小、不需要每条立即发送、可以接受少量延迟，因此适合用“队列 + 批量 + 定时 Flush”的模式。而录屏数据完全不同：事件量大、单次 Payload 大、对网络和页面生命周期更敏感，而且只在发生异常后才真正有价值，所以更适合“持续录制 + 环形缓冲 + 错误触发截取 + 独立上报”。理解了这个差异，后续的设计就顺理成章了。
普通数据上报：队列、批量与双阈值触发
DataReporter 初始化时维护一个队列（this.queue）和定时器（this.timer），所有错误、性能、行为数据最终都会进入 addToQueue(data)，而不是立即发送。连续产生多个事件时不会产生多 ...
