VSCode索引卡顿主因是文件监听器超限，需同时配置files.watcherExclude和search.exclude，并调高inotify限制、禁用符号链接搜索、清理workspaceStorage等缓存。
VSCode打开项目卡在“正在建立索引”是文件监听器被撑爆了
不是项目太大，而是 VS Code 默认对 node_modules、.git、dist 这类目录照单全收，为每个文件注册 inotify 监听器——Linux/macOS 有句柄数限制，Windows 有 NTFS 事件队列瓶颈，一旦超限，索引就卡死不动，CPU 占用飙高但无实际进度。
验证方法：打开开发者工具（Developer: Toggle Developer Tools），切到 Performance 标签页录一段操作，看主线程是否长期被 watcher 或 tsserver 阻塞；或终端执行 ps aux | grep tsserver，发现进程频繁重启也是典型信号。
- 必须同时配置
files.watcherExclude和search.exclude，前者防监听注册，后者防搜索读取，只配一个等于白配 -
"**/node_modules/**"中的结尾/**不可省略，写成"node_modules"或"**/node_modules"会失效 - Linux 用户务必检查：
cat /proc/sys/fs/inotify/max_user_watches，若低于524288，运行echo 524288 | sudo tee /proc/sys/fs/inotify/max_user_watches
哪些路径必须加进 files.watcherExclude
别只抄 node_modules 和 dist，真实项目里这些才是高频“监听炸弹”：
-
"**/node_modules/**"：含嵌套 monorepo 的packages/*/node_modules -
"**/.git/**"：GitLens 等插件会反复扫描 Git 状态，大历史仓库尤其吃资源 -
"**/target/**"（Rust/Java）、"**/.next/**"（Next.js）、"**/out/**"（TSoutDir） -
"**/*.log"：单个 200MB 的日志文件就能让 watcher 队列卡住数秒 - 如果你有
.gitignore，建议把里面所有非空行路径转成files.watcherExclude条目——避免 Git 插件和搜索插件各自重复扫同一堆垃圾
search.followSymlinks: false 是 monorepo 开发者的救命开关
在用 yarn link 或 npm link 的项目里，符号链接常指向外部 node_modules 或 packages 目录。默认 search.followSymlinks: true 会让 VS Code 顺着链接一路扫进去，瞬间多出几千个文件要读，索引直接卡死。
设为 false 后，搜索只停在链接文件本身，不穿透。它不影响代码跳转（Go to Definition），只管全局搜索（Ctrl+Shift+F）和快速打开（Ctrl+P）。
- 配合
search.exclude使用更稳，例如："**/packages/**": true+"search.followSymlinks": false - 如果临时需要穿透搜索，可在搜索面板右下角点
!图标临时关闭排除规则，搜完再关回去
删缓存比调设置更快见效，但得删对地方
VS Code 缓存堆积后，workspaceStorage 里会存大量损坏或过期的索引快照，导致每次打开都重跑失败流程。清理比反复调参数更立竿见影。
- 必须完全退出 VS Code（包括托盘进程），否则部分缓存文件被占用删不掉
- 重点清理三个目录：
Cache（HTTP 响应、Marketplace 数据）、CachedData（语法高亮 token）、workspaceStorage（每个工作区一个 GUID 目录，含搜索索引） - Windows 路径：
%APPDATA%\Code\Cache、%APPDATA%\Code\CachedData、%APPDATA%\Code\User\workspaceStorage - macOS/Linux 路径：
~/.cache/Code、~/.config/Code/CachedData、~/.config/Code/WorkspaceStorage - 删完重启，首次打开略慢（重建缓存），但后续加载明显提速
真正容易被忽略的是：workspaceStorage 下每个子目录对应一个打开过的工作区，哪怕你已关闭该文件夹，它的索引缓存仍常驻磁盘并持续拖慢新项目启动——这个细节几乎没人主动清理。
