[v1.4] VSCodeConnect 代码重构

[cyfung1031]

[v1.3/1.4] VSCodeConnect 重构：提升 WebSocket 连接稳定性与可维护性

本次 PR 对 src/app/service/offscreen/vscode-connect.ts 进行重构，目标是改善旧版在连接管理、重连逻辑与异常处理上的不稳定与难维护问题，使 VS Code 热重载流程在长时间运行与异常场景下表现更可靠。

新旧对比一览

项目	旧版（修改前）	新版（修改后）	改进效果
连接管理方式	直接使用原生 WebSocket，事件与状态分散在 connect / connectVSCode	集中管理 WebSocket 生命周期，统一在单一类中处理连接、事件与清理	状态更集中，逻辑更容易理解与维护
连接超时保护	无连接超时，WebSocket 可能长期停留在 CONNECTING	明确 30 秒连接超时（CONNECT_TIMEOUT），超时后自动 cleanup	避免无期限等待，提高异常场景下的可靠性
自动重连机制	使用 setInterval 每 30 秒重试，逻辑简单粗放	使用 setTimeout + 延迟重连，记录 lastParams 并支援指数退避	减少无意义重试，重连行为更可控
旧事件残留 / race condition	多次 connect 时，旧 socket 的 close / error 仍可能影响新连接	引入 epoch 机制，所有回调需验证当前连接代数	避免旧事件干扰新连接，行为更可预测
资源清理	仅在部分流程中 close socket / clearInterval，事件回调未移除	统一 cleanup()，清除 socket、timer，并移除所有 WebSocket 回调	降低记忆体泄漏与僵尸连线风险
稳定脚本 ID 生成	直接使用 uuidv5(data.data.uri)，未验证 payload 完整性	明确验证 script / uri 存在后才生成 stableId，并记录成功日志	避免异常 payload 导致安装错误
讯息处理健壮性	直接 JSON.parse，异常或未知 action 未处理	try-catch 包装解析流程，未知 action 与异常皆有日志	降低 crash 风险，除错更容易
日志详细度	仅少量 debug 日志	增加 debug / info / warn / error，多记录 epoch、url、uri 等关键信息	问题定位更直观
核心功能保留	hello 握手 + onchange 安装脚本	完整保留原有行为，仅重构流程与安全性	无功能变更，仅稳定性与可维护性提升

总结：旧版痛点 vs 新版价值

旧版主要问题：

• WebSocket 状态与事件分散，流程复杂且容易互相干扰
• 缺乏连接超时与完善清理，异常情况下容易残留连接
• 重连机制粗糙，长时间运行时行为难以预测

新版带来的好处：

• 连接、超时、重连、清理逻辑集中，状态更清楚
• 能正确处理 VS Code 重启、连线失败、网路中断等情况
• 日志更完整，未来除错与扩充成本更低

影响范围：仅限 VSCode 开发模式连接逻辑，不影响一般 ScriptCat 使用者。

测试建议

• 正常热重载：VS Code 储存 .user.js → ScriptCat 是否即时更新
• 断线重连：关闭 VS Code → 重新开启 → 是否能自动重新连接
• 快速连线测试：多次触发「连接开发模式」→ 是否无异常错误或重复行为
• 超时测试：使用无效 URL → 30 秒后是否正确 timeout 并进入重连流程

[CodFrm]

能放1.4就1.4了，现在两个版本内容挺多了，时间也挺久了

[cyfung1031]

AI 再重构

以下是对这两个版本 VSCodeConnect 类的比较分析：

项目	v0 (原版)	v1 (重构版)	评价 / 谁更好
epoch 机制实现	每次 connect 递增 epoch，旧回调被忽略	每次 startSession 递增 epoch，同样用来废弃旧回调	平手（逻辑等价）
重连逻辑的触发控制	较松散，onerror / onclose 都会 queueReconnect	使用 isReconnecting 锁 + 更明确的条件判断	v1 明显更好
重连定时器重复注册防护	仅检查 reconnectTimerId 是否存在	结合 isReconnecting 锁 + timer 存在检查	v1 更安全
connect() 函数的职责	包含建立 ws + 绑定事件 + 超时逻辑	只负责建立 ws + 绑定事件，超时独立看门狗	v1 职责更单一
超时清理位置	集中在 openSocket 的 finish() 内	分散在 handleOpen / handleClose 内	v0 更集中，v1 更分散
dispose / cleanup 彻底性	清理 timer + 移除事件 + close ws	同左，但命名为 dispose 更符合「销毁会话」语义	v1 语义更清晰
reconnectDelay 重置时机	只在连接成功时重置	收到 connect 请求时就重置（更积极）	v1 更合理
程式码结构与可读性	一个大 connect 方法 + 较长的 Promise	拆分成 startSession / connect / 多个 handler	v1 明显更好
事件处理函数的 epoch 检查	大多数有检查，但 onerror/onclose 内逻辑重复	每个 handler 开头统一检查 epoch	v1 更一致
防范「同时多个重连定时器」	仅靠 reconnectTimerId != null 防护	双重防护（锁 + timer存在）	v1 更稳健
错误处理的细腻度	较粗糙，部分错误直接 reject	更统一走 handleError → scheduleReconnect	v1 更好
整体维护性 / 未来扩展性	中等	较高（职责拆分清晰、状态管理更明确）	v1 胜出
引入的新 bug 风险	—	增加 isReconnecting 锁，可能误锁或漏解锁	v1 略高（但目前看正确）
程式码行数	较少	略多（因为拆分更多小函数）	v0 更精简

总结评价

v1（重构版）整体明显优于 v0，尤其在以下几个关键点：

1. 状态管理更安全：引入连接锁（isReconnecting） + epoch 双重防护，大幅降低「多个重连定时器同时触发」或「旧会话干扰新会话」的风险。
2. 职责分离更好：把「建立连接」与「超时管理」「重连调度」进一步拆分，单个函数更短、更专注。
3. 可读性与可维护性提升明显：事件处理统一在开头做 epoch 过滤，逻辑路径更线性。
4. 语义更清晰：dispose()、startSession() 等命名比 cleanup()、connect() 更能表达意图。