EventSource不会自动重连，其重连由浏览器控制且能力有限：仅对网络层错误或5xx响应触发，默认间隔3秒，不处理静默断连、不支持自定义退避、无法刷新token或动态URL。
不会自动重连。Mercure 的浏览器客户端（MercureEventSource）本身不包含任何重连逻辑，它只是对原生 EventSource 的封装，而标准 EventSource 的重连行为完全由浏览器控制，且极其有限。
浏览器 EventSource 的重连机制很弱
原生 EventSource 在连接断开后会按固定规则尝试恢复：
- 默认重试间隔是 3 秒（由响应头
Retry:指定，若未设置则用此值） - 它只在收到 HTTP 5xx 或网络层错误时触发重连；若连接被静默关闭（如 NAT 超时、代理中断），浏览器可能长时间卡在“connecting”状态而不触发重试
- 无法自定义退避策略、最大重试次数或主动探测“假连接”
- 重连 URL 固定，不支持动态刷新 token 或更新订阅主题
FrankenPHP 的 Mercure Hub 不改变这一限制
FrankenPHP 自带的 Mercure Hub 是服务端组件，它负责广播、JWT 验证和 SSE 流分发，但对客户端重连行为零干预。它不注入 JS、不提供 SDK、也不监听前端连接状态。所以：
-
MercureEventSource实例一旦创建，就完全交由浏览器调度 - 服务端返回
200 OK+text/event-stream后，后续所有重连决策都在浏览器内完成 - 即使 Hub 配置了
ping_interval，那也只是向客户端发送ping消息用于保活，不是重连指令
必须手动封装重连逻辑
生产环境要可靠，就得自己接管重连流程。核心动作包括：
立即学习“PHP免费学习笔记（深入）”；
- 监听
onerror和超时（比如 30 秒无消息），而非只依赖onclose - 用
isReconnecting标志位防止并发多个MercureEventSource实例 - 每次重建前调用旧实例的
close()，并清除其引用（避免内存泄漏） - 重连前重新生成带时效 JWT 的 URL（token 过期会导致 401，且浏览器不会自动重试）
- 实现指数退避：延迟 =
Math.min(1000 * Math.pow(2, retryCount), 30000)，并加随机抖动 - 重试达上限（如 10 次）后停止自动重连，改由用户手动触发或提示网络异常
真正容易被忽略的是：Mercure 的重连失败往往不是代码问题，而是 token 过期未刷新、Hub 的 allow_anonymous 配置与前端鉴权方式错配、或反向代理（如 Nginx）提前切断空闲连接——这些都会让浏览器永远等不到响应，却不会抛出可捕获的错误。
