eventsource构造函数支持withcredentials选项，但仅部分浏览器可靠实现；跨域携带cookie需同时满足前端withcredentials:true、服务端access-control-allow-credentials:true且access-control-allow-origin非通配符、cookie设置samesite=none且secure:true。
EventSource 构造函数不支持 withCredentials 参数
浏览器原生 EventSource API 的构造函数签名是 new EventSource(url, options)，但 options 仅接受 withCredentials 字段——它确实存在，但**仅在部分浏览器中被实现，且行为不可靠**。更关键的是：即使设为 true，若服务端未严格配合，Cookie 仍不会发送。这不是前端单方面能控制的事。
跨域 SSE 携带 Cookie 必须同时满足三个硬性条件
缺一不可，任一环节失败都会导致请求头里没有 Cookie，后续所有事件流都无登录态。
- 前端创建
EventSource时必须传入{ withCredentials: true } - 服务端响应必须包含
Access-Control-Allow-Credentials: true - 服务端响应的
Access-Control-Allow-Origin不能是*，必须显式写出请求来源（如https://your-frontend.com）
常见错误：后端用 Express 写了 res.header("Access-Control-Allow-Origin", "*")，又开了 Access-Control-Allow-Credentials ——这会直接触发浏览器报错 Failed to construct 'EventSource': The value of the 'credentials' member is not supported if the 'origin' member is present。
为什么推荐 event-source-polyfill 而非原生 EventSource
原生 EventSource 在 Safari 和部分旧版 Chrome 中对 withCredentials 支持不稳定；更重要的是它**完全不支持自定义请求头**，而很多鉴权场景（如 Bearer Token）无法只靠 Cookie 解决。
event-source-polyfill 底层用 XMLHttpRequest 或 fetch 实现，因此能：
- 稳定支持
withCredentials: true，且兼容性更好 - 允许你通过 URL 参数（如
?token=xxx）或封装请求逻辑注入认证信息 - 便于统一管理重连策略、错误回调、连接状态
示例初始化（注意不是直接 new EventSource）：
import { EventSourcePolyfill } from 'event-source-polyfill';
<p>const es = new EventSourcePolyfill('/api/events', {
withCredentials: true,
headers: { 'X-Requested-With': 'XMLHttpRequest' }, // 可选，某些后端校验此头
});</p>
Cookie 自身也得“同意跨站发送”
即使前端和服务端配置全对，如果 Cookie 是服务端用 httpOnly: true + SameSite=Lax（默认值）设置的，它在跨域 SSE 请求中依然不会被带上。
必须确保后端设置 Cookie 时明确指定：
-
SameSite=None（强制要求） -
Secure: true（即只在 HTTPS 下发送；开发环境若用 HTTP，则需改用SameSite=Lax或SameSite=Strict并配合 localhost 特殊处理）
例如 Express 中设置登录态 Cookie：
res.cookie('sessionid', 'abc123', {
httpOnly: true,
secure: true, // 生产必须
sameSite: 'None', // 跨域必需
maxAge: 24 * 60 * 60 * 1000
});
这个点最容易被忽略：前端反复检查 withCredentials 和 CORS 头都没问题，最后发现是 Cookie 自己“拒绝出门”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
