避免 WebRTC getStats 的六个常见错误
内容提要
WebRTC getStats() API 监控易出错，常见六误区：计数器误当速率、对象切换未匹配、轮询频率不等于采样更新、jitter单位是秒非毫秒、packetsLost可为负值、bytesReceived含重传和FEC。需按ID匹配对象，用时间戳算差值，显式换算单位，区分累计与瞬时值，保留未知状态，避免错误解读。
延伸解读
监控面板的“合理错误”更危险
文章指出，WebRTC getStats() 的陷阱在于指标可能被正确采集却错误解读，导致面板显示的数字看似合理但实际有误。例如，将累计计数器直接当作速率，或忽略单位换算，都可能让错误值看起来正常。这种“合理错误”比明显的故障更难发现，因为它不会触发警报，却会误导对连接质量的判断。因此，在构建监控时，应仔细核对每个字段的语义，而非仅依赖字段名。
对象切换与时间戳：差值计算的关键
计算速率或差值时，必须确保两次观测针对同一统计对象，并使用对象自带的时间戳。ICE 重启等事件可能导致对象被替换，若将新对象误认为旧对象的延续，相减计数器会产生巨大负值。此外，getStats() 的调用频率不等于底层采样频率，两次报告的时间戳可能相同，导致除零错误。因此，应通过 id 匹配对象，并检查时间戳差值是否大于零。
单位与符号：容易被忽略的细节
jitter 和 currentRoundTripTime 的单位是秒，而非毫秒，直接展示会误导（如 0.024 秒被误读为 0.024 毫秒）。packetsLost 是有符号值，可能为负，负差值不一定代表错误，但面板可显式钳制到零。bytesReceived 包含重传和 FEC 流量，若需计算原始媒体码率，应减去 retransmittedBytesReceived 和 fecBytesReceived（若存在）。
缺失的远端统计：未知不等于零
remote-inbound-rtp 统计依赖 RTCP 报告，可能在连接初期不存在。将缺失值默认为零会扭曲会话开始阶段的指标，并使跨会话平均值显得过于健康。正确的做法是保留“未知”状态，直到数据真正可用。这提醒我们，在聚合或展示前，应明确区分“零”和“无数据”，避免误导性结论。
Q&A
WebRTC getStats() 中 bytesReceived 等值是什么类型？如何正确计算码率？
bytesReceived、packetsReceived、framesDecoded、nackCount 等是累计计数器，不是速率。要计算码率，需要两次观测的差值除以时间差，公式为：((curr.bytesReceived - prev.bytesReceived) * 8) / ((curr.timestamp - prev.timestamp) / 1000)。注意使用统计对象自带的时间戳，并确保两次观测针对同一对象。
为什么 WebRTC 统计对象可能变化？如何避免跨对象计算错误？
统计对象可能因 ICE 重启等原因被替换，新对象有独立的 ID 和计数器。如果监控代码将新对象当作旧对象的延续，相减计数器会产生巨大负差值。应使用统计对象的 id 进行匹配，若 prevReport.get(curr.id) 不存在，则视为对象切换，不进行跨对象计算。
频繁调用 getStats() 能获得更细粒度的测量吗？为什么？
不能。WebRTC Stats 规范允许实现使用缓存或节流，应用无法控制底层采样节奏。两次调用可能返回相同时间戳，导致时间差为零。因此，轮询频率不等于采样更新，应检查时间戳，若 deltaMs <= 0 则跳过计算，避免除零错误。
WebRTC 统计中 jitter 的单位是什么？如何转换为毫秒？
jitter 的单位是秒，不是毫秒。例如 jitter = 0.024 表示 24 毫秒。转换公式：jitterMs = stat.jitter * 1000。同样，currentRoundTripTime 等往返时间也是秒，需乘以 1000 转换为毫秒。
packetsLost 为什么可能为负？如何处理负的丢包差值？
packetsLost 是有符号值，遵循 RTP 累计丢包语义，定义为预期接收包数减去实际接收包数，实际接收可能包含重复包，因此可能为负。计算差值时，负值不代表错误。监控面板可显式将负值钳制到零，但应作为面板定义，而非默认底层统计出错。
bytesReceived 包含哪些流量？如何分离出原始媒体码率？
bytesReceived 包含重传和前向纠错（FEC）流量。如果实现暴露了 retransmittedBytesReceived 和 fecBytesReceived 字段，可用公式：originalBytes = bytesReceived - retransmittedBytesReceived - fecBytesReceived 分离。但字段可能缺失，需显式处理。根据指标目的决定是否包含恢复开销。
remote-inbound-rtp 统计为什么可能缺失？缺失时应该如何处理？
remote-inbound-rtp 统计由远端通过 RTCP 报告回传，可能不会在连接建立时立即存在。缺失时不应默认为零，因为零表示“无丢包”等健康状态，而实际是“未知”。应保留“未知”状态，避免扭曲聚合数据。
在将 WebRTC 统计量用于监控前，应该问哪些关键问题？
应问四个问题：1. 这个值是累计的、瞬时的还是推导的？2. 它的单位是什么？3. 它属于哪个对象？跨报告比较时是否同一对象？4. 它是否可能合法地不可用？这些问题比字段名更有助于正确解读。
