浏览器对 websocket 并发连接数限制为同源 6 条，是硬性策略；需通过子域名分片或路径级多路复用规避，并配合监控降级机制。
浏览器对 WebSocket 的并发连接数限制是硬性策略，不是 bug，也不是服务端能扩的——你建第 7 个 wss://ws.example.com 连接时，它大概率会卡在 CONNECTING 状态或直接触发 onerror，和后端性能无关。
为什么 WebSocket 不能像 HTTP/2 那样多路复用
HTTP/2 的多路复用发生在单个 TCP 连接上，但每个 WebSocket 连接都独占一条 TCP 连接。浏览器把 WebSocket 和 XHR/fetch/图片请求一起算进「同源最大并发 TCP 数」里（Chrome/Firefox/Safari 默认都是 6），所以你开 6 个 WebSocket + 1 个 fetch，那个 fetch 就得排队等。
- WebSocket 不走 HTTP/2 通道，即使你的域名启用了 HTTP/2，
wss://仍新建独立 TCP 连接 - 没有浏览器 API 能查当前已建 WebSocket 数，
WebSocket.OPEN状态也不代表 TCP 已就绪 - 频繁
new WebSocket()+close()不仅不释放连接槽位，还可能因 TIME_WAIT 状态加剧阻塞
子域名分片：最直接但有运维成本的绕过方式
把连接分散到不同子域名，每个子域名拥有独立的 6 连接配额。比如把 wss://ws.example.com 拆成 wss://ws1.example.com、wss://ws2.example.com……
Comet AI 浏览器
下载
下载 Comet AI 浏览器，体验由 Perplexity AI 驱动的革命性上网方式。内置 AI 助手可实时总结网页、跨标签页对比信息、自动执行任务。告别繁琐操作，让 AI 成为你的浏览副驾，大幅提升研究与工作效率。支持 Windows、macOS、Android 和 iOS。
- DNS 必须支持泛解析或提前配置好全部子域名，否则
ws3解析失败会导致连接静默失败 - TLS 证书需覆盖所有子域名（通配符证书
*.example.com或 SAN 证书） - 客户端需实现负载逻辑：可用轮询、哈希取模（如
userId % 4）、或根据连接成功率动态调度 - 注意跨子域名无法共享 cookie，若鉴权依赖 cookie，得改用 token 放在 URL query 或首次 handshake 消息里
路径级多路复用：推荐的轻量级方案
只维持 1 个 WebSocket 连接，所有业务消息通过自定义协议字段路由，前端按 type 分发到对应模块：
{
"type": "chat:message",
"id": "msg_abc123",
"data": { "from": "user1", "text": "hello" }
}
{
"type": "notify:unread",
"data": { "count": 5 }
}
- 避免连接管理复杂度，省去重连同步、心跳对齐等多连接协调问题
- 服务端需做消息分发层（如用
Map<string set>></string>维护 topic 订阅关系） - 前端要加简单序列化/反序列化逻辑，建议统一用
JSON.stringify()+JSON.parse()，别手写二进制协议 - 注意大消息（如文件 chunk）可能阻塞小消息，可约定优先级字段或拆出专用连接
监控与降级：别等用户投诉才发现瓶颈
连接限制问题往往表现为偶发、不可复现的“部分功能失联”，必须主动观测：
- 监听
onerror和onclose，当event.code === 1006（CLOSE_ABNORMAL）或event.reason含 “timeout” 时，大概率是连接被限或 DNS 卡住 - 记录每个连接从
new WebSocket()到open的耗时，持续 > 5s 应告警 - 准备 fallback：连续 3 次
WebSocket连接失败后，自动切到 Server-Sent Events（SSE）或长轮询；恢复后平滑切回 - 关键点：SSE 和轮询也受同域名并发限制，fallback 域名最好和主 WebSocket 域名分离（如
api.example.com）
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
