Eventsource连接失败但不报错的主因是服务端响应头缺失content-type: text/event-stream或消息格式错误（如前置空行、末尾单换行）；需检查响应头、验证readystate、手动close并重建实例。
EventSource 连接失败时浏览器不报错但收不到数据
这是最常见的情况：页面看似正常执行了 new EventSource()，控制台没报错，但 onmessage 从不触发。根本原因通常是服务端响应头缺失或错误。
- 必须返回
Content-Type: text/event-stream，少一个字母或带 charset 都可能被部分浏览器（如 safari）静默拒绝 - 响应体开头不能有空行、bom 或任意前置输出（PHP 的
echo "n";、Node.js 的res.write("n")都会中断流） - 每条消息末尾必须是两个换行符
nn，单个n会导致解析卡住 - chrome DevTools 的 Network 面板里，SSE 请求状态码为 200 但预览为空，基本可断定是响应头或格式问题
重连机制没生效，断网后连接永远挂起
EventSource 自带重连，但默认行为很“懒”：断连后等 3 秒再试，且不区分网络不可达、服务宕机还是超时。实际项目中必须手动接管。
- 监听
onerror时不要只看事件对象——它在连接建立前、建立中、已建立后都可能触发，无法区分具体阶段；应结合readyState判断：readyState === 0表示未连接或连接失败，=== 2才是已连接 - 主动调用
eventSource.close()后，必须重新new EventSource()，仅靠原实例不会自动恢复 - 建议用指数退避：首次重试 1s，失败则 2s、4s、8s…上限设为 30s，避免雪崩式请求
- 服务端若返回
retry: 5000，仅影响下一次重连间隔，不影响前端已设置的逻辑
跨域场景下 EventSource 报 CORS 错误
和普通 ajax 不同，EventSource 只支持 GET，且不发送 cookie（除非显式配置），但 CORS 检查更严格：服务端必须返回 access-Control-Allow-Origin，且不能为 *（当携带凭证时）。
- 如果前端需要带 Cookie（比如鉴权 session），初始化时必须加
{ withCredentials: true }，否则浏览器直接拒发请求 - 服务端响应头必须同时满足：
Access-Control-Allow-Origin: https://your-domain.com（不能是*）、Access-Control-Allow-Credentials: true - nginx 反向代理时，确保 proxy_pass 后端服务返回了正确响应头，而不是被 Nginx 覆盖或过滤掉
- 开发环境用本地 server 代理接口？确认代理规则转发了所有响应头，特别是
Access-Control-Allow-*系列
长时间运行后内存泄漏或连接堆积
页面未销毁 EventSource 实例就跳转或关闭，是典型泄漏源。现代浏览器虽会回收，但旧版 Chrome 或 electron 中可能残留连接。
立即学习“前端免费学习笔记（深入）”；
- 组件卸载/页面离开前，务必调用
eventSource.close()，并在调用后将引用置为NULL - 避免全局变量存储
EventSource，尤其在 SPA 中反复进入同一页面时，容易重复创建却未清理旧实例 - 服务端需设置合理的 keep-alive 心跳（如每 15s 发送
:keepalivenn），否则 Nginx/apache 默认 60s 断连，前端会误判为异常断开而频繁重连 - 用
chrome://net-internals/#events查看底层连接状态，比单纯看 Network 更准——能看到是否真的建立了 HTTP/1.1 流式连接
真正麻烦的不是连不上，而是连上了却收不到数据，或者断连后你以为它在重试，其实早就卡死在 readyState 0 了。检查响应头、验证 readyState、手动控制 close 和重建，这三步绕不开。