EventSource 的 retry 字段仅在服务端通过响应头或事件流中的 retry: 行显式设置时生效，前端无法通过构造函数配置；其值必须为纯数字、独占一行、冒号后有空格，且需在每次事件前重复发送以维持策略。
EventSource 的 retry 字段只在服务端未显式设置时才生效
很多人以为只要在前端 new EventSource 时传个参数就能控制重连间隔，其实不是。EventSource 的 retry 是一个**服务端响应头或事件流中的指令**，前端无法通过构造函数参数设置它。浏览器只认服务端发来的 retry: 行（注意冒号后有空格），比如：
retry: 5000 data: hello
如果服务端没发这行，浏览器会用默认值——通常是 3 秒（不同浏览器略有差异，Chrome 是 3000ms，Firefox 也是约 3s）。
服务端必须在每个事件前或首次响应头中发送 retry
retry 不是一次性配置，而是对后续所有重连行为生效的“当前策略”。它可以在两个地方出现：
- HTTP 响应头：
Cache-Control: no-cache+Content-Type: text/event-stream+Retry: 10000（注意首字母大写不影响，但字段名必须是Retry） - SSE 流内容中：
retry: 2000\n（必须独占一行，且后面要跟换行符）
常见错误：只在第一个事件里写 retry，之后就不再发送——这样断连后重试仍可能回落到默认值。稳妥做法是：每次发送事件前都插入 retry: NNNN\n 行，或至少在连接建立后的前几秒内重复发送几次。
立即学习“前端免费学习笔记（深入）”；
浏览器对 retry 的解析很脆弱，格式错一点就失效
以下任一情况都会导致 retry 被忽略，退回到默认重试间隔：
-
retry行末尾多了空格或制表符，比如retry: 3000 \n - 写成
retry : 3000（冒号前后有空格） - 数值不是纯数字，比如
retry: 3s或retry: "3000" - 放在
data或event行之后，而非事件块开头（虽然规范允许它出现在任意位置，但部分浏览器实现只识别块首的retry）
调试建议：用 curl 或浏览器 DevTools 的 Network → Response 查看原始流，逐字确认 retry: 行是否干净、独立、数值合法。
断线重连的实际间隔还受浏览器指数退避影响
即使服务端正确设置了 retry: 1000，你也不一定会看到稳定 1 秒重连。现代浏览器（Chrome ≥90、Firefox ≥85）在连续失败后会自动启用指数退避，例如：1s → 2s → 4s → 8s → … 直到上限（通常 60–300 秒）。这个机制不可关闭，也绕不过。
这意味着：
- 单次短暂断连（如网络抖动）大概率按
retry执行 - 服务端长时间宕机时，重试间隔会越来越长，避免雪崩
- 如果你需要“强制立刻重试”，只能手动
eventSource.close()后 new 一个新的实例——但这会丢失上次的lastEventId，需自行维护
真正可控的只有服务端那个 retry 行；其余都是浏览器策略，别试图 hack。
