根本原因在于linux内核inotify的fs.inotify.max_user_watches值过小，导致vscode无法创建文件监听器，即使配置files.watcherexclude也无效；需通过sysctl临时或永久调高max_user_watches及其他相关参数。
根本不是 VSCode 配置问题，而是 Linux 内核 inotify 的 fs.inotify.max_user_watches 打满了 —— 直接调它，别折腾 launch.json 或插件。
为什么改了 files.watcherExclude 还报 Failed to watch
因为 VSCode（以及底层的 chokidar）在启动时仍会递归扫描工作区根目录，哪怕你写了 "**/node_modules/**": true，只要内核 watch 资源池已空，连排除逻辑都来不及执行就会失败。典型表现是：code --status 里大量 watcher::create 失败，终端 inotifywait -m -r . 报 No space left on device。
- 必须先确认当前限制：
cat /proc/sys/fs/inotify/max_user_watches，若 ≤ 16384，基本就是它 -
files.watcherExclude是“事后过滤”，max_user_watches是“事前配额”——配额没了，过滤根本没机会跑 - 写错通配符（比如用
/node_modules/或node_modules）会导致排除失效，但不会阻止 watch 创建，所以仍会爆限
临时提升：一行命令验证是否真根于此
不用重启系统，不用改配置文件，快速验证：
- 执行：
sudo sysctl -w fs.inotify.max_user_watches=524288 - 再运行：
sudo sysctl -p（确保内核重载参数） - 必须完全退出 VSCode 所有窗口（不只是 reload window），再重新打开工作区
- 验证是否生效：
cat /proc/sys/fs/inotify/max_user_watches输出应为524288
注意：该值重启后恢复默认（通常是 8192），仅用于快速定位或临时应急；设太高（如 200 万）会吃掉约 2GB 内核内存，不推荐。
永久生效：写进 /etc/sysctl.conf 而非 sysctl.d
部分发行版（如某些 Ubuntu 衍生版）的 sysctl -p 默认不递归加载 /etc/sysctl.d/ 下的文件，容易漏掉配置。
- 执行：
echo "fs.inotify.max_user_watches = 524288" | sudo tee -a /etc/sysctl.conf - 再执行：
sudo sysctl -p - 检查输出是否含
fs.inotify.max_user_watches = 524288；若没有，说明/etc/sysctl.conf有语法错误（比如多了空格、引号或换行） - 无需重启系统，但 VSCode 必须完全重启才能应用新限制
别只盯着 max_user_watches，顺手检查另外两个参数
虽然 max_user_watches 是主因，但在高事件密度场景（比如热重载 + 同时保存多个文件），以下两个参数也可能成为瓶颈：
-
fs.inotify.max_user_instances：单用户可创建的 inotify 实例数，默认常为 128；VSCode + Webpack + Vite 同时监听，很容易打满；建议设为512 -
fs.inotify.max_queued_events：事件队列长度，默认常为 16384；事件爆发时（如git pull后大量文件变更），队列溢出会导致丢事件；建议设为65536 - 检查方式同上：
cat /proc/sys/fs/inotify/max_user_instances和cat /proc/sys/fs/inotify/max_queued_events
它们的修改方式和 max_user_watches 完全一致，也需加到 /etc/sysctl.conf 并 sudo sysctl -p 加载。
