VSCode文件变动后不更新，主因是插件争抢监听权及inotify配额耗尽；需启用files.useExperimentalFileWatcher并调高fs.inotify.max_user_watches至524288，重启VSCode生效。
VSCode 文件变动后不更新，90% 不是 Live Server 或浏览器的问题，而是多个插件在争抢文件监听权——比如 Live Server、ESLint、Prettier、Auto Rename Tag 都可能悄悄注册自己的文件 watcher，结果互相干扰或被系统限流，最终表现为“改了 HTML，页面不动”“保存后 Git 状态没刷新”“外部脚本生成文件，VSCode 根本看不见”。
为什么 files.useExperimentalFileWatcher 必须开
VSCode 默认用系统 inotify 监听文件，但在 WSL、Docker、大型 node_modules 工作区下极易失效（尤其 Linux 上 fs.inotify.max_user_watches 被耗尽时）。此时即使插件没冲突，监听也会静默挂掉。
- 必须手动开启
files.useExperimentalFileWatcher：它会 fallback 到轮询 + inotify 混合策略，绕过内核限制 - 该设置需重启 VSCode 才生效，热重载无效
- VSCode 1.84+ 默认启用，但企业策略或旧版可能关闭；检查方法：打开
settings.json，确认存在"files.useExperimentalFileWatcher": true - 开启后 CPU 占用略升，但对现代机器影响可忽略；若你用的是 WSL2 或 Docker Desktop，这步跳过等于白调
Live Server 和其它插件共存时的 reload 冲突
Live Server 自带 reload 机制，但如果 ESLint、Prettier 或 EditorConfig 也配置了 onSave 触发动作，它们可能在文件写入中途介入，导致 Live Server 拿到的是中间态内容，从而跳过刷新或触发失败。
- 确保
Live Server是唯一启用reload的插件：在settings.json中显式设"liveServer.settings.reload": true，并关掉其他插件的自动保存类行为 - 禁用 ESLint 的 onSave 格式化：
"eslint.format.enable": false，只保留校验（"eslint.run": "onType"） - 避免
Auto Close Tag和Auto Rename Tag同时启用——它们会在输入时高频修改 DOM 结构，干扰 Live Server 对 HTML 变更的判断 - 若仍不刷新，临时禁用所有非必要插件，只留
Live Server+@vscode/typescript-language-features测试基础链路
Linux/macOS 下 inotify 耗尽的真实表现与修复
右下角弹出“无法在这个大型工作区中监视文件更改”，不是警告，是确诊书——说明系统 inotify 配额已被插件们瓜分完。此时哪怕只开一个插件，也可能因配额不足而监听失败。
- 运行
cat /proc/sys/fs/inotify/max_user_watches查当前上限（常见值为 8192） - 前端项目含 node_modules 时，实际需求数常超 50000；临时提高：执行
sudo sysctl fs.inotify.max_user_watches=524288 - 永久生效：向
/etc/sysctl.conf追加fs.inotify.max_user_watches=524288，再运行sudo sysctl -p - 注意：某些插件（如旧版
ms-python.python）即使被禁用，仍会在启动阶段预占大量 watches，删掉对应目录更彻底：rm -rf ~/.vscode/extensions/ms-python.python-*
真正难处理的不是“哪个插件坏了”，而是多个插件在底层共享同一套文件事件通道却互不知情——它们各自注册监听、各自触发 reload、各自清理缓存，最后谁先写完谁说了算。所以排查时别只盯着功能开关，得看谁在抢 fs.watch、谁在改 stat 时间戳、谁在往 inotify 实例里塞路径。这些细节藏在 Developer Tools 的 Console 和 Extension Host 日志里，不是设置里能点出来的。
