For the complete documentation index, see llms.txt. This page is also available as Markdown.

Chrome插件清理当前网站缓存和本地存储

前端开发或给客户部署页面时,经常遇到一个很现实的问题:代码已经发了,但对方浏览器还在命中旧缓存。

普通刷新、强刷、清浏览器缓存都不一定稳定,因为缓存来源可能有很多:

  • HTTP cache

  • Cache Storage

  • Service Worker

  • Cookie

  • LocalStorage

  • SessionStorage

  • IndexedDB

所以我做了一个 Chrome MV3 插件,目标很简单:只清理当前网站的数据,然后自动硬刷新当前页面。

manifest 权限

MV3 里需要声明这些权限:

{
  "manifest_version": 3,
  "name": "站点缓存清理工具",
  "version": "1.1.0",
  "permissions": [
    "browsingData",
    "activeTab",
    "tabs",
    "storage",
    "scripting"
  ],
  "host_permissions": ["<all_urls>"],
  "background": {
    "service_worker": "background.js"
  },
  "commands": {
    "clear-and-reload": {
      "suggested_key": {
        "default": "Alt+Shift+R",
        "mac": "Alt+Shift+R"
      },
      "description": "清除当前网站数据并硬刷新"
    }
  }
}

如果要上 Chrome Web Store,可以在商店版构建时去掉 host_permissions,减少审核压力。

只清当前站点

不要直接清全浏览器缓存。更安全的方式是根据当前 tab 的 URL 计算 origin:

同时要排除浏览器内部页面:

browsingData 清理

这里可以清掉大部分站点数据,但有一个问题:sessionStorage 不一定能通过 browsingData 处理干净。

在 MAIN world 清 sessionStorage

sessionStorage 属于页面上下文,所以需要把脚本注入到页面的 MAIN world:

这个点很关键:如果只调用 browsingData.remove,用户页面的 session 状态有时还会留着,导致“明明清了缓存但页面还是不对”。

清理后硬刷新

完整流程就是:

外部分发自动更新

如果不走 Chrome Web Store,也可以用 CRX + updates.xml 做外部分发。构建时生成:

注意:

  • update_url 必须是 HTTPS。

  • CRX 签名私钥不能提交到仓库。

  • 固定公钥后扩展 ID 才能保持不变。

总结

这类插件看起来只是“一键清缓存”,但真正要稳定,需要同时处理:

  • 当前站点 origin 限制。

  • Service Worker 反注册。

  • Cache Storage 删除。

  • sessionStorage 的 MAIN world 注入。

  • 清理后强制刷新。

  • 商店版和外部分发版的 manifest 差异。

做好之后,对调试线上缓存问题非常省时间。