好的实现不会依赖用户反复刷新碰运气，而会让每个阶段有明确输入、输出、超时和终态。 用户可从系统共享条、浏览器工具栏或关闭源窗口终止捕获，应用按钮只是其中一条路径。轨道 ended 是最终事实，处理器必须幂等完成通知、解绑和资源释放。
浏览器能力由版本、权限、页面可见性和设备策略共同决定。实现需要能力探测与可解释降级，不能把某一台开发机上的 API 存在当成产品契约。
先定义系统契约
这项能力横跨客户端、网络与服务端，局部最优很容易制造全局故障。工程决策需要同时约束两端行为、持久化事实和运维预算。
- 为每次捕获分配 share session ID，ended 回调只结束所属会话。
- 停止时先更新终态，再 replaceTrack(null)、停止所有轨道并通知观看方。
- 重新选择源创建新轨道与新版本，旧轨道迟到 ended 不得停止新共享。
屏幕共享终态由轨道与会话共同决定。所有停止入口汇入同一幂等清理函数，旧回调再晚也不能影响新捕获。
哪些情况会破坏契约
边界条件会把隐藏假设变成真实事故。弱网、刷新、并发和容量上限必须组合测试，因为单独出现时它们往往都能被重试掩盖。
- 只监听应用停止按钮，系统停止后发送方 UI 仍显示正在共享。
- 多个轨道共用一个全局 ended，音频结束错误终止仍正常的视频。
- 观看方刷新后没有会话对账，发送方长期保留无观众的编码任务。
如何逐条验证契约
发布闸门应包含确定性回归、随机时序探索和真实浏览器组合。发现一次失败后保存 seed 与状态轨迹，让它永久成为可重放用例。
- 从应用、浏览器工具栏、源窗口和权限撤销四条路径分别停止。
- 快速切换两次共享源，延迟触发旧轨道 ended，确认新会话保持。
- 观看方刷新、断网和正常退出时核对观看人数、轨道和发送端提示。
完成并不等于主路径跑通，而是每个终态都能对账、每个自动动作都受用户意图约束、每个成本都有明确上限。