先运行developer: show running extensions查看startup time（>150ms即抢主线程）和cpu列（>200mb+频繁波动说明后台执行分析/监听），结合running状态确认真正在运行的插件；再通过禁用激进策略、配置files.watcherexclude及code --disable-extensions验证定位。
怎么看插件实际在干啥：Startup Time 和 CPU 列不是摆设
打开 Ctrl+Shift+P（Windows/Linux）或 Cmd+Shift+P（macOS），输入并运行 Developer: Show Running Extensions。这不是罗列已装插件，而是看谁正在真实劫持主线程：
-
Startup Time超过150ms的插件，基本等于编辑器一启动就抢走用户交互权——比如某些 Copilot 衍生插件、主题预加载器，甚至部分远程连接扩展 -
CPU列持续跳动（尤其 >200MB + 频繁波动），说明它正在后台跑分析/监听/缓存任务：GitLens、ESLint、Prettier常年蹲在这儿 - 状态显示为
Activated但耗时几乎为 0？它只是注册了激活事件，还没真干活；而Running状态且CPU持续跳动的，才是正在吃资源的活进程
禁用前先调设置：很多“重”是默认行为太莽
别急着卸载。多数插件卡顿源于默认开启的全量扫描、实时索引、自动缓存等激进策略：
-
GitLens默认开启全仓库历史扫描和符号缓存 → 改"gitlens.advanced.caching.enabled": false，内存可降几百 MB -
TypeScript扩展默认加载所有@types→ 改"typescript.preferences.includePackageJsonAutoImports": "auto"，TSServer 启动快一倍 -
ESLint默认onType实时检查 → 改成"eslint.run": "onSave"，敲字不卡，保存再报错 - 所有调整必须写入
.vscode/settings.json（项目级）或用户settings.json，改完需重启窗口才生效
files.watcherExclude 不配，插件再轻也白搭
VS Code 的文件监听机制（chokidar）一旦被 node_modules、.git、dist 这类目录拖住，插件再怎么优化也救不了——因为它们的触发逻辑全依赖这些事件：
- 必须在工作区级
.vscode/settings.json中配置，用户级设置无效 - 至少包含：
"**/node_modules/**": true、"**/.git/**": true、"**/dist/**": true、"**/build/**": true、"**/__pycache__/**": true - Python 项目补上：
"**/venv/**": true、"**/.mypy_cache/**": true；前端项目补上："**/out/**": true -
**/是关键，单星号*/或漏掉斜杠会失效；路径通配符必须双星号开头，否则子目录照样扫 - 改完后必须关闭并重新打开当前工作区，设置才真正加载；只刷新窗口没用
验证是否真因插件导致卡顿：code --disable-extensions 是金标准
很多卡顿看似是插件引起，实则是文件监视或语言服务器问题。最干净的验证方式是绕过所有插件启动：
- 终端执行
code --disable-extensions --no-sandbox（Linux/macOS）或code --disable-extensions（Windows） - 打开同一份大规模单体项目，观察启动时间、打字延迟、Git 状态刷新是否明显改善
- 若恢复流畅，说明问题确在插件层；若仍卡，立刻转向排查
files.watcherExclude配置或TypeScript语言服务负载 - 注意：
--disable-extensions不影响你已写入.vscode/settings.json的配置项，所以排除法结果可信度高
GitLens 在首次点击 Git 图标时才拉起完整历史分析，这种延迟触发的资源争抢最难定位。务必在真实编辑场景下盯住 Developer: Show Running Extensions 的 CPU 波动，而不是只看刚启动那几秒。
