这类问题看似集中在一个 API 或参数上，真正决定可用性的却是状态归属、资源上限和失败后的恢复方式。 “发控制台截图”既费力又可能泄露连接码。结构化诊断由白名单构造，用户先预览，再选择复制短码或下载加密包。
产品闭环要覆盖开始、等待、取消、失败、恢复与再次进入，并保证自动化服从用户最后一次明确选择。指标应衡量任务结果，而不是按钮点击数量。
先把实现决策说清楚
这项能力横跨客户端、网络与服务端，局部最优很容易制造全局故障。工程决策需要同时约束两端行为、持久化事实和运维预算。
- 包包含 release、browser major、feature flags、candidate types、terminal errors 与最近有限状态；每次生成随机 supportId，默认不过网。
- 把协议事实、用户意图和自动恢复分层；自动化只能恢复事实，不能推翻用户明确选择。
- 重试必须带幂等键、退避和截止时间；超过截止时间后建立新任务，而不是继续复活旧回调。
“自助诊断包：让用户能报清问题，又不上传隐私内容”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
最容易漏掉的失败路径
最值得优先排查的是会静默留下错误事实的故障：界面看似恢复，底层队列、权限或计数却已分叉。这类问题通常在下一次动作才暴露。
- 自动收集所有 localStorage 和 WebRTC stats 会带身份、IP 与业务数据；永久 supportId 又变成跨工单跟踪标识。
- 刷新或网络切换同时触发两条恢复路径，重复副作用被误当成两次真实用户操作。
- 指标标签直接包含用户或任务标识，既制造高基数成本，也让诊断数据泄露不必要的身份信息。
上线前怎样验证
测试不能以“最后成功了”结束。还要测量经历了多少次副作用、等待多久、是否泄露内容，以及失败后再次执行能否从干净基线开始。
- 填入唯一敏感 canary 后运行每种错误并导出，安全测试扫描压缩包、剪贴板文本和上传请求，canary 必须为零。
- 用乱序、重复和延迟消息驱动状态机，确认旧版本被丢弃且显式停止不会被自动恢复覆盖。
- 分别覆盖直连、中转、弱网、后台标签页和移动端，报告不能只给平均值或一次成功截图。
可以上线的标准是：用户知道当前发生了什么，系统在异常后能停止或恢复，资源不会无界增长，运维也能从最小必要证据定位阶段。