vscode中node.js进程cpu过高主因是扩展或语言服务失控，应先运行code --status定位extension host、tsserver等高占用子进程，再配置files.watcherexclude排除node_modules等目录、降级语言服务、禁用插件并彻底重启窗口。
VSCode 里 Node.js 进程 CPU 占用过高，90% 不是代码写错了死循环，而是某个扩展或语言服务在 Node 子进程中卡死——code --status 能立刻确认是不是它，而不是靠猜。
怎么看是不是 Node 子进程真在疯跑
别信任务管理器里那个“Code Helper”进程名，它只是壳。真正干活的是 Extension Host、tsserver、pyright、lingma-server 这类子进程：
- 终端执行
code --status，直接列出所有子进程的 PID、CPU% 和内存占用 - 重点关注 CPU% 长期 >60% 的
Extension Host—— 说明某个插件（比如esbenp.prettier-vscode或gitlens.gitlens）在 on-save 或文件监听失败后卡住，不是你写的 JS 代码在跑死循环 - 看到命令行含
tsserver或pyright？那大概率是 TypeScript/Python 语言服务在反复解析node_modules/@types，不是你的业务逻辑出问题 - 如果
lingma-server或copilot进程占满 CPU，说明通义灵码或 Copilot 正在对整个工作区做后台索引，和你写的异步代码无关
为什么 files.watcherExclude 配错等于没配
VSCode 默认用 chokidar 监听整个工作区，一旦项目里有 node_modules（几万小文件），inotify 事件就爆炸式触发，Node 子进程持续满载——你什么都没改，CPU 就 80%+
- 必须写在项目根目录的
.vscode/settings.json中，用户级设置无效 - 通配符必须是
"**/node_modules/**": true，写成"node_modules"、"*/node_modules/*"或"/node_modules/"全部不生效 - 改完必须完全关闭当前 VSCode 窗口（不是重载），再重新打开工作区才生效
- Linux 用户还需检查
cat /proc/sys/fs/inotify/max_user_watches，低于524288就得调高，否则 watcher 会静默失败并不断重试
禁用插件后 CPU 还不降？旧进程根本没退出
很多插件注册了 onStartupFinished 或 onLanguage:javascript 这类激活事件，一旦触发就会常驻内存。“Disable”只是阻止新加载，旧进程还在跑——这是最常被忽略的坑
- 先运行命令面板里的
Developer: Show Running Extensions，按 CPU% 排序，确认哪些插件真在跑 - 右键目标插件 →
Disable (For All Folders)（注意不是仅限当前工作区） - 必须完全关闭当前 VSCode 窗口，再重新打开工作区；
Developer: Reload Window不会杀掉旧进程 - 必要时手动清理残留：
ps aux | grep -i "tsserver\|pyright\|lingma"，找到 PID 后kill -9 [PID]
语言服务器降级比禁用插件更有效
TypeScript 和 Python 的语言服务默认做全量语义分析，对中大型项目等于把整个 node_modules/@types 或所有依赖包加载进内存——不是慢，是设计上就不轻量
- Python：把
python.languageServer从Pylance改为Jedi（Jedi 不做全量类型推导） - TypeScript：设
typescript.preferences.includePackageJsonAutoImports为off，避免导入时反复解析node_modules/@types - ESLint：设
eslint.run为onType，并精简eslint.probe的文件类型（比如去掉.json） - GitLens：关掉
gitlens.codeLens.enabled和gitlens.hovers.enabled，能降 30%–50% 内存
真正容易被忽略的是：VSCode 1.118 版本起，Copilot CLI 和通义灵码这类 AI 插件默认开启全工作区索引，且不提供 UI 提示——code --status 是唯一能提前发现它们吃光 CPU 的方式。
