直接运行developer: startup performance生成时间线报告，重点关注“activating extension”超300ms、“waiting for language server”挂起、“blocked on require/import”三类条目。
怎么定位插件卡住 VSCode 的具体位置
直接看任务管理器里 Code Helper (Renderer) 进程的 CPU 占用没用——它只是“症状”，不是“病灶”。真正要抓的是哪个插件在拖慢启动、阻塞编辑、或持续吃内存。
打开命令面板（Ctrl+Shift+P），输入并执行：Developer: Startup Performance。它会生成一个带时间线的报告，列出每个扩展的激活耗时、语言服务器初始化延迟、以及是否触发了同步阻塞操作。
重点关注三类条目：
- “Activating extension” 耗时 >300ms 的插件（比如某些未优化的 ESLint 或 GitLens 版本）
- “Waiting for language server” 持续挂起（说明 TS/Python 服务本身卡死，不是 VSCode 问题）
- “Blocked on” 后面跟着
require或import——这是 CommonJS 模块加载阻塞，常见于老版本插件
如何用最小开销验证某个插件是否真有问题
别一上来就卸载。先做“二分法禁用”：在插件面板（Ctrl+Shift+X）里，把已安装插件按启用状态排序，禁用后半部分 → 重启 → 测试输入响应和文件切换速度。如果变快，问题就在后半；否则再禁用前半。两轮就能缩到 2–3 个嫌疑插件。
更准的做法是临时创建一个干净工作区：
- 新建空文件夹，用
code --disable-extensions --user-data-dir=/tmp/vscode-test启动（Linux/macOS）或code --disable-extensions --user-data-dir=C:\temp\vscode-test（Windows） - 只手动启用一个待测插件，再开一个 .js 文件，打几个字观察延迟
- 注意：这个模式下所有用户设置、历史记录、扩展都隔离，能排除配置污染
为什么关掉 GPU 加速反而让插件更稳
很多插件（尤其是带 WebView 或自定义渲染器的，如 REST Client、Markdown Preview Enhanced）默认依赖 Electron 的 GPU 渲染路径。但在 Intel HD 4000–UHD 620、老旧 AMD APU 或 Windows 上的 WSL2 环境中，WebGL context 创建失败会导致插件主线程反复重试，CPU 占用飙高且无日志报错。
验证方式：打开开发者工具（Ctrl+Shift+I），切到 Console 标签页，输入 getGPUInfo()。如果返回 null 或报 Failed to create WebGL context，说明 GPU 渲染链已断。
此时必须加启动参数强制降级：
code --disable-gpu --disable-hardware-acceleration --disable-direct-composition- Windows 用户额外加
--disable-features=CalculateNativeWinOcclusion可缓解窗口遮挡重绘抖动 - 参数必须完整退出所有 VSCode 进程后再运行，否则不生效
插件日志里最该盯住的几行错误
VSCode 插件崩溃通常不弹框，只默默降级为“未激活”。打开输出面板（Ctrl+Shift+U），在下拉菜单里选 Log (Extension Host)，滚动到底部看最近 20 行。真正关键的不是 Cannot find module，而是这些：
-
Activation timeout for ... after 10000ms：插件启动超时，大概率在初始化语言服务或读大文件 -
Extension host terminated unexpectedly：Node.js 子进程被系统 kill，通常是内存溢出（低配机 4GB 内存跑 Prettier + ESLint + TypeScript Server 就容易触发） -
textDocument/completion request cancelled：补全请求被中断，90% 是语言服务器响应太慢，插件等不及就放弃
这些日志不会自动上报，也不进开发者工具 Console，必须手动翻输出面板——这是低配设备上最常被跳过的诊断步骤。
