code --status是定位VSCode卡顿根源的真相入口，可查看各子进程PID及实时CPU%，结合ps命令定位高负载扩展；需正确配置files.watcherExclude、调高inotify限制、用二分法排查扩展，并精细调整语言服务器设置。
直接看 code --status 定位真实罪魁祸首
VSCode 界面卡不卡，和 CPU 高不高是两回事。code --status 才是真相入口——它会列出所有子进程（Extension Host、Renderer、Shared Process、Code Helper (Plugin)）的 PID 和实时 CPU%。别信活动监视器里一堆 “Code Helper”，得看哪个 PID 对应的 CPU 持续 >70%，再用 ps -p [PID] -o comm= 查它实际在跑什么扩展或服务。
常见误判：看到 Code Helper (Plugin) 占 95%，就以为是 VSCode 自身问题。其实它只是个壳，背后大概率是某个扩展的 Node.js 子进程在疯狂解析、监听或类型检查。
- 如果
Extension Host高负载，重点查 ESLint、Prettier、GitLens、TypeScript 或 Python 扩展 - 如果
Shared Process高负载，先关掉"telemetry.telemetryLevel": "off"和同步设置 - 如果多个
Code Helper (Plugin)并发高，大概率是文件监听爆炸，跳到下一条
files.watcherExclude 必须配，且通配符不能写错
VSCode 默认用 chokidar 监听整个工作区，一旦项目含 node_modules、dist、.git/objects，每次文件变动都会触发成百上千个事件，Code Helper 就在后台不停 fork 子进程处理，CPU 直接拉满。
正确配置只生效于双星号 ** 语法，写成 */node_modules/* 或 node_modules 都无效：
"files.watcherExclude": {
"**/node_modules/**": true,
"**/dist/**": true,
"**/.git/objects/**": true,
"**/.git/subtree-cache/**": true,
"**/tmp/**": true,
"**/bower_components/**": true
}
Linux/macOS 用户还要检查内核限制：fs.inotify.max_user_watches 过低会导致 watcher 静默失败并反复重试，用 sudo sysctl fs.inotify.max_user_watches=524288 临时调高。
用二分法禁用扩展比手动猜快得多
别一个一个禁用——VSCode 内置了扩展二分排查：Ctrl+Shift+X → 右上角 ⋯ → Bisect Extensions。它会自动禁用一半扩展、重启窗口、让你判断 CPU 是否回落；几轮下来就能把问题缩到单个扩展，比如 ms-python.python 在含 50+ 包的项目里常因全量语义分析拖垮 CPU，或 esbenp.prettier-vscode 在保存时触发嵌套格式化死循环。
注意：某些扩展（如 MarsCode、Cursor 插件）会在后台持续拉取模型或运行 LSP，即使没编辑也在耗资源，这类要优先怀疑。
别忽略语言服务器自身的配置粒度
TypeScript 和 Python 的语言服务不是“开/关”二选一，它们有精细的控制开关。比如 TypeScript 默认会扫描 node_modules/@types 全量类型定义，一个大型项目可能加载上万文件进内存：
- 加
"typescript.preferences.includePackageJsonAutoImports": "auto"减少自动导入推导 - 对 Python，设
"python.languageServer": "Pylance"+"python.analysis.extraPaths": []避免无意义路径扫描 - 禁用非必要功能：
"editor.suggest.snippetsPreventQuickSuggestions": true能降低补全时的瞬时 CPU 峰值
真正难搞的是那些“看起来没在干活却一直占着 CPU”的情况——往往是因为某扩展注册了全局文件监听器，但没做路径过滤，连你桌面截图保存到 Downloads 目录都能触发它的回调。这种必须靠 Developer: Start Performance Recording 抓火焰图才能看清调用栈源头。
