联动帖子：
问题背景
前两天在使用油猴脚本 Pixiv Downloader 时，利用 File System Access API (FSA) 批量下载了约 2 万张图片。
后遗症：哪怕事后将图片全部移走/删除，并重启电脑，清除 Chrome 24 小时缓存数据，电脑依然出现了严重的性能问题：
- 运行时周期性顿卡，电脑每隔一段时间就会全局挂起 1-2 秒。
- 启动 Chrome 必现“未响应”，卡死数秒后才能进入界面。
排查过程
启动 Chrome 出现【未响应】 是最新出现的问题，是必现的，且顿卡多次在“切换浏览器标签页”时触发，怀疑是 Chrome 的锅。改用 Firefox，发现电脑再无此问题，得以确定。
遇到这类 I/O 阻塞型卡顿，常规思路往往会指向以下几个 Chrome 的缓存大户，但 经排查均被排除：
权限记录膨胀：Preferences文件仅 850KB，FSA API 仅请求了根目录句柄，未产生海量权限记录。- 下载历史阻塞：
History数据库仅 40MB，未发现超大downloads记录。 - 脚本数据库撑爆：
IndexedDB目录 180MB 且无对应站点数据，排除脚本将 2 万条元数据写入本地数据库导致的 V8 内存溢出。 - 系统级文件死锁：Windows 的
Recent及跳转列表均未发现死链导致 Shell32 寻址超时。 - 插件/扩展拥堵：禁用所有扩展后启动依然卡死，排除跨进程通信 (IPC) 日志残留。
破局点：交叉启动测试
为了精准定位，利用 Chrome 命令行参数进行了四组对照实验：
chrome.exe --user-data-dir="D:\chrome_temp_profile"（全新目录）：发现 Chrome 秒开。chrome.exe --guest（访客模式）：Chrome 长时间白屏。chrome.exe --disable-extensions --disable-background-networking --disable-sync --disable-component-update --no-experiments：最卡，Chrome 短暂出现【未响应】- 手动将原本的
Default文件夹塞入全新的chrome_temp_profile：秒开。
结论锁定：Default 目录（包含书签、密码、历史、扩展等核心数据）完全健康。问题 100% 潜伏在 User Data 根目录下。
怀疑：海量高频的 I/O 操作导致根目录下的某个全局系统状态文件（如网络行为预测、设备配额管理器或安全浏览队列）发生了结构性损坏或死锁。
无损修复方案
得益于 Chromium 的设计为高度解耦的微服务集合，它的 User Data 目录具有极强的容错与自愈能力（Self-healing）：如果它发现某个组件的数据文件/文件夹缺失，它不会崩溃，而是会认为该组件处于出厂状态，并自动生成一个干净的空文件或文件夹。
我们可以通过移花接木的方式，剥离毒瘤并完美保留所有个人数据。
Step 1：环境隔离与备份
- 彻底关闭所有
chrome.exe进程。 - 进入 Chrome 数据目录：
%LOCALAPPDATA%\Google\Chrome\。 - 将现有的
User Data文件夹重命名为User Data.bak（保留完整案发现场）。
Step 2：重建纯净根目录
- 新建一个空的
User Data文件夹。 - 将
User Data.bak中的Default文件夹（如果有多个账号，还包括Profile 1等）直接复制到新的User Data目录下。
Step 3：修复登录状态丢失（关键！）
由于 Chrome 的 Cookies 和密码使用了 DPAPI 加密，其 加密密钥（Seed） 存储在根目录的 Local State 文件中。新建根目录会导致密钥丢失，从而使网站登录状态全部失效。必须进行密钥移植：
- 从
User Data.bak中复制Local State文件，覆盖到新的User Data根目录下。 - 为防原有 Cookie 文件在刚才的失效启动中被覆写，从
User Data.bak\Default\Network\中复制Cookies及其 journal 文件，覆盖到新Default\Network\目录下。
结果
启动 Chrome。等待几分钟，浏览器自动重建了根目录下的全部缺失组件，彻底消除了 I/O 阻塞源。卡顿完全消失，启动恢复秒开，且所有书签、密码、插件以及网站登录状态 100% 无损保留。
总结与建议
- 慎用 FSA API 进行超大规模并发写入：浏览器的文件系统沙盒及全局配额监控机制在面对上万次瞬间 I/O 时，容易引发底层状态文件死锁。批量下载建议降级使用常规的
<a>标签或插件自带的下载管理器。 - 排错策略：遇到离奇的浏览器卡顿，善用
--user-data-dir建立对照组，配合.bak快照策略，可以实现安全、可回退的“外科手术”级修复。
感想
- 我的情况应该是某种 Edge Case，或者是高并发 IO 刚好和升级周期重叠，发生了竞态，导致底层文件损坏。
- Windows 应该对 Chrome 有特殊照顾，或者 Chrome 运行在比用户空间更底层的位面（类似于安全软件），它的 BUG 直接影响到其他软件的稳定性。
- 若 Chrome 发生 BUG，直接重建数据比起排查 BUG 更加省心。
- Chrome 很强，能带伤运行而不崩溃；但又没那么强，做不到完全自愈。