卡顿大概率由插件引起，需先执行code --disable-extensions验证，再通过Developer: Show Running Extensions查看Startup Time＞150ms或CPU＞5%、内存＞300MB的插件，并配置files.watcherExclude排除node_modules等目录。
卡顿大概率不是 VSCode 本身的问题，而是某个插件在后台持续抢 CPU、占内存，或启动时就卡住主线程——尤其当你装了 20+ 插件时，往往一个“重”插件就能拖垮整套体验。
Developer: Show Running Extensions 看谁真在吃资源
别凭感觉猜，直接看实时负载：
-
Startup Time超过 150ms 的插件（如ms-python.python、eamodio.gitlens）大概率一开就阻塞 UI 线程 -
CPU %持续 >5% 或Memory MB>300MB 的插件（常见于dbaeumer.vscode-eslint、esbenp.prettier-vscode），说明它在后台跑分析/监听任务没节制 - 状态是
Running而非Activated：意味着它没闲着，正在干活，不是只注册了个事件
code --disable-extensions 是最干净的验证手段
关掉所有窗口，终端执行该命令再打开项目：
- 如果卡顿消失 → 100% 是插件问题，不用再查系统或硬件
- 如果仍卡顿 → 问题可能出在
settings.json配置、文件监视机制或 WSL2 跨文件系统访问（比如项目放在/mnt/c） - 这个命令不改任何设置，也不卸载插件，只是临时绕过扩展加载，比手动禁用快且可靠
files.watcherExclude 不配，插件再轻也白搭
VS Code 默认递归监听整个工作区，node_modules 里几万个小文件会直接打爆 inotify 句柄：
- 必须在项目根目录的
.vscode/settings.json中加这一段：
"files.watcherExclude": {
"**/node_modules/**": true,
"**/dist/**": true,
"**/build/**": true,
"**/.git/**": true,
"**/__pycache__/**": true
}
cat /proc/sys/fs/inotify/max_user_watches，若低于 524288，需执行 echo 524288 | sudo tee /proc/sys/fs/inotify/max_user_watches
Cmd+Q，Windows/Linux 关掉所有窗口并确认进程结束），再重新用 code . 打开；只点 Reload Window 不生效某些插件天生“启动即重”，禁用前先调配置
很多卡顿不是因为插件多，而是某几个默认就干重活：
-
ms-vscode.js-debug：即使你从不调试 JS，也会初始化完整调试服务 -
gitlens：默认开启全仓库历史扫描，关掉gitlens.advanced.caching.enabled能省几百 MB 内存 -
Remote - SSH：连接失败时 UI 线程会挂起几秒不报错，表现为“卡住” - 这些插件的
package.json里常含"activationEvents": ["*"]或"onStartupFinished"，不是装得多，是某个插件抢在启动时就干重活
真正难处理的不是崩溃或报错，而是插件卡在激活阶段、不报错也不退出，让后续所有插件排队等它——这种问题必须靠 Developer: Show Running Extensions 和 Developer: Start Extension Bisect 双验证，单看控制台日志容易漏掉。
