卡死在“正在加载扩展”或启动瞬间无响应，基本是某个扩展的activate()函数阻塞主线程；用code --status查看Extensions耗时，配合Developer: Start Extension Bisect二分定位，3–4轮即可锁定问题插件。
卡死在“正在加载扩展”或启动瞬间无响应，基本就是某个扩展的 activate() 函数阻塞了主线程——不是所有扩展都“重”，但只要一个用了同步 fs 操作、没设超时的网络请求，或递归监听了 node_modules，整个 UI 就会挂住。
怎么看哪个扩展在拖后腿
别猜，直接看 VSCode 自己报的账：code --status 是最准的启动诊断命令。它不渲染界面，只输出关键耗时数据。
- 重点盯
Extensions区域：有没有扩展显示activated状态且耗时 >200ms？尤其是ms-vscode.js-debug、gitlens、esbenp.prettier-vscode这类声明了"activationEvents": ["*"]的 - 如果终端卡在输出一半、或者最后几行出现
ERR! spawn ENOENT或Extension host terminated unexpectedly，说明某个扩展启动失败并拖垮了整个 Extension Host 进程 - 配合
Developer: Startup Performance（Cmd+Shift+P 输入）可看到更细粒度的子阶段耗时，比如 “Activating extension ms-python.python” 卡在 “Running activation script” 超过 1.5s，基本就是它
怎么快速隔离问题扩展
手动一个个禁用太慢，VSCode 提供了二分法工具，3–4 轮就能定位。
- 先运行
code --disable-extensions：能正常启动，就确认是扩展问题 - 接着按 Cmd+Shift+P / Ctrl+Shift+P，输入
Developer: Start Extension Bisect，它会自动启用一半扩展 → 你测试是否卡死 → 它再切另一半，反复直到锁定唯一嫌疑插件 - 常见高危组合包括：
ESLint+Prettier同时设为默认格式器、GitLens在大型仓库中开启缓存、Remote-SSH远端环境权限异常或 Node 版本不兼容
为什么改了 settings.json 还不生效
VSCode 的配置分层很关键：用户级设置不覆盖项目级行为，而且很多扩展初始化逻辑只在**首次加载工作区时执行一次**，改完不重启等于白改。
- 必须把优化项写进项目根目录的
.vscode/settings.json，而不是用户settings.json；例如排除监听："files.watcherExclude": {"**/node_modules/**": true, "**/dist/**": true} - 禁用扩展要右键 →
Disable (Workspace)，不是仅禁用当前窗口；否则下次打开别的文件夹，它又自动激活 - 改完配置后，**必须完全退出 VSCode（macOS 查活动监视器，Windows 查任务管理器里所有 Code.exe），再重新打开整个窗口**——热重载对扩展激活逻辑无效
容易被忽略的三个底层陷阱
排查到扩展层面还不够，有些卡死根本不在 UI 层，而是发生在 Node 子进程或系统调用环节。
-
node_modules下存在软链接循环（比如a -> ../b，b -> ../a），会导致fs.realpathSync()死循环，表现为node --version卡住、npm run无响应——这不是 VSCode 的错，但你会在调试时误判 - Linux/macOS 用户的
inotify句柄数不够（/proc/sys/fs/inotify/max_user_watches默认常为 8192），而 VSCode 监听整个工作区时会快速耗尽，结果就是 CPU 拉满、保存延迟、Git 状态不更新 - Remote-SSH 连接卡在“输入密码”却无报错，大概率是远端残留的
code-server进程僵死，不是网络或密钥问题；需 SSH 登上去杀掉所有node和code进程再重连
