sse跨域关键在于前后端配置协同：服务端必须返回access-control-allow-origin（具体域名）和content-type:text/event-stream；前端启用withcredentials:true时，服务端还需返回access-control-allow-credentials:true，且origin不能为*。
JavaScript 中用 EventSource 处理跨域 SSE 请求，关键不在前端“怎么写”，而在于前后端配置必须协同一致。浏览器对 SSE 的跨域限制比普通 AJAX 更“安静”——失败时往往不报详细错误，只静默关闭连接，所以细节匹配特别重要。
服务端必须返回的两个核心响应头
EventSource 发起的请求本质是 HTTP GET，带 Origin 头，服务端必须明确回应以下两项，缺一不可：
-
Access-Control-Allow-Origin：必须是具体域名（如
https://your-app.com），不能用*；若前端启用了凭证，则此项必须精确匹配，且需同时返回Access-Control-Allow-Credentials: true - Content-Type: text/event-stream：不仅值要对，还要确保响应体真正以流式方式输出（禁用缓存、不提前结束连接）
前端 EventSource 的跨域写法要点
构造时是否携带凭证，决定了服务端配置方向：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 默认不带凭证（最常见）：
const es = new EventSource('https://api.example.com/events');
此时服务端可设Access-Control-Allow-Origin: *，但不能设Access-Control-Allow-Credentials: true - 需要传 Cookie 或 Authorization：
const es = new EventSource('https://api.example.com/events', { withCredentials: true });
服务端必须返回Access-Control-Allow-Origin: https://your-app.com（不能是 *）和Access-Control-Allow-Credentials: true
容易被忽略的辅助响应头
这些不是强制项，但不加可能引发断连、延迟或缓存问题：
- Cache-Control: no-cache：防止代理或浏览器缓存响应，导致连接中断后无法重连
- Connection: keep-alive：显式维持长连接
- X-Accel-Buffering: no（Nginx 环境）：禁用 Nginx 内部缓冲，避免事件堆积延迟送达
为什么不能在 EventSource 里加自定义请求头
EventSource API 本身不支持设置请求头（比如 Authorization、X-Token）。这是规范限制，不是 bug。浏览器出于安全考虑，禁止它触发预检（OPTIONS），也因此不开放 header 配置入口。如果必须传 token，可行方案有：
- 把 token 放在 URL 查询参数中（如
/events?token=abc123），服务端从中提取验证 - 使用
withCredentials: true+ Cookie 自动携带（需服务端 Set-Cookie 并配合 CORS 凭证配置） - 改用
sse.js这类增强库（支持 headers 和 POST），但它已脱离原生 EventSource 规范
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
