Google Chrome 浏览器再次出现了一个 bug，Jeff Johnson（来自 Lapcat Software）在 2026 年 9 月 5 日发布的测试中发现，即使用户启用了"关闭所有窗口时删除已保存到设备上的站点数据"设置，chrome.com 的站点数据仍会被保留。这个问题与 2020 年发生过的 bug 非常相似，后者在 Johnson 报告后得到了修复。

Chrome settings showing site data deletion options for google.com with Delete site data and permissions button selected
Chrome's site data settings for google.com demonstrating the "Delete site data and permissions" configuration optionlapcatsoftware.com

Jeff Johnson documented the exact Chrome setting he tested - the 'Delete site data and permissions for www.google.com and its installed app' checkbox was enabled at chrome://settings/content/siteData, showing the configuration intended to prevent persistence

Chrome site data management interface showing detailed storage information for google.com and other sites
Detailed site data management view in Chrome showing on-device storage usage, with google.com listed among other tracked siteslapcatsoftware.com

This interface view illustrates how Chrome tracks and displays site storage information, providing the context for understanding the persistent 1,216 KB of google.com data despite deletion attempts

Chrome browser showing DuckDuckGo as default search engine with Google search results page
Browser interface screenshot showing DuckDuckGo as default search engine and Google search execution for testing purposeslapcatsoftware.com

Johnson configured DuckDuckGo as the default search engine in Chrome to eliminate search-engine-related variables from the test, setting up the controlled environment for reproducing the site data persistence bug

Johnson 测试了 Chrome 152.0.7977.83 版本，在两台 Mac 上启用了 chrome://settings/content/siteData 中的"关闭所有窗口时删除已保存到设备上的站点数据"设置。他没有登录 Chrome 帐户，并将默认搜索引擎改为 DuckDuckGo，以排除搜索引擎相关的影响。执行了一次 Google 搜索后关闭唯一的 Chrome 窗口，他发现 chrome.com 的站点数据（包括 cookies、local storage 和 session storage）仍然保留在了 ~/Library/Application Support/Google/Chrome/Default 中，即使重启 Chrome 后这些数据仍然存在。这种行为在删除数据后重新测试时反复出现。

问题的根源是 Chrome 的 Compression Dictionary Transport 功能，这是一个 Chromium 特有的 Web 技术。正如 Johnson 在 9 月 16 日补充中提到的，他引用了一份由第三方提交的 Chromium 公开 bug 报告："bug 的原因是 Compression Dictionary Transport...google.com 是该技术的早期采用者。"该功能创建的共享字典是额外的存储，Chrome 在关闭浏览器时无法正确清理掉它。正如一名 Chromium 贡献者在当前的 Hacker News 讨论中确认的："不仅仅是 google.com，使用 Compression Dictionary Transport 的任何网站都会遇到这个问题...共享字典是该功能中新增的存储，但并没有正确地在关闭时清除。一个修复方案正在开发中。"

Chrome site data storage showing 1,216 KB of usage for google.com after window close test
Site data storage output from Chrome 152.0.7977.83 showing 1,216 KB of google.com data persisted despite window close settinglapcatsoftware.com

The screenshot captured in Johnson's test shows the actual storage amount after closing the Chrome window with site data deletion enabled, demonstrating the bug's effect with 1,216 KB of google.com data remaining

Chrome site data storage interface showing zero bytes usage before test was run
Initial site data storage showing 0 B usage before performing search and window close test, establishing baseline for comparisonlapcatsoftware.com

The screenshot from Johnson's test setup shows the initial state of site data storage (0 B) before the search and browser close operation, providing the baseline for comparison with the persisted 1,216 KB after the bug occurred

这与 2020 年发生的一个 bug 非常相似，当时 Chrome 免除了 Google 旗下 Search 和 YouTube 站点的数据删除设置。那个 bug 最终被追踪到了一个 Chromium 提交，并在 Chrome 86 版本中部分修复了 youtube.com 的问题，但 google.com 仍然存在这个问题。当前的问题源自于一个新的压缩功能，而不是同样的代码路径。

Johnson 强调，这个 bug 的再次发生反映了质量保证方面的不足，尽管 Google 拥有大量资源。这个 Compression Dictionary Transport 解释意味着 exemption 不仅限于 Google 旗下产品——任何采用该技术的网站都会出现同样的问题，但 google.com 的早期采用使其成为第一个被观测到的案例。Chromium 项目中已经在开发一个修复方案，来解决这个问题。