长轮询模式与重连逻辑

长轮询按以下周期运行：客户端发送 HTTP 请求，服务器保持连接打开，直到有新数据可用（或发生超时，通常为 30 到 60 秒），服务器返回数据，然后客户端立即发起下一次请求。这会形成近乎持续的连接，并具有服务器推送的特征。

在 React 中，长轮询可以通过 useEffect 内部的异步递归函数实现。该函数发起请求、处理响应，然后再次调用自身。组件卸载时，AbortController 信号会停止递归。只要组件仍处于挂载状态且尚未收到中止信号，该函数就会持续循环。

在 useEffect 顶部创建一个 AbortController，并将 controller.signal 传递给每次请求。在清理函数中调用 controller.abort()。组件卸载时，这会取消任何正在进行的请求，避免对已卸载的组件进行状态更新，并防止网络资源泄漏。

长轮询请求失败时，不要立即重试——请在下一次尝试前等待一段时间。指数退避会在每次连续失败时将等待时间加倍：1 秒、2 秒、4 秒、8 秒、16 秒，最多等待 30 秒。这样可以避免持续冲击发生故障的服务器，并为临时问题的解决留出时间。响应成功后，请将等待时间重置为 1 秒。

当许多客户端轮询同一台服务器时，不带抖动的指数退避会造成“惊群效应”：所有客户端等待相同的时间后同时重试，再次压垮服务器。请通过随机化等待时间来添加抖动：delay + Math.random() * delay。这样可以将重试分散到一个时间窗口内，减少服务器负载峰值。

请维护连接状态，以反映轮询的生命周期：isConnecting（初次连接或出错后正在重连）、isConnected（上一次轮询成功）和 isError（连续失败且已达到最大重试次数）。请在用户界面中显示此状态，让用户了解实时数据的可靠程度。

在下一次重试前的退避等待期间，您可以显示倒计时，例如“将在 8 秒后重连……”，并配合进度指示器。设置退避计时器时计算重试时间戳，然后每秒更新显示内容。这种透明的反馈可以让用户放心，了解应用正在积极尝试恢复。

轮询时，请使用递归 setTimeout（在响应处理程序中调用下一次轮询），而不是使用 setInterval。setInterval 会按固定间隔触发，不考虑上一次请求耗时多久，因此长时间运行的请求可能导致轮询重叠。递归 setTimeout 只有在上一次请求完成后才会开始下一次轮询。

请将轮询间隔作为钩子的配置选项公开：useLongPoll({ url, interval: 5000 })。不同数据源对新鲜度的要求不同：“在线状态”指示器可能每 30 秒轮询一次，而任务状态可能每 5 秒轮询一次。请避免在实现代码中硬编码间隔。

随着接口逐渐成熟，您可以用服务器发送事件替代轮询，以提高效率。使用轮询钩子的 React 组件应与传输层解耦。如果钩子公开相同的接口（onData、状态、错误），那么在底层将轮询切换为 EventSource 时，无需更改使用该钩子的组件。

当服务器保持长轮询连接且没有数据到达时，必须通过超时响应（返回空正文的 200，或返回 204 无内容）来避免连接无限期挂起。客户端随后会立即再次轮询。此服务器端超时（30 到 60 秒）与客户端请求超时不同，后者应设置得更长，例如 90 秒。

长轮询在连接错误后重试时，为什么要使用指数退避？

长轮询：客户端发起请求，服务器持续保持连接，直到有数据可用或发生超时；客户端在收到响应后立即重新请求。在 useEffect 中使用递归异步请求实现，并使用 AbortController 进行清理。发生错误时，采用指数退避（1 秒、2 秒、4 秒……上限为 30 秒），并加入抖动以避免惊群效应。使用递归 setTimeout 而不是 setInterval，以防止轮询重叠。跟踪 isConnecting/isConnected/isError 状态，为用户界面提供反馈。