文件图标加载慢不是显示问题，而是图标扩展（如material-icon-theme）对每个文件同步解析路径、读取package.json等文件内容导致i/o阻塞；需禁用动态逻辑、配准files.watcherexclude并清理workspacestorage缓存。
为什么文件图标加载慢不是“显示问题”，而是扩展在反复解析文件
VSCode 文件资源管理器里图标延迟出现、点击文件夹卡顿半秒、甚至图标干脆不显示——这通常不是渲染层的问题，而是某个图标主题扩展正在对每个文件执行同步读取或正则匹配。尤其是 material-icon-theme 这类功能丰富的主题，会在首次展开目录时遍历所有子路径，逐个检查 package.json、tsconfig.json、.gitignore 等文件内容来决定图标，大型项目下极易堆积 I/O 延迟。
- 常见错误现象：
Developer: Toggle Developer Tools→ Console 里持续刷出ENOTDIR或ENOENT报错；资源管理器展开某目录后 CPU 持续 30%+ 占用数秒 - 关键判断点：禁用所有扩展后图标秒出 → 问题锁定在图标/文件系统类扩展
- 不要只关
material-icon-theme，还要检查是否同时启用了vscode-icons、Project Manager（它会扫描所有.code-workspace）、GitLens（它的文件树增强逻辑也会触发额外 stat 调用）
files.watcherExclude 配错会让图标主题“白忙活”
很多用户以为配了 files.exclude 就够了，但图标主题不看这个——它依赖文件监视器（watcher）来感知目录结构变化，而 watcher 默认会监听所有子目录。如果 files.watcherExclude 没生效，图标主题每次展开都会重新扫描 node_modules、dist 下成千上万个路径，导致 UI 线程阻塞。
-
files.watcherExclude的 glob 必须以**/开头，且结尾推荐加/**（如"**/node_modules/**": true），写成"node_modules"或"**/node_modules"都不生效 - Linux/macOS 下 inotify 句柄耗尽时会出现
watcher limit reached错误，此时图标加载会彻底停滞，必须重启 VSCode 才能恢复 - 多根工作区中，每个根目录的
files.watcherExclude是独立生效的，不能只在最外层.vscode/settings.json里配一次
material-icon-theme 的高开销配置项必须关
material-icon-theme 默认开启多项动态检测逻辑，比如根据 package.json 的 type 字段切换 JS/TS 图标、扫描 .git 状态显示锁图标、识别 monorepo 工具链（pnpm/nx/lerna）自动染色。这些在小型项目无感，但在含 50+ 子包的 workspace 下会引发指数级路径检查。
- 关闭动态识别：
"material-icon-theme.activeIconPack": "none"（禁用所有基于内容的图标逻辑） - 停用 Git 状态图标：
"material-icon-theme.hidesExplorerArrows": true+"material-icon-theme.folders.color": "#888"（避免读取 .git/index） - 禁用语言专属图标包：
"material-icon-theme.languages.associations": {}（清空自定义映射，回归基础文件后缀匹配） - 如果只是要“快”，直接换轻量主题：
"workbench.iconTheme": "vs-minimal"—— 它不读任何文件，纯 CSS 控制，100% 零延迟
缓存残留会导致图标反复重载
VSCode 会把图标解析结果缓存在 workspaceStorage 目录下，但图标扩展升级或配置变更后，旧缓存不会自动失效。你改了 files.watcherExclude，可图标主题仍坚持去扫已排除的目录，大概率是缓存没刷新。
- 必须退出 VSCode（包括托盘进程），然后删除对应工作区的
workspaceStorage/{guid}/file-icons子目录（Windows 在%APPDATA%\Code\WorkspaceStorage，macOS 在~/Library/Application Support/Code/WorkspaceStorage） - 别删整个
workspaceStorage，否则符号索引、搜索历史全丢，得重新建库 - 重启后首次加载仍稍慢（重建缓存），但后续就稳定了；如果还是慢，说明有扩展绕过了
files.watcherExclude自行调用fs.stat
