这类问题看似集中在一个 API 或参数上，真正决定可用性的却是状态归属、资源上限和失败后的恢复方式。 浏览器授权捕获不等于用户同意给某个远端观看。应用还要在捕获后显示观看者、共享对象与醒目标识，并让任何一端的停止立即传播。
风控既要限制滥用，也要限制自己收集的数据。优先使用短期、粗粒度、可解释信号，并为共享网络、弱网和辅助技术保留恢复与申诉路径。
先把实现决策说清楚
先从数据和协议能保证的事实出发，再决定界面承诺。下面的规则都应有明确所有者、边界值和兼容策略，不能只存在于某次代码评审的口头共识里。
- 共享前重新核验对端能力，优先当前标签页并提示系统音频；共享中常驻红色状态与观看人数，track ended 后原子结束会话和清理 sender。
- 为状态写出唯一所有者、版本号和终态；任何回调只能修改自己创建的版本。
- 兼容性通过显式能力协商决定，旧客户端得到可解释的降级路径，而不是进入半可用状态。
“屏幕共享威胁模型：捕获前、传输中和停止后分别保护什么”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
最容易漏掉的失败路径
最值得优先排查的是会静默留下错误事实的故障：界面看似恢复，底层队列、权限或计数却已分叉。这类问题通常在下一次动作才暴露。
- B 刷新后 A 仍显示正在共享会让用户误判隐私状态；隐藏标签页继续编码又可能在无人观看时暴露屏幕和耗电。
- 旧响应在新任务建立后迟到，如果没有版本隔离，会把健康状态覆盖成失败或再次启动已取消工作。
- 降级路径从未压测，主路径故障时所有流量同时进入更慢、更昂贵的后备方案。
上线前怎样验证
验证时同时观察两端状态、持久化记录和可观测指标。单看某个按钮或一次接口响应，无法证明整个闭环成立。
- 覆盖观看方刷新、关闭、网络断开、撤销信任、系统停止和共享者崩溃，测量双方 UI 与轨道在明确时限内收敛。
- 在操作中途断网、切换网络并恢复，核对两端状态、持久化记录和资源计数最终一致。
- 用故障注入验证告警先于用户投诉触发，并确认值班人员能从有限证据定位到具体阶段。
最终结果应同时满足正确性、可恢复性和可解释性。任何一项只能依赖刷新页面或工程师猜测，都说明协议闭环仍不完整。