一句话定义：WebTransport 是浏览器提供的一组 JavaScript 接口，让网页与服务器之间同时开多条独立通道，既能发可靠有序的数据流（stream），也能发“丢了就算了”的数据报（datagram）；它底层运行在 HTTP/3 和 QUIC 之上。
先说说它想解决什么。WebSocket 是目前最常用的实时通道，但它建立在 TCP 之上，本质上是一根严格有序的水管：所有消息排成一队，前面的一个数据包在路上丢了，后面的数据哪怕早就到了，也只能在内核缓冲区里等着重传。这就是队头阻塞（head-of-line blocking）。聊天、推送通知无所谓，等几十毫秒没人察觉；但云游戏的操作指令、实时语音的一帧音频、视频会议的画面，等不起。晚到的数据等于没用的数据。
打个比方：WebSocket 是把所有货物装进一条单车道隧道，前面一辆车抛锚，后面全堵死。QUIC（基于 UDP 的传输协议，在用户态实现可靠传输、加密与拥塞控制）则修了多条独立车道，每条 stream 有自己的序号和重传逻辑，A 车道追尾不影响 B 车道照常通行；而 datagram 更像发传单：不重传、不排序，最新的一版到了就行，旧的丢了反而更好。此外，QUIC 把加密（TLS）写进了协议本身，连接建立更快，也省掉了 TCP 时代的跨层等待。
和相邻概念的区别：
| 底层 | 可靠性 | 连接模型 | 典型场景 | |
|---|---|---|---|---|
| WebSocket | TCP，单条字节流 | 全可靠、全有序 | 客户端—服务器 | 聊天、通知、简单推送 |
| WebTransport | HTTP/3 + QUIC | 流可靠有序，数据报不可靠 | 客户端—服务器，复用 HTTP 生态 | 云游戏、低延迟直播、实时语音 |
| WebRTC 数据通道 | SCTP over DTLS | 可配置 | 主要是点对点，需信令与 ICE | 视频通话、P2P 传文件 |
关键差别有两层。第一层是结构：WebSocket 只有一条流，WebTransport 可以开任意多条双向或单向流，互不干扰；还有一条不可靠的 datagram 通道。第二层是生态：WebRTC 能力很强，但要处理信令、ICE、SDP 这一整套，且天生偏点对点；WebTransport 是标准的客户端—服务器模型，沿用同源策略、Cookie、请求头这套 Web 安全与运维习惯，后端接起来更像普通 Web 服务。
需要说清的边界：单条 stream 内部依然是可靠有序的，这条流里丢了包，这条流自己还是会等；真要极致低延迟，得用 datagram 并自己在应用层处理丢包。它也需要 HTTPS 环境与支持 HTTP/3 的服务器，浏览器兼容情况各家不同，具体以官方文档的兼容性表为准。
对从业者的意义：做 AI 语音对话，用户打断时你要能立刻丢掉还在排队的那段音频——这是 datagram 的活；做模型流式输出，多条独立流可以让不同会话互不拖累；做云游戏或远程操控，操作指令走 datagram、资源加载走 stream，一条连接两种语义。对普通职场人来说，它意味着以后网页里的实时协作、直播连麦、云端渲染，卡顿和“延迟半秒”的体验会慢慢变少——你不会看到这个名字，但会感受到那根水管变成了多车道。