先禁用高危插件（如GitLens、ESLint、Prettier、Python），再配置files.watcherExclude排除node_modules等目录，最后彻底退出VS Code并验证句柄数是否下降。
怎么看哪个插件在疯狂申请 inotify 句柄
Windows 上没有 inotify，但 VS Code 用的是底层文件监视库 chokidar，它在 Windows 会退化为轮询（polling）或使用 ReadDirectoryChangesW，一旦监听目录过多、过深，句柄数和 CPU 就会飙升——现象是系统资源监视器里 Code Helper (Renderer) 或 Extension Host 进程句柄数轻松破 5000，且不随关闭文件下降。
直接查：按 Ctrl+Shift+P，运行 Developer: Show Running Extensions，重点看 Activation Events 列含 onStartup、* 或 onFileSystem 的插件；再配合 Developer: Open Process Explorer，点开 Extension Host 子进程，看是否有持续 >300MB RSS + 高句柄数的子线程。
-
eamodio.gitlens默认开启全仓库 blame 和图谱扫描，对.git目录高频轮询 -
dbaeumer.vscode-eslint若配置了"eslint.probe": ["*"]，会递归扫描所有子目录找配置文件 -
esbenp.prettier-vscode在未配.prettierignore时，保存即遍历整个工作区找可格式化文件 -
ms-python.python启用 Pylance 后，会主动监听venv、site-packages下的变更
禁用必须分清作用域，否则白操作
右键插件点 “Disable” 默认是全局禁用，但很多插件（尤其是 GitLens、ESLint）注册了 workspace 级激活事件，只禁全局根本没用——它仍会在你打开任意文件夹时自动加载。
正确做法是：在扩展面板里找到目标插件 → 点击右下角齿轮图标 → 选 Disable (For All Folders)（不是“Disable”或“Disable (Workspace)”）；若插件已显示灰色但进程仍在，说明它被工作区级配置复活了。
- 检查项目根目录下的
.vscode/settings.json，删掉类似"extensions.enabled": { "eamodio.gitlens": true }这类显式启用项 - 检查用户级
settings.json（%APPDATA%\Code\User\settings.json），确认没写"extensions.autoEnable": true或残留的gitlens.*开关 - 禁用后必须彻底退出 VS Code：任务栏右键图标 → “退出”，不能只关窗口；否则旧 Extension Host 进程锁着句柄不释放
files.watcherExclude 不配等于没禁插件
即使禁掉了所有高危插件，只要没配 files.watcherExclude，VS Code 仍会默认监听 node_modules、dist、.git 等目录——Windows 上这会导致 chokidar 启动大量轮询线程，句柄数指数级增长，CPU 持续 30%+。
Windows 命令行编码与兼容规范。涵盖 GBK/UTF-8 编码、PowerShell/pwsh 互操作、Python/Node.js、Git 配置及代码生成规则。适用于 Windows 10/11 + MSYS2/Git Bash 环境下的所有命令行操作。
必须在项目级 .vscode/settings.json 中添加（注意 JSON 格式合法，末尾无逗号）：
{
"files.watcherExclude": {
"**/node_modules/**": true,
"**/dist/**": true,
"**/build/**": true,
"**/.git/**": true,
"**/coverage/**": true
}
}
- 别写成
"**/node_modules/*"—— 缺少末尾/**就不生效 - 别在用户级 settings 里配——它只对当前工作区有效，不同项目要各自配
- 配完后重启 VS Code，再跑
code --status，观察输出中watcher行是否明显变短
验证句柄是否真降下来了
禁用 + 配置完别急着关命令面板，先用系统工具确认效果。Windows 上最准的方式是打开任务管理器 → “详细信息”页 → 右键列标题 → “选择列” → 勾选 “句柄数”。找到 Code Helper (Renderer).exe 和 Code.exe（主进程），对比禁用前后句柄数变化。
- 正常工作状态：主进程句柄
- 如果句柄没降，大概率是某个插件没真正退出：打开 PowerShell，执行
Get-Process | Where-Object {$_.ProcessName -like "*code*"} | Select-Object Name,Id,HandleCount，看有没有残留的Code HelperPID - 残留进程手动杀：记下 PID，执行
Stop-Process -Id XXXX -Force，再重开 VS Code
句柄泄漏最隐蔽的地方不在插件本身，而在它触发的监听行为是否被 files.watcherExclude 拦住——配错一行路径，前面所有禁用都白做。
