VSCode CPU或内存过高主因是扩展、文件监听或语言服务异常：先用code --status定位高占用进程，再配置files.watcherExclude排除node_modules等目录，优化Python/TS语言服务及AI插件索引行为。
VSCode 占用 CPU 或内存过高，基本不是编辑器本身的问题，而是某个扩展、文件监听行为或语言服务在后台持续吃资源。直接查 code --status 就能定位到具体是哪个进程在“发疯”，比盲猜禁用快得多。
用 code --status 快速定位高占用进程
VSCode 启动后 CPU 持续 70%+，界面却还能点——这说明主进程（Renderer）正常，问题大概率出在 Extension Host 或 Shared Process 上。code --status 会列出所有子进程及其 CPU / 内存占用，重点关注：
-
Extension Host：如果它占 80% CPU，说明某个扩展在反复解析、监听或索引 -
Shared Process：占用高通常指向设置同步、遥测（telemetry.telemetryLevel）、或自动更新检查 -
Search Service或File Watcher：可能被node_modules或日志目录拖垮
拿到高占用进程的 PID 后，用 ps -p [pid] -o comm=（macOS/Linux）或任务管理器（Windows）确认对应扩展名，再针对性处理。
files.watcherExclude 配置必须写对
这是最常被写错、也最立竿见影的优化项。VSCode 默认用 chokidar 监听整个工作区，一旦项目里有 node_modules 这种几万文件的目录，监听器就会疯狂触发事件，让 Node.js 子进程满载。
- 路径通配符必须是
**/node_modules/**，写成*node_modules*或/node_modules/无效 - 生效需关闭并重新打开工作区，仅保存 settings.json 不够
- 常见必加项：
"**/node_modules/**": true、"**/dist/**": true、"**/.git/**": true、"**/*.log": true - Linux 用户若仍卡顿，检查系统级限制：
cat /proc/sys/fs/inotify/max_user_watches，低于 524288 建议调高
Python/TypeScript 扩展内存驻留太高
Python 扩展（ms-python.python）和 TypeScript 语言服务不是“慢”，是试图把整个依赖树加载进内存做类型推导。一个含 50+ 包的 Python 项目，Extension Host 常驻内存轻松破 1.2GB。
- Python：把
python.languageServer从Pylance改为Jedi，或禁用python.analysis.extraPaths - TypeScript：关掉
typescript.preferences.includePackageJsonAutoImports，避免 npm 包导入时反复解析 - ESLint：设
eslint.run为onType，并精简eslint.probe的文件类型（比如去掉.json） - GitLens：关掉
gitlens.codeLens.enabled和gitlens.hovers.enabled，能降 30%–50% 内存
别忽略通义灵码这类 AI 插件的索引行为
像 tongyi lingma 这类插件，默认会对整个工作区做代码索引。你没主动用它，它也在后台扫文件——尤其当工程大、文件多时，CPU 和内存都会悄悄爬升。
- 在项目根目录建
.tongyiignore，格式和.gitignore一致，比如写上node_modules/、dist/ - 改完后要手动结束 Lingma 进程（
kill -9 [pid]或重启 VSCode），配置才生效 - 同理，其他带“AI”“copilot”“auto-import”字样的插件，也要留意其索引范围和触发时机
真正难搞的从来不是单个配置，而是多个监听机制叠加：watcher 在扫文件、ESLint 在校验、Pylance 在推导、Lingma 在索引——它们各自只占 20% CPU，合起来就把机器拖垮了。优先砍掉最重的那一个，再看 code --status 变化，比一口气全禁更稳。
