页面重建可能保留多条 socket 和定时器，服务端连接数量增加，页面仍显示旧状态。
连接归属页面生命周期，握手之后还有消息解析与有效性。关闭时清理资源，恢复后重置退避，后台与网络变化也会影响状态。
一、问题的范围与前提
浏览器所看到的页面、实际请求地址与服务器收到的路径要对应起来。页面来源、代理、缓存、Cookie 和连接生命周期分别影响行为。桌面浏览器、平板与嵌入式 WebView 可能具有不同访问条件，不能把某一端成功直接视为所有终端都已通过。
二、技术分析与方案取舍
关闭 socket 可能触发 onclose，旧回调又启动新定时器。因此 cleanup 还需配合组件有效标记或代际身份，防止销毁后自动复活。恢复订阅时检查重复处理，历史缺口通过业务游标补取。界面分别显示连接状态与最近有效消息，即使握手完成却一直无数据，也能识别为功能未就绪。
实现时明确入口和 API 基址，页面或组件销毁后清理连接与定时器。版本更新需要考虑旧页面并存，错误提示保留网络、鉴权和依赖异常的区别。若采用代理，路径替换和协议头按预期上游核对，不能同时在多处随意拼接前缀。
三、实现与排查的顺序
- 记录连接创建关闭。
- 销毁时清理资源。
- 使用有界退避。
- 按有效消息更新界面。
按这个顺序保留中间结果，可以区分输入条件、处理过程和最终输出。前一阶段的条件不成立时，先解释对应错误，再继续后面的试验；单次返回成功不足以覆盖整条链路。
最小示例
1
2
3
4
5
6
7
8
let retryTimer = null;
let socket = null;
function cleanup() {
if (retryTimer !== null) clearTimeout(retryTimer);
if (socket !== null) socket.close();
retryTimer = null;
socket = null;
}
清理片段属于连接管理的一部分，并非完整重连实现。实际代码还要禁止关闭后再次触发旧定时器，维护组件有效标记并恢复订阅或缺失消息。
示例聚焦当前技术关系。引用的图片、数据库、消息对象或处理函数，需要由调用环境提供；它不包含完整服务的认证、持久化与并发管理。验证时先用受控输入检查，再纳入应用。
四、验证和结果解释
一组完整的排查资料应能展示请求方法、路径、响应状态与时间，以及相关后端记录。只展示一个登录失败截图，无法判断请求是否到达目标服务。共享记录时移除凭据和个人信息，仅保留非敏感字段、状态与必要结构。
| 需要验证的结果 | 保留的对照 | 不能由此推出的结论 |
|---|---|---|
| 没有重复连接 | 固定输入与配置、对应输出 | 一次成功代表所有条件成功 |
| 恢复后只有一个订阅者 | 中断前后状态与错误阶段 | 没有报错代表结果正确 |
| 无新消息可被识别 | 恢复后的同条件复测 | 临时恢复代表根因已经消失 |
验证应覆盖首次打开、缓存命中、刷新、断网恢复与后台切换。连接状态和最后有效数据分别显示，旧数据不能因页面仍打开而永久看作实时。发布后的页面和静态资源还应逐项核对，不仅检查仓库文件是否存在。
五、适用边界与结论
重连不自动恢复丢失消息。需要序列或游标补取，不能把实时通道当历史消息库。
这条路径把“记录连接创建关闭”与“按有效消息更新界面”连在一起，中间保留可复查的条件。实施时优先确认“没有重复连接”，再检查“无新消息可被识别”；两者都满足，才能在当前样本与配置范围内评价方案。设备、数据或软件版本改变以后，相关假设需要重新验证。
