根本原因是VSCode默认递归扫描工作区时被node_modules、符号链接或权限受限路径阻塞，需同时配置files.exclude和files.watcherExclude，并禁用GitLens等监听型扩展。
为什么资源管理器卡在“正在加载…”
根本原因是 VSCode 默认对整个工作区递归扫描，遇到 node_modules、dist、符号链接挂载点或权限受限目录时，会阻塞文件树渲染。这不是插件问题，而是底层文件监视器（chokidar）被拖住——尤其在 Linux/macOS 上触发 ENOSPC 或 watcher limit reached 报错后，资源管理器直接无响应。
files.exclude 和 files.watcherExclude 必须同时配
files.exclude 只控制左侧资源管理器是否显示路径；files.watcherExclude 才真正阻止文件系统监听。两者缺一都会卡。
-
files.exclude的 glob 必须写成"**/node_modules/**": true，写成"node_modules"或"**/node_modules"都不生效 -
files.watcherExclude同样要求**/开头，且必须包含/**结尾（如"**/build/**": true），否则 inotify 仍会监听该目录下所有子文件 - 多根工作区下，每个子文件夹需单独配置，根目录的设置不会继承
- Windows 对大小写不敏感，但 macOS/Linux 敏感，
"**/Build/**"在 Linux 下无法排除build/
哪些扩展会偷偷拖慢目录树
GitLens、Path Intellisense、Auto Rename Tag 这类插件默认全量扫描工作区，它们绕过 files.watcherExclude 自行调用 fs.watch，一个就能让 CPU 持续占用 20%+。
- 打开命令面板，运行
Extensions: Show Enabled Extensions，重点关掉带 “file”、“watch”、“scan” 关键词的扩展 - GitLens 可保留，但务必在设置里加
"gitlens.advanced.fileWatcher.latency": 1000 - Prettier、ESLint 等只在保存/编辑时触发的插件相对安全，但 ESLint 若配置了
lintOnFly且未限制目录，也会持续扫描 - 验证方式：打开开发者工具（
Help → Toggle Developer Tools），切到 Console，看是否有EACCES、EMFILE或大量watcher相关报错
符号链接和挂载点是隐形杀手
VSCode 遇到指向 NAS、Docker volume、已卸载设备或权限不足的软链时，会卡在遍历阶段，且不报错，只表现为资源管理器空白或长时间“正在加载…”。
- 临时移除工作区根目录下的可疑符号链接，再执行
Developer: Reload Window - 检查
python.defaultInterpreterPath是否指向损坏的虚拟环境——Pylance 会因此反复尝试扫描，拖慢初始化 - 如果项目含 Lerna/Yarn Workspaces，额外加
"**/packages/**/node_modules/**": true到files.watcherExclude
真正卡住目录树的往往不是代码量，而是没被意识到的监听范围和扩展行为。配对排除规则 + 关掉监听型插件 + 清理符号链接，三者齐备才能让资源管理器秒开。
