code --status是定位VSCode重复检测高CPU的唯一可信入口，需重点查Extension Host（>60%）、Search（>300MB）及Shared Process，再配files.watcherExclude、关onType检测、调高inotify句柄并彻底重启。
VSCode 代码重复检测（如 ESLint、Prettier、GitLens 的重复行/相似块分析）本身不直接触发高 CPU，真正吃资源的是它依赖的后台进程——尤其是 Extension Host 被反复唤醒做全量扫描，或 rg（RipGrep）暴力遍历 node_modules 等目录时。
用 code --status 快速确认是不是重复检测在作祟
打开终端，执行：code --status
重点看三类进程：
-
Extension HostCPU% 长期 >60%：大概率是dbaeumer.vscode-eslint或esbenp.prettier-vscode在onType模式下持续解析整个文件树，尤其当项目含大量.ts或.js文件时 -
Search进程内存 >300MB 或 CPU 暴涨：说明rg正在扫node_modules、.git/objects或符号链接目录——而很多“重复检测”功能（比如 GitLens 的相似提交比对、ESLint 的no-duplicate-case全局检查）会隐式触发搜索 -
Shared Process占高且伴随频繁磁盘 I/O：可能是遥测或扩展同步在轮询，间接拖慢重复检测响应，造成“卡着不动但 CPU 不降”的假象
files.watcherExclude 必须配对生效，否则重复检测永远跑不满
VSCode 的重复检测逻辑（如 ESLint 自动修复、Prettier 格式化触发）高度依赖文件变更监听。一旦监听器被 node_modules 这类目录淹没，就会不断重试、排队、堆积任务，导致 Extension Host 持续满载。
- 必须写在项目根目录的
.vscode/settings.json中（不是用户级设置） - 通配符必须是
"**/node_modules/**": true，写成"node_modules/**"、"*/node_modules/*"或"node_modules"全无效 - 顺手加上
"**/dist/**": true、"**/build/**": true、"**/coverage/**": true，避免构建产物干扰 - 改完后必须完全关闭 VSCode 窗口（不是重载），再重新打开工作区才生效
关掉实时检测，改用 onSave + 精准范围更省资源
重复检测类扩展默认开启 onType（边打字边检查），对中大型项目就是 CPU 杀手。换成保存时触发，配合文件类型过滤，能砍掉 70%+ 后台负载：
- ESLint：
"eslint.run": "onSave"+"eslint.probe": ["javascript", "typescript"]（去掉"json"、"html"等非代码文件） - Prettier：
"prettier.requireConfig": true（只在有.prettierrc的目录生效），避免全局瞎扫 - GitLens：
"gitlens.codeLens.enabled": false+"gitlens.hovers.enabled": false（禁用行内重复提交提示和悬停相似变更） - TypeScript：
"typescript.preferences.includePackageJsonAutoImports": "off"（防止导入时反复解析node_modules/@types，间接减少重复类型检查压力）
Linux 用户注意 inotify 句柄数不足会静默失败
即使你配了 files.watcherExclude，Linux 下若 /proc/sys/fs/inotify/max_user_watches 小于 524288，watcher 会静默失败并不断重试——结果是 CPU 看似不高，但重复检测根本收不到文件变更通知，你以为“没在跑”，其实它卡在重试队列里。
- 运行
cat /proc/sys/fs/inotify/max_user_watches查当前值 - 临时调高：
echo 524288 | sudo tee /proc/sys/fs/inotify/max_user_watches - 永久生效需写入
/etc/sysctl.conf，否则重启失效
真正的瓶颈往往不在“检测逻辑多复杂”，而在“它被不该扫的目录拖垮了”。配错一个通配符、少关一个实时开关、漏调一次系统限制，都可能让优化白做。
