webtransport必须基于真实协商成功的http/3连接，否则new webtransport()必失败；报securityerror因url非https或非localhost，notsupportederror因浏览器版本低或未启用实验标志，networkerror则表明服务端未真正支持http/3。
WebTransport 不能直接“建立 HTTP/3 通道”，它依赖已存在的、真实协商成功的 HTTP/3 连接；没跑通 h3，new WebTransport() 就是死路一条。
new WebTransport() 报 SecurityError 或 NotSupportedError 怎么办
这两个错误不是配置问题，而是环境硬性不达标：
-
Failed to construct 'WebTransport': The URL's scheme must be 'https:' or 'http:' with localhost→ 地址用了http://example.com（非 localhost）或ws:///wss://；必须是https://your-domain.com或http://localhost:port -
WebTransport is not supported in this browser→ Chrome 版本低于 115，或未开启实验标志：chrome://flags/#enable-webtransport（需重启） -
transport.ready rejected with NetworkError→ 浏览器连上了，但服务端没真正响应 HTTP/3；不是证书无效就是 QUIC 模块没启用
怎么确认浏览器和服务端真在用 h3 协议
别信文档说“支持”，只看实际协商结果：
- Chrome DevTools → Network 面板 → 刷新页面 → 找任意一个请求（比如 HTML 或 JS）→ 看 Protocol 列是否为
h3；如果是h2或http/1.1，navigator.webtransport就是undefined - 终端执行：
curl -I --http3 https://your-domain.com；返回HTTP/3 200且含alt-svc头才算通过 - Nginx 需编译
quiche模块；Caddy 2.8+ 默认支持，但得在配置里显式写protocols h1 h2 h3
datagram 和 createBidirectionalStream() 到底该选哪个
这不是性能高低问题，是语义和场景错配就会出事：
-
transport.datagrams：不可靠、无序、无重传，适合心跳、游戏帧、丢得起的小状态包；延迟最低，但不能传文件或指令 —— 它就是加密 UDP -
transport.createBidirectionalStream()：可靠、有序、带流控，适合配置同步、小文件、命令；但单一流内部阻塞不影响其他流，这是比 WebSocket 强的地方 - 传视频帧？别塞进单个 stream；拆成多个流（控制流 + 视频流 + 音频流），或用
datagram+ 应用层 FEC
流不 close 就泄漏，不是警告是事实
createBidirectionalStream() 返回的流绑定 QUIC 连接里的独立流 ID，不释放就一直占着连接资源：
- 写完数据后必须调用
writer.close()或writer.abort()；await writer.write(...)后直接结束函数，等于留了个悬空流 - 常见错误写法：
const writer = stream.writable.getWriter(); await writer.write(...);→ 缺少writer.close() - datagram 的
writable.getWriter()也一样：写完要releaseLock()，否则后续写入会卡住
最常被忽略的点：WebTransport 不是“升级 WebSocket 就行”，它是全新协议栈；h3 没跑通，所有 API 调用都只是抛错。验证必须落到 Protocol: h3 和 curl --http3 这两级，缺一不可。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
