题干与适用场景
应用需要传输高频光标、姿态或拖拽预览，最新状态比每一条历史更新更重要。请说明如何使用 WebTransport 的 datagrams，处理无序、丢失、大小预算、背压、重连和不支持浏览器。不要只比较 WebSocket 和 HTTP/3。
面试官考察点
- 是否理解 datagram 是不保证到达和顺序的低延迟通道，不能承载关键事实。
- 是否能设计消息序列号、过期时间、丢弃策略和流量预算。
- 是否区分 datagram 与可靠 stream，并处理发送队列、拥塞和重连。
- 是否提供 HTTPS、能力检测、降级和可观测性方案。
回答前需要澄清的问题
- 哪些消息是可重建的瞬时状态，哪些必须可靠、有序或持久化？
- 单个数据报大小、更新频率、目标延迟和可接受丢包率是多少？
- 客户端能否从快照恢复？重连后从哪里获取权威状态？
- 浏览器与网络是否支持 WebTransport、HTTPS 和 HTTP/3？降级到什么传输？
30 秒回答框架
我会把 datagram 限定为可丢弃的最新状态，把操作记录、权限和最终结果放进可靠 stream 或服务端存储。每条状态带序列号、时间戳和对象版本，接收端只应用更新版本并主动丢弃过期数据；发送端监控队列和预算，不能无限排队。建立连接后先发可靠快照，断线重连重新获取权威状态；能力检测失败时降级到已有可靠通道。
分步骤深入解答
1. 划分可靠性边界
光标和预览可重建，适合数据报；文档操作、权限变更和提交结果必须走可靠有序通道。不要因为同一连接同时支持两类传输，就混用它们的语义。
2. 设计可丢弃消息
为对象携带单调序列号、生成时间和会话版本。接收端只接受比当前版本新的消息；超过新鲜度窗口、对象已删除或版本落后时直接丢弃。消息不应包含无法从快照恢复的唯一事实。
3. 控制预算与恢复
限制单条大小、每秒发送量和待发送队列长度；队列接近上限时合并同一对象的最新状态。重连后先通过可靠流取得快照，再恢复数据报更新，避免用旧的瞬时状态覆盖新快照。
4. 兼容与可观测性
仅在安全上下文中建立连接并检测浏览器能力。记录丢弃率、队列长度、发送失败、重连次数和状态修复耗时；不支持 WebTransport 时降级到 WebSocket 或轮询，并保持相同的状态版本协议。
高质量示范回答
我会先把消息分成可重建瞬时状态和不可丢失事实：光标、拖拽预览走 datagram，文档操作、权限和提交结果走可靠 stream。每个数据报带对象版本、序列号和时间戳，接收端只接受更新版本并丢弃过期消息；发送端限制大小、频率和队列，按对象合并最新状态。连接建立或重连时先用可靠流获取权威快照，再继续应用数据报。全程要求 HTTPS，检测能力并准备 WebSocket/轮询降级，监控丢弃率、队列、重连和快照修复时间。
常见错误
- 把 datagram 当成可靠、有序的消息队列。
- 用数据报承载权限、扣款或不可重建的业务事实。
- 没有序列号和过期时间，导致旧状态覆盖新状态。
- 无限累积发送队列，忽略拥塞和内存预算。
- 重连后直接继续发旧状态，没有先同步权威快照。
- 忽略 HTTPS、浏览器能力检测和降级路径。
追问及应对
丢包率升高时怎么办？
缩短状态保留窗口、降低发送频率并合并同对象更新；关键事实继续走可靠流。若状态无法从快照恢复，应重新评估其是否适合 datagram。
如何防止乱序覆盖？
比较对象版本或单调序列号，只接受更大的版本；重连会话要更新 epoch，拒绝旧会话的消息。
为什么还需要可靠流？
数据报不保证到达和顺序，适合“新值覆盖旧值”的状态。操作日志、快照、权限和最终确认必须具备可靠传输与持久化语义。