webtransport 必须使用 https:// 或 http://localhost；生产环境需 https 且证书可信，服务端须支持 http/3/quic；需显式关闭流防泄漏；低延迟场景应优先用 datagram 而非 stream。
WebTransport 构造函数必须用 https:// 或 http://localhost
直接把 new WebSocket('ws://...') 换成 new WebTransport('http://...') 会立刻报错：Failed to construct 'WebTransport': The URL's scheme must be 'https:' or 'http:' with localhost。HTTP/3 要求 TLS 加密或本地开发环境，非 localhost 的纯 HTTP 不被接受。生产环境必须走 https://，且证书要被浏览器信任（自签名需手动添加到系统信任库）。
连接前必须确认浏览器和服务端都真正在跑 HTTP/3
Chrome 控制台报 WebTransport is not supported in this browser，大概率是没开实验性功能；报 transport.ready rejected with NetworkError，则更可能是服务端没启 QUIC。验证方式只有两个：
- 打开 Chrome DevTools → Network 面板 → 点开任意请求 → 查看 Protocol 列是否为
h3（不是h2或http/1.1） - 用
curl -I --http3 https://your-domain.com测试服务端是否响应 HTTP/3 头
常见坑：Nginx 需编译支持 QUIC 的模块（如 quiche），Caddy 默认启用但得配 protocols h1 h2 h3；Node.js 服务端目前无原生支持，得靠 @cloudflare/webtransport 这类封装库。
创建流后必须显式 close() 或 abort()，否则资源泄漏
transport.createBidirectionalStream() 返回的流不像 WebSocket.send() 那样“发完就丢”。它背后绑定的是 QUIC 连接里的一个独立流，不释放就会持续占用连接资源。典型错误写法：
const stream = await transport.createBidirectionalStream();
const writer = stream.writable.getWriter();
await writer.write(encoder.encode("ping"));
// ⚠️ 忘了 writer.close() 或 writer.abort()
可靠流适合指令、状态同步等小数据；若要传大文件或长时媒体帧，建议用多个流分优先级，避免单一流阻塞影响其他逻辑。
真正降延迟的关键是 datagram，不是 stream
如果你的目标是「比 WebSocket 更低延迟」，别只盯着 createBidirectionalStream()。WebTransport 的不可靠数据报（transport.datagrams）才是突破口——它跳过重传、排序、流控，类似加密版 UDP：
- 发送端调用
transport.datagrams.writable.getWriter().write(data)后无需等待确认 - 接收端用
transport.datagrams.readable.getReader()拿到的就是原始包，顺序和到达率都不保证 - 适合游戏帧同步、音视频关键帧、传感器心跳等容忍丢包但不能忍延迟的场景
注意：datagram 单包大小受限于路径 MTU（通常 ≤ 1200 字节），超长数据得自己分片，且服务端必须明确开启 datagram 支持（不是所有 HTTP/3 服务器默认打开）。
最常被忽略的一点：WebTransport 不是“换个 API 就变快”，它把协议选择权交给了你。stream 和 datagram 行为差异极大，混用时必须清楚每条数据的语义——比如控制指令走 stream，渲染帧走 datagram，两者共用一个 WebTransport 实例没问题，但不能指望它们共享重传逻辑或拥塞窗口。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
