Auto Tab Cleaner 开发记录：安全清理空闲标签页

产品现在是什么

Auto Tab Cleaner 是一个 Manifest V3 Chrome 插件。它会跟踪标签页活动，并根据用户设置识别长时间未访问的标签页。 默认模式不是关闭，而是 discard：释放内存，但标签仍留在标签栏里，用户点开时再重新加载。

当前版本包含三种模式：monitor 只统计候选标签页，discard 默认安全清理，close 作为显式 opt-in 的高级模式。 它会保护 active、pinned、audible、内部浏览器页面和用户 allowlist 里的域名。close 模式下，插件会保留短期本地 restore history，用户可以从 popup 或 options 恢复最近被插件关闭的标签页。

今天看到的开发进展

项目历史很清楚地分成几步：先创建基础扩展；再补安全清理设计；然后实现 monitor、discard、close 三种模式； 接着引入 spec-driven development；最后围绕 restore history 和 allowlist 完成一轮可发布候选。

最新实现已经覆盖核心安全闭环：`src/background.js` 负责后台清理、活动记录、allowlist 判断、恢复历史和 runtime message； popup 负责状态和快速恢复；options 负责持久设置、close 风险提示、allowlist 管理和恢复历史保留规则。 README、Chrome Web Store listing 草稿、图标、截图和 smoke test 也已经补齐。

走过的弯路

第一条弯路是把“自动关闭旧标签页”当成默认价值。这个方向看起来直接，但破坏性太强：用户可能有未保存表单、 正在听声音的页面、重要 dashboard 或稍后要回来的资料。后来设计改成 safe by default：默认 discard，close 必须显式开启。

第二条弯路是低估了恢复能力的重要性。只要存在自动关闭，就必须先回答“误关后怎么找回”。所以 restore history 被设计成本地、限量、限期保存，只记录恢复所需的 title、URL、closedAt 和原因，并明确不做远程同步。

第三条弯路是 allowlist 规则容易越做越复杂。最终选择 hostname 匹配，而不是 path、query 或复杂 wildcard。 这让 MVP 更容易解释，也避免引入 content script、host permissions 或更大的隐私面。

第四条弯路是 MV3 service worker 的状态不能靠内存。标签 ID 是 session-scoped，service worker 会休眠， 所以 activity、settings、cleanup summary 和 restore history 都要放进 Chrome storage，并在 startup 时重建。

使用的工具

这个项目最有价值的工具是 spec-driven development。通过 gotalab/cc-sdd 接入的 Kiro 风格流程，把需求、设计、任务和实现拆开：先写 brief，再明确 requirements， 再做 design 和 tasks，最后按任务实现并验证。对这种涉及安全边界和隐私承诺的插件，比直接写代码稳很多。

Chrome extension 相关验证也很关键：`manifest.json` JSON 校验、`node --check` 语法检查、 自定义 Chrome extension workflow validator，以及 `tests/background-smoke.test.mjs` 里的 mock Chrome API 烟测。 这些测试覆盖 allowlist 跳过、close 成功记录、失败不记录、非 close 不记录、恢复和历史裁剪。

今天用于复盘和发布博客的工具包括 Codex、rg、git、curl、Vercel、Chrome DevTools 和 Browser。 Codex 负责读取项目记忆和历史，rg 快速定位文件，git 还原开发阶段，curl 验证线上 noindex，Vercel 发布日志站， 浏览器工具确认分类页和文章可访问。

下一步

下一步可以把 Auto Tab Cleaner 的发布流程再补齐：生成干净 ZIP、确认上传包不含 `.git`、`.kiro`、测试文件和素材源文件， 再做一次 unpacked extension 手动 smoke test。产品层面还可以继续观察 close 模式是否需要更强的首次确认， 以及 allowlist 是否需要从 hostname 扩展到更易理解的简单模式。