[Feature] 重构：清理 src/pages/content/index.tsx 里的大量重复性代码

[andy-ish]

🥰 需求描述 | Feature Description

现存 src/pages/content/index.tsx 在 window.addEventListener('beforeunload', () => { /* … */} （第 649 行）中有大量的重复样板代码来处理内存泄露问题，相应代码节选如下：

// Setup cleanup on page unload to prevent memory leaks
    window.addEventListener('beforeunload', () => {
      try {
        window.removeEventListener('unhandledrejection', onUnhandledRejection);
        window.removeEventListener('error', onWindowError);
        // Disconnect watermark-remover observers.
        stopWatermarkRemover();
        if (folderManagerInstance) {
          folderManagerInstance.destroy();
          folderManagerInstance = null;
        }
        if (promptManagerInstance) {
          promptManagerInstance.destroy();
          promptManagerInstance = null;
        }
        if (slashPromptFeatureInstance) {
          slashPromptFeatureInstance.destroy();
          slashPromptFeatureInstance = null;
        }
        if (quoteReplyCleanup) {
          quoteReplyCleanup();
          quoteReplyCleanup = null;
        }
// ……

大量的代码被用来重复地执行清理逻辑，违反了代码的 DRY (Don't Repeat Yourself) 原则。因此，本 Issue 提出对此进行重构。

🧐 解决方案 | Proposed Solution

在 src/core/utils 模块新增一个管理类，集中式地封装记录和执行清理函数的逻辑。

✅ 验收标准 | Acceptance Criteria

实际上，代码修改后，用户应该能感知到 0 处变动，因为这是一个不影响代码功能的重构。

🔄 替代方案 | Alternatives Considered

No response

📝 补充信息 | Additional Information

我已经在本地完成了相应改动并测试通过（点击跳转），若仓库 Owner approve，我可以直接开启 PR。

💻 贡献意愿 | Contribution

• 我愿意为该功能贡献代码 / I am willing to contribute code for this feature
• 💡 若 Issue 未标记 community-only，其他贡献者可评论 /claim 认领 / Other contributors may use /claim unless the issue is labeled community-only

[Nagi-ovo]

感谢梳理。我确认这段 cleanup 样板代码确实已经比较多，集中管理的方向是合理的。

不过当前分支建议先调整后再开 PR：

• 删除遗留的调试 console.log。
• WillCleanUp.execute 中一个 cleanup 抛错会导致后续 cleanup 不再执行，而且列表不会清空；需要保证各项隔离执行并最终释放引用。
• 重构后 cleanup 的执行顺序发生了变化，不符合“0 行为变化”的验收目标；需要明确并测试执行顺序。
• plugin platform/custom website 会在注册 beforeunload 之前提前 return，已登记的 cleanup 实际不会执行。

另外建议补充异常、执行顺序和 early-return 分支的测试。现有 typecheck、全量测试和 Chrome 构建我这边都已验证通过，主要还需要补齐 lifecycle 正确性。感谢贡献！

[andy-ish]

感谢 Review。

前两个建议已采纳：

• 移除了多余的 console.log；
• 增强了 WillCleanUp.execute 的健壮性，且添加相关测试。

Fork 仓库已同步相应更新。

---

关于 cleanup 执行顺序发生变化的问题：

目前我既没有证据证明顺序变化会导致 bug，也没有证据证明顺序变化不会导致 bug。
如果能确定清理函数之间没有互相依赖（即顺序不重要），则可以适当修改 Issue 对于验收目标的措辞，不追求 100% 零行为变化。
如果清理顺序确实不能修改，我也可以调整代码确保清理顺序和之前一致。

---

关于 early-return：

我查阅了项目的主分支，发现“注册 beforeunload 之前提前 return ”的行为在我的改动之前便存在，可能并非本次重构引入。
鉴于该问题确实会导致 cleanup 代码无法执行，我们可以采取以下措施的一个：

• 将该问题的修复纳入本 Issue 以及相关 PR 的范围内；
• 或者 新建一个 Issue 专门处理该问题？

如果纳入本 Issue 范围内，我会补充对应的修复。

[Nagi-ovo]

感谢更新。关于剩余两点：cleanup 顺序请保持与现有实现一致，继续以“0 行为变化”为目标；early-return 确属既有问题，建议另开 Issue 处理，避免扩大本次重构范围。
另外，新版 execute 内部直接记录并吞掉所有异常，会绕过入口原有的 extension-context-invalidated 过滤。建议 registry 不直接打印日志，先清空队列、逐项执行，再将异常交给调用方处理。

[andy-ish]

好的，没问题。

不过我最近几天电脑不在身边，可能处理会稍微延期几天。预计最晚下周日（8 月 9 日）之前可以完成相关提交，感谢理解 🙏

[andy-ish]

已完善 cleanup 顺序和 execute 异常处理，见 #905。

[Nagi-ovo]

@andy-ish 感谢贡献。#905 已合并到 main（f0f9c37c），会随下一个版本发布；如果发布后仍有清理生命周期问题，欢迎重新打开这个 Issue。

[andy-ish]

已开启 #912 表明 early-return 问题。