是插件抢走了inotify句柄。VSCode文件监视器与fs.watch共享inotify资源，插件如GitLens、Python等大量监听路径会耗尽max_user_watches，导致“无法监视文件更改”，可通过code --disable-extensions验证并用--disable-extension逐个排查。
确认是否是插件抢走了 inotify 句柄
VSCode 自身的文件监视器（files.watcherExclude 控制）和你代码里调用的 fs.watch 共享同一套系统 inotify 资源。一旦某个插件在后台悄悄监听了大量路径（比如 GitLens 监控整个工作区、Project Manager 扫描多根目录、旧版 Python 插件 spawn 的 pylance 语言服务器），就会快速耗尽 /proc/sys/fs/inotify/max_user_watches。此时 VSCode 状态栏会显示「无法监视文件更改」，且 lsof | grep 'VSCode' | grep inotify | wc -l 返回值接近或等于系统上限。
- 运行
cat /proc/sys/fs/inotify/max_user_watches，若 ≤ 16384，基本可判定是瓶颈源头 - 打开命令面板，执行
Developer: Open Extension Host Log，搜索watch或inotify，看是否有插件反复报ENOSPC或EMFILE - 检查插件是否显式调用
fs.watch：比如某些 SFTP、Sync 插件会在连接时递归监听远程映射路径，这类行为不会出现在 UI 提示里，只藏在日志末尾
用 code --disable-extensions 快速验证
这不是“禁用全部扩展”按钮，而是真正跳过所有插件加载流程的硬隔离方式——它不读 settings.json、不解析 .vscode/extensions.json、不触发任何 activate() 函数。只有这个命令能排除“插件在启动早期就注入并抢占句柄”的情况。
- 关闭所有 VSCode 窗口，终端执行：
code --disable-extensions /path/to/your/project - 观察右下角是否还弹出「无法监视文件更改」；若消失，说明确实是插件导致
- 不要用图形界面点“禁用全部”，那个操作对已崩溃的插件无效，尤其当错误发生在
Extension host terminated unexpectedly阶段时
精准定位高危插件的命令行策略
一旦确认是插件问题，别靠手动开关试错。直接用 --disable-extension 参数逐个排除，尤其适合连插件面板都打不开的场景。
- 优先测试近期更新或已知高监控负载的插件：
code --disable-extension ms-python.python、code --disable-extension esbenp.prettier-vscode - 一次禁用多个更高效：
code --disable-extension bradlc.vscode-tailwindcss --disable-extension dbaeumer.vscode-eslint - 注意：
--disable-extension只对本次启动生效，不影响插件本身安装状态 - 若禁用后仍失效，打开任务管理器筛选
exthost进程，观察哪个插件启用后 CPU / 内存突增或进程异常退出
绕过插件干扰的临时开发配置
有些插件（如旧版 Python、SFTP）会在启动时尝试 spawn 外部进程，而路径含空格、中文或权限不足会导致静默失败——这种错误不会出现在 UI 提示里，只藏在 exthost 日志末尾。与其等它崩，不如提前降级。
- 在工作区
.vscode/settings.json中添加："files.watcherExclude": { "**/node_modules/**": true, "**/dist/**": true }，强制避开最耗句柄的目录 - 脚本中加判断：
if (process.env.VSCODE_PID) { /* 切换为 fs.watchFile 轮询 */ }，避免和 VSCode 共争 inotify - 远程开发（WSL）用户必须同步调整 WSL2 内核参数：
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
真实麻烦的不是插件数量，而是某些插件在启动瞬间就占满句柄却不释放——它们甚至没来得及写入日志，就已经把 inotify 池子抽干了。
