VSCode CPU 占用 100% 的根源是后台进程异常，需先运行 code --status 定位高占用的 Extension Host、cpptools-srv 或语言服务器等进程，再结合 files.watcherExclude 排除 node_modules 等目录、降级语言服务（如 Python 改用 Jedi）、关闭遥测与自动刷新等逐项优化。
VSCode 运行代码时 CPU 占用 100%，不是 VSCode 本身“太重”，而是某个后台进程在持续满载——大概率是 Extension Host、cpptools-srv、code-helper 或某个语言服务器（如 Pylance、typescript-language-features）在疯狂解析、监听或索引。直接看 code --status 就能定位真凶，不用猜。
用 code --status 快速定位高 CPU 进程
这是最省时间的第一步，比禁用扩展、改设置都靠前。它不依赖 UI 响应，直接读取底层进程状态。
- 终端执行
code --status，输出里重点关注Extension Host、Renderer、Shared Process和带cpptools、pylance、tsserver字样的进程 - 若某进程 CPU% 长期 >70%，记下它的 PID；再用
ps -p [PID] -o comm=（macOS/Linux）确认实际命令名，比如node /path/to/pylance -
Shared Process占高，大概率是遥测、同步或自动更新在后台轮询，可临时加"telemetry.telemetryLevel": "off"验证 - 别跳过这步：有些问题（如通义灵码后台索引）在 UI 里完全没提示，但
code --status会明确显示lingma-server进程占 95% CPU
files.watcherExclude 必须配，否则监听器会扫爆 CPU
VSCode 默认用 chokidar 监听整个工作区，一旦打开含 node_modules 的目录，几万个文件变动事件就会让 Node.js 子进程持续 100% 跑。
- 在
settings.json中加这几行（注意双星号**是必须的，*无效）："files.watcherExclude": { "**/node_modules/**": true, "**/dist/**": true, "**/build/**": true, "**/.git/**": true, "**/*.log": true } - Linux 用户如果发现监听静默失败（CPU 不高但文件变更不触发），检查系统限制：
cat /proc/sys/fs/inotify/max_user_watches，低于 524288 就要调高 - 这个配置只影响文件变更监听，不影响搜索；
search.exclude是另一回事，顺手也加上能减轻 I/O 压力 - 别把整个用户目录或磁盘根目录当工作区打开——只打开真正要编辑的子文件夹，这是最彻底的规避方式
语言服务降级：关掉全量类型分析
TypeScript 和 Python 的语言服务器默认做深度语义分析，对中大型项目等于把整个 node_modules/@types 或所有依赖包加载进内存，不是慢，是根本没打算轻量。
- TypeScript：关掉自动导入提示，避免每次保存都扫描
package.json："typescript.preferences.includePackageJsonAutoImports": "off" - Python：把
python.languageServer从Pylance改成Jedi，内存常驻从 1.2GB+ 降到 300MB 左右；改完后必须执行Python: Restart Language Server - C++：如果
cpptools持续占高，除了用cpulimit限频，更治本的是在c_cpp_properties.json中精简includePath，去掉冗余系统路径 - 通义灵码类插件：在项目根目录建
.tongyiignore（格式同.gitignore），排除node_modules、vendor等，改完手动杀掉lingma-server进程生效
别忽略渲染与通信层的隐性开销
很多卡顿不是逻辑层问题，而是 Electron 渲染或远程同步机制在拖后腿，尤其在 M 系列 Mac 或外接显示器场景下。
- 启动时加
--enable-gpu强制启用 GPU 加速：code --enable-gpu --disable-gpu-sandbox；若仍卡，再关掉editor.smoothScrolling和workbench.editor.enablePreview - 用 Remote-SSH/WSL 时，本地 CPU 高往往是因为远端
code-server进程异常或网络抖动导致元数据同步卡死；远端执行ps aux | grep code看是否有残留进程 - 禁用
git.autorefresh，尤其在有大量未提交变更的仓库里，每秒轮询 Git 状态很吃资源 - 终端缓冲区默认存 10000 行，设为
"terminal.integrated.persistentSessionScrollback": 1000可明显降低内存压力
真正难排查的不是配置项本身，而是多个因素叠加：比如 files.watcherExclude 漏了 dist，同时 Pylance 又在扫整个 venv，再加上 GitLens 在后台解析历史——这时单改一项效果甚微。务必从 code --status 出发，按进程 PID 逐个验证，否则容易在“感觉该关什么”上反复试错。
