语法高亮插件冲突本身不直接导致CPU飙升，真正耗资源的是其注册的文件监听、onSave处理或语言服务启动逻辑；多个插件同时响应同一事件（如保存.ts文件）会触发重复解析、格式化、类型检查，使Extension Host持续满载。
语法高亮插件冲突本身不直接导致 CPU 飙高，真正吃资源的是它们注册的文件监听、onSave 处理或语言服务启动逻辑——多个插件同时响应同一事件（比如保存 .ts 文件），会触发重复解析、格式化、类型检查，最终让 Extension Host 持续满载。
为什么两个高亮插件会互相“打架”
VSCode 的语法高亮本身极轻量，但很多高亮插件（如 esbenp.prettier-vscode、ms-python.python、bradlc.vscode-tailwindcss）实际不止做高亮：它们常附带 onSave 格式化、实时 lint、CSS 类名补全、依赖扫描等功能。一旦两个插件都声明了对 typescript 或 python 语言的 onLanguage:typescript 激活事件，VSCode 就会在打开 .ts 文件时同时加载两者，各自启动子进程（比如 tsserver 和 pyright），并监听文件变更。
- 常见组合踩坑：
ESLint+Prettier同时启用 onSave → 保存一次触发两次全文件解析 + 两次 AST 生成 -
GitLens+MarsCode AI→ 都在后台扫描 git 历史 + 上下文索引，共享同一个Extension Host进程却互不感知负载 -
Auto Rename Tag+Highlight Matching Tag→ 都监听 DOM 结构变化，光标移动时反复触发 DOM 树遍历
如何确认是高亮类插件在作祟
别靠直觉猜哪个插件“看起来重”，用 code --status 看真实子进程：
- 运行
code --status，重点关注Extension Host行的 CPU% —— 若长期 >60%，说明有插件在持续轮询或卡死 - 记下 PID，再执行
ps -p [PID] -o args=（macOS/Linux）或在任务管理器中右键 → “打开文件位置”，看命令行是否含prettier、eslint、tailwind等关键词 - 打开命令面板，运行
Developer: Show Running Extensions，按 “CPU Time” 排序，排前两位的大概率就是真凶
files.watcherExclude 配错会让冲突雪上加霜
即使你禁用了某个高亮插件，只要 files.watcherExclude 没配对，它残留的监听逻辑仍可能被另一个插件“误唤醒”。例如：
- 你禁用了
Prettier，但没配"**/node_modules/**": true→ESLint仍会因node_modules里成千上万个 .js 文件变更而反复触发 lint - 通配符写成
"node_modules": true或"*/node_modules/*"→ VSCode 完全忽略该配置，监听照旧 - 配置写在用户级
settings.json而非项目根目录的.vscode/settings.json→ 对当前工作区无效
降级语言服务比禁用插件更治本
很多“语法高亮插件”实际是语言扩展的壳（比如 ms-python.python 提供 Python 高亮，但底层依赖 pyright）。与其禁用整个插件，不如切断高开销模块：
- Python 项目：把
python.languageServer从Pylance改为Jedi（Jedi 不做全量类型推导，内存占用低 60%+） - TypeScript 项目：关闭
typescript.preferences.includePackageJsonAutoImports，避免每次 import 都扫描node_modules/@types - CSS 类名补全类插件（如 Tailwind）：关掉
tailwindCSS.experimental.classRegex自定义正则，防止遍历 HTML 字符串
真正难处理的不是“哪个插件该禁”，而是多个插件共用一套底层机制（比如都依赖 chokidar 监听、都往同一个 Extension Host 进程塞任务）——这时单点禁用只是缓解，必须配合 files.watcherExclude 和语言服务降级才能断根。
