code --status是vscode性能诊断第一入口，可查看各子进程cpu/内存占用，重点排查extension host高占用及files.watcherexclude配置、语言服务器模式、远程/c++扩展异常。
code --status 是第一眼必须看的诊断入口
VSCode CPU 高不是编辑器“变慢”，而是某个后台进程在疯跑。直接运行 code --status，它会列出所有子进程（Extension Host、Renderer、Shared Process 等）及其 CPU% 和内存占用。重点关注 Extension Host 进程——如果它持续占 60%+，基本就是某个扩展在反复解析或监听文件。
常见错误现象：code --status 显示某 extension host 占高，但编辑器界面仍可操作。这说明问题不在主 UI 线程，而在扩展自己的 Node.js 子进程里。
- 记下高占用进程的 PID，用
ps -p [pid] -o comm=（macOS/Linux）或任务管理器（Windows）确认具体是哪个扩展启动的进程 - 别一上来就禁全部扩展；先定位 PID 对应的扩展名，再针对性处理
- 某些扩展（如
esbenp.prettier-vscode、ms-python.python）在打开含node_modules的项目时，会因监听范围太宽触发高频解析
files.watcherExclude 必须配，且通配符不能写错
VSCode 默认用 chokidar 监听整个工作区，一旦项目里有 node_modules、dist、.git 这类目录，inotify/fsevents 就会为每个文件变动发事件——几万个文件 = 每秒几十次扫描，CPU 直接拉满。
使用场景：你只是打开一个前端项目，没写代码、没保存、没搜索，CPU 却稳定在 70%+，八成是 watcher 在扫构建产物。
- 在
settings.json中加这几行："**/node_modules/**": true、"**/dist/**": true、"**/.git/**": true - 注意必须用双星号
**，写成*或*/node_modules/*无效 - Linux 用户需检查系统限制：
cat /proc/sys/fs/inotify/max_user_watches，若低于 524288，执行sudo sysctl fs.inotify.max_user_watches=524288并写入/etc/sysctl.conf
Python/TypeScript 语言服务器吃内存？换轻量模式
ms-python.python 和内置的 typescript-language-features 不是“慢”，是默认加载整个依赖树做类型推导。一个含 50+ Python 包的项目，Extension Host 内存常驻 1.2GB+；TS 项目里 node_modules/@types 一多，语言服务器直接吃光 2GB 内存。
性能影响明显：改配置后重启，CPU 占用常从 60%+ 掉到 5% 以内，首次打开文件的延迟也大幅下降。
- Python：把
python.languageServer从Pylance改为Jedi（Jedi 不做全量语义分析） - TypeScript：关掉自动导入提示：
typescript.preferences.includePackageJsonAutoImports设为off - 顺手关掉
editor.quickSuggestions中的strings和comments，减少语法分析压力
Remote-WSL/SSH 或 C++ 扩展异常要单独处理
远程开发场景下，本地 CPU 高往往不是本地 VSCode 的问题，而是远端 server 同步元数据卡住，或本地客户端反复重试通信。C++ 扩展（ms-vscode.cpptools）则容易因符号索引爆炸或二进制兼容问题，在 macOS/Linux 上拉起 microsoft.vscode.cpp.extension.darwin 进程长期占满单核。
容易被忽略的地方：这类问题不会出现在 code --status 的常规进程列表里，得去远端终端查 ps aux | grep code，或看扩展日志输出（命令面板 → Developer: Toggle Developer Tools → Console）。
- Remote-WSL：在远端执行
code --status，确认是否远端 server 进程异常；临时关掉remote.WSL.fileWatcherPolling - C++ 扩展：更新到最新版优先；若仍高，尝试在
settings.json加"C_Cpp.intelliSenseEngine": "Default"，避免启用旧版 Tag Parser - 不建议手动 patch
client.js或改二进制启动脚本——版本一升级就失效，且有安全风险
