直接看developer: show running extensions，重点盯activation time（超150ms抢启动控制权）和cpu列（持续跳动且内存>200mb说明后台扫目录/建缓存），状态running且cpu波动的才是真吃资源的活进程。
怎么看插件到底在拖慢哪一步
启动卡、打字卡、切换文件卡——不同卡法对应不同插件行为。直接看 Developer: Show Running Extensions，重点盯两列：Activation Time 和 CPU。前者超 150ms 就说明它抢了编辑器刚露头那会儿的控制权；后者持续跳动且内存 >200MB，基本是后台在扫目录、建缓存或跑分析。
常见陷阱：状态显示 Activated 但耗时为 0 的插件，只是注册了事件，还没真干活；而状态为 Running 且 CPU 列频繁波动的，才是正在吃资源的活进程。
-
ms-vscode.js-debug即使你从不调试 JS，也会初始化完整服务，Activation Time常破 2000ms -
gitlens默认开启全仓库历史扫描，CPU持续占满，关掉gitlens.advanced.caching.enabled可降几百 MB 内存 -
ms-python.python旧版本会在打开任意文本文件时尝试初始化 Python 环境，Activation Time高得离谱
禁用前先调配置，很多“重”是默认太莽
卸载不是第一选择。多数插件的“重”，来自默认开启的全量监听、实时索引或自动缓存。这些行为可关，且关了不影响核心功能。
- GitLens：设
"gitlens.advanced.caching.enabled": false，停掉符号缓存和历史预加载 - TypeScript：关
"typescript.suggest.autoImports": false和"typescript.preferences.includePackageJsonAutoImports": "off"，TSServer 启动快一倍 - ESLint：改
"eslint.run": "onSave"，避免onType实时检查打断输入流 - Pylance（Python）：直接设
"python.languageServer": "none"，保留语法高亮但不启语言服务进程
所有修改必须写入 settings.json（用户级或项目级），改完需关闭并重新打开工作区才生效。
files.watcherExclude 配错等于白调
VSCode 的文件监听机制（chokidar/inotify）一旦被 node_modules、.git、dist 这类目录拖住，再轻的插件也救不了——因为它们的触发逻辑全靠这些事件驱动。
正确写法必须用双星号通配："**/node_modules/**": true，漏掉任一 **/ 或写成 "node_modules/**" 都会失效，子目录照样扫。
- 推荐最小安全集：
"**/node_modules/**"、"**/.git/**"、"**/dist/**"、"**/build/**"、"**/__pycache__/**"、"**/venv/**" - Linux/WSL2 用户若遇到
ENOSPC错误，需运行echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p - 改完必须关闭当前工作区再重开，仅刷新窗口不加载新设置
验证是否真由插件引起
别猜，用命令实锤。终端执行 code --disable-extensions，如果秒开、语法高亮正常、跳转可用，问题就 100% 出在扩展上。
接着补一个动作：code --status，输出里 Extensions 区域会标出每个插件的真实激活耗时，比 GUI 更准——有些插件在 Developer: Show Running Extensions 里显示很快，但 code --status 里暴露真实延迟。
- 若
--disable-extensions仍卡，大概率是 VSCode 自身机制问题：GPU 渲染异常、inotify耗尽、或工作区过大触发默认索引 - 此时再试
code --disable-gpu --disable-hardware-acceleration，尤其对集成显卡或 WSL2 环境有效 - 注意：禁用 GPU 后字体略发虚，但响应速度提升明显；若屏幕闪烁，额外加
--disable-direct-composition
真正容易被忽略的是：插件禁用后没重启工作区，或者 files.watcherExclude 路径少写了一个 **/，结果白调半天。
