针对你提到的WebRTC动态添加轨道（比如屏幕共享）的实现困境，确实有第三种实用方案，同时也可以通过手动兼容逻辑让完美协商方案适配旧浏览器，下面详细说明：

第三种方案：应用层协商锁机制 #

这种方案相当于在信令层实现一个"协商互斥锁"，从业务逻辑层面避免两端同时发起协商冲突，既不需要固定Offer发起方，也不依赖浏览器的原生回滚支持：

• 当一端触发onnegotiationneeded（或者需要主动添加轨道）时，先通过信令向对方发送一个"协商请求锁定"的消息；
• 对方收到锁定请求后，暂时抑制自己的onnegotiationneeded触发逻辑（比如设置全局标记isNegotiating，触发时先检查该标记）；
• 发起方完成Offer/Answer交换后，通过信令发送"协商解锁"消息，对方恢复正常的协商触发；
• 如果两端同时发起锁定请求，可以约定优先级规则（比如以连接发起方、设备ID更小的一方优先），另一方主动取消自己的协商流程，转而响应对方的请求。

这种方案兼容性极强，所有支持WebRTC的浏览器都能运行，同时避免了固定Offer方带来的信令耦合，延迟也比传统方式低很多。

完美协商方案的向下兼容实现 #

如果你更倾向于使用标准的onnegotiationneeded模式，可以通过手动实现回滚逻辑来适配不支持原生回滚的浏览器：

1. 状态保存：在每次成功设置localDescription和remoteDescription后，保存当前的描述状态（比如用变量存储lastLocalDesc和lastRemoteDesc）；
2. 冲突检测：当检测到两端同时发起协商时（比如自己刚发送Offer，就收到了对方的Offer），判断哪一方的协商发起时间更早，或者提前约定优先级；
3. 手动回滚：需要放弃当前协商的一端，调用pc.setLocalDescription(lastLocalDesc)和pc.setRemoteDescription(lastRemoteDesc)恢复到之前的状态，然后重新处理对方的Offer/Answer；
4. 抑制重复触发：在协商过程中，设置isNegotiating标记，避免onnegotiationneeded重复触发导致的循环。

需要注意的是，手动回滚需要严格处理时序，确保状态恢复的准确性，同时要处理ICE候选的缓存与重新收集逻辑，避免丢包。

补充优化思路 #

另外，你提到replaceTrack仅适用于替换已有轨道，但如果是屏幕共享场景，其实可以提前创建一个空的视频transceiver，后续用replaceTrack把屏幕轨道替换进去——这种方式不需要重协商，也是一种优化思路，但前提是你能提前预判需要添加的轨道类型（比如提前知道要共享屏幕）。

内容的提问来源于stack exchange，提问作者Marius Melzer