一项能力能否长期维护，不取决于演示是否成功，而取决于团队能否解释每个状态、每次重试和每一份残留数据。 实时通信兼容性属于双方组合：Safari 发送到 Chrome 与反方向可能不同。版本名称只是代理，测试首先记录实际协商能力和 SDP 结果。
测试要把状态机、故障注入和真实浏览器组合起来。确定性用例守住已知契约，随机时序寻找竞态，失败 seed 和两端轨迹必须保存成永久回归。
设计时必须回答的问题
这项能力横跨客户端、网络与服务端，局部最优很容易制造全局故障。工程决策需要同时约束两端行为、持久化事实和运维预算。
- 每次提交跑核心同浏览器对，夜间覆盖跨浏览器与移动，发布前加入当前/上一大版本；历史故障组合永久进入最小回归集。
- 所有输入都设置大小、次数和时间预算，并在超限时返回可操作的稳定错误码。
- 重试必须带幂等键、退避和截止时间；超过截止时间后建立新任务，而不是继续复活旧回调。
“浏览器兼容矩阵：按能力和组合测试，不按“Chrome 能用”下结论”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
边界情况不是附加项
最值得优先排查的是会静默留下错误事实的故障：界面看似恢复，底层队列、权限或计数却已分叉。这类问题通常在下一次动作才暴露。
- 只测最新版桌面 Chrome 会漏掉 iOS WebKit 权限和后台策略；全笛卡尔积又昂贵到没人维护，最终全部跳过。
- 旧响应在新任务建立后迟到，如果没有版本隔离，会把健康状态覆盖成失败或再次启动已取消工作。
- 指标标签直接包含用户或任务标识，既制造高基数成本，也让诊断数据泄露不必要的身份信息。
用证据确认它真的可用
测试不能以“最后成功了”结束。还要测量经历了多少次副作用、等待多久、是否泄露内容，以及失败后再次执行能否从干净基线开始。
- 从生产能力分布生成加权矩阵，报告覆盖的用户占比、未覆盖风险和每组合的连接、文件、屏幕闭环结果。
- 用乱序、重复和延迟消息驱动状态机，确认旧版本被丢弃且显式停止不会被自动恢复覆盖。
- 分别覆盖直连、中转、弱网、后台标签页和移动端，报告不能只给平均值或一次成功截图。
最终交付标准应当是：正常路径足够快，异常路径能够收敛，用户意图不会被自动恢复覆盖，运维人员也能从有限而安全的证据定位问题。