根本原因是 linux 内核 inotify 限制过低，执行 cat /proc/sys/fs/inotify/max_user_watches 若≤65536且 vscode 卡在“loading…”或 inotifywait 报 no space left on device，即可确认；临时修复用 sudo sysctl -w fs.inotify.max_user_watches=524288 并彻底重启 vscode；永久生效需 echo "fs.inotify.max_user_watches = 524288" | sudo tee -a /etc/sysctl.conf && sudo sysctl -p。
直接改 fs.inotify.max_user_watches 就行，不是 VSCode 的 bug，也不是项目配置问题，纯属 Linux 内核默认限制太低，尤其在含 node_modules 的前端项目里几秒就打满。
怎么看是不是这个原因？
终端执行：cat /proc/sys/fs/inotify/max_user_watches。如果输出 ≤ 65536，且同时出现以下任意现象，基本锁定：
- VSCode 状态栏卡在 “Loading…”
- 左下角弹出
Failed to watch workspace - 终端运行
inotifywait -m -r .报错No space left on device -
code --status显示大量watcher::create failed
注意：ENOSPC 这里和磁盘空间无关，是 inotify 句柄池耗尽。
临时生效：快速验证+应急
执行命令立即提升限制（需 root）：sudo sysctl -w fs.inotify.max_user_watches=524288
然后必须完全退出 VSCode（关掉所有窗口，不只是 Reload Window），再重新打开。如果问题消失，说明定位准确。
- 该设置重启系统后失效，仅用于验证或临时救急
- 别设太高（比如 200 万），
524288 ≈ 512MB内核内存已足够覆盖绝大多数项目 - 用
cat /proc/sys/fs/inotify/max_user_watches确认值已更新
永久生效：写入 sysctl.conf 并加载
执行两步（推荐用 tee 避免权限问题）：
echo "fs.inotify.max_user_watches = 524288" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
- 不要用
/etc/sysctl.d/子目录方式，部分发行版（如某些 Ubuntu 衍生版）的sysctl -p默认不递归加载，容易漏掉 - 检查命令输出是否含
fs.inotify.max_user_watches = 524288，否则可能是sysctl.conf中有空格或引号语法错误 - 不需要重启系统，但 VSCode 必须完全重启才能读取新值
顺手检查另外两个相关参数（容易被忽略）
虽然 max_user_watches 是主因，但大型项目并发监听多时，max_user_instances 和 max_queued_events 也可能成为瓶颈：
查看当前值：cat /proc/sys/fs/inotify/max_user_instances 和 cat /proc/sys/fs/inotify/max_queued_events
- 若
max_user_instances≤ 128，建议一并调高：在/etc/sysctl.conf中追加fs.inotify.max_user_instances = 512 -
max_queued_events默认 16384，一般够用；若频繁丢事件（比如保存后没触发 ESLint），可提到 65536 - 改完同样要执行
sudo sysctl -p加载
真正麻烦的不是改哪一行，而是改完忘了彻底重启 VSCode——它不会自动感知内核参数变化，必须杀进程重起。
