http/2无法突破sse单域名6连接限制，因sse仍被视作独立http/1.1长连接，不参与http/2多路复用；可行方案是子域名散列或单连接多会话复用。
HTTP/2 本身不能直接帮 SSE 突破浏览器单域名 6 连接限制，因为 SSE 本质上仍是 HTTP/1.1 风格的长连接，它不参与 HTTP/2 的多路复用机制。即使你的域名启用了 HTTP/2，EventSource 发起的 SSE 请求仍会被浏览器当作独立的、不可复用的 HTTP 连接来管理，和其他 fetch/XHR/图片一样，共用同源 TCP 连接池配额（Chrome/Firefox/Safari 默认 6 个）。
为什么 HTTP/2 对 SSE 无效
SSE 基于标准 HTTP 响应流，服务端需返回 Content-Type: text/event-stream 并保持连接打开。浏览器底层将每个 EventSource 实例视为一个“持久性 HTTP 连接”，而 HTTP/2 的多路复用只对同一 TCP 连接上的多个 HTTP/2 请求生效——SSE 不发起新请求，而是持续复用初始响应通道，这个通道在协议栈中不被 HTTP/2 流（stream）抽象所覆盖。因此：
- 每个
new EventSource(url)占用一个独立 TCP 连接槽位 - 6 个 SSE 连接 + 1 张图片 = 第 7 个资源必须排队等待
- 启用 HTTP/2 后，普通 fetch 请求可复用连接，但 SSE 不会自动“挤进”那个复用通道
真正可行的突破方式：子域名散列
和静态资源、WebSocket 类似，SSE 可通过域名分片绕过单源限制。把 https://api.example.com/sse 拆成多个等效子域名，例如：
https://sse1.example.com/ssehttps://sse2.example.com/ssehttps://sse3.example.com/sse
前提是：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- DNS 能正确解析所有子域名（建议泛解析或预配置）
- TLS 证书覆盖全部子域（通配符
*.example.com最稳妥） - 子域名不携带 Cookie（避免因
Domain=example.com导致请求头膨胀） - 控制子域数量在 3～5 个之间（过多可能触发浏览器总 socket 数上限）
更优解：单连接 + 多会话复用（推荐）
比起开多个 SSE 连接，更轻量、更可控的方式是：只建 1 个 EventSource，后端通过会话 ID 或消息类型字段区分不同业务流。例如：
- 前端传 query 参数：
new EventSource('/sse?sessionId=abc123') - 后端在推送时加前缀：
id: msg-1\nevent: chat\ndata: {"text":"hello"}\n\n - 前端监听
chat事件，而非默认message
这样单用户多轮对话、多模块通知都复用一条连接，实测可降低并发连接数 60% 以上，且完全规避域名限制问题。
补充提醒：不要依赖“HTTP/2 + SSE”自动优化
目前没有任何主流浏览器将 SSE 纳入 HTTP/2 多路复用调度。所谓“HTTP/2 提升 SSE 性能”的说法是常见误解。如果你观察到启 HTTP/2 后 SSE 表现变好，大概率是因为其他优化（如 TLS 握手更快、头部压缩降低延迟），而非连接数限制被解除。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
