VSCode编辑器启动加载项的性能优化技巧-VSCode-PHP中文网

vscode启动慢90%是扩展抢资源，因activationevents设为*或未声明触发条件导致全量加载；应禁用高耗时扩展、配置extensions.experimental.affinity延迟加载、精准设置files.watcherexclude排除node_modules等目录。

vscode编辑器启动加载项的性能优化技巧

为什么 VSCode 启动慢，90% 是扩展在抢资源

VSCode 启动慢的核心原因不是硬件差，而是大量扩展在主进程初始化阶段就争抢 CPU 和内存。尤其当 activationEvents 配置为 * 或插件未声明触发条件时，它会在启动瞬间全部加载——哪怕你只打开一个 .txt 文件，GitLens、Docker、ESLint 全部已就绪待命。

实操建议：

运行 Developer: Startup Performance 查看各阶段耗时，重点关注“Extension Activation”是否占总时间 40% 以上
用 Extensions: Show Running Extensions 查当前活跃扩展及其 CPU/内存占用，高消耗但低使用频次的直接禁用
检查插件设置里是否有 activationMode 选项（如 gitlens.activationMode），设为 onCommand 或 never 可跳过冷启动加载

如何让插件真正“按需加载”，而不是“一哄而上”

VSCode 1.86+ 内置了 extensions.experimental.affinity 机制，它不依赖插件自身是否适配 activationEvents，而是由编辑器强制调度延迟加载。数字 2 表示“仅在首次调用其命令或打开匹配语言文件时才激活”，对老旧或未规范开发的插件特别有效。

实操建议：

打开 settings.json，添加类似配置：

"extensions.experimental.affinity": {
  "ms-vscode.vscode-typescript-next": 2,
  "esbenp.prettier-vscode": 2,
  "redhat.vscode-yaml": 2
}

不要给所有插件都设 2——像 Python 扩展若你每天写 Python，设为 1（正常加载）反而更稳；而 Remote - SSH 这类非日常插件才适合 2
该配置对 workspace 级别也生效，可在项目根目录的 .vscode/settings.json 中单独设置，避免全局一刀切

files.watcherExclude 配置错一个斜杠，文件监视就退化成全盘扫描

files.watcherExclude 不是“隐藏文件”，而是告诉 VSCode “别监听这些路径的变更”。一旦漏配或路径写错（比如写成 "**/node_modules" 少了末尾 /），系统级文件监视器（如 macOS 的 FSEvents）会因匹配失败而 fallback 到低效的轮询模式，导致 CPU 持续 30%+ 占用、保存卡顿、自动补全延迟。

VSCode

避免常见的 VSCode 错误——设置冲突、调试器配置和扩展冲突。

下载

实操建议：

必须用 glob 语法，且路径末尾带 /：正确是 "**/node_modules/**": true，错误是 "**/node_modules": true
优先排除高频干扰目录："**/node_modules/**"、"**/dist/**"、"**/.git/**"、"**/build/**"
如果项目含大量小文件（如日志目录），额外加 "**/*.log": true，避免 inotify 句柄耗尽（Linux/macOS 下常见 OOM 原因）

终端启动慢？可能和编辑器本身毫无关系

VSCode 启动后点击 + 开新终端却要等 2 秒才有提示符，大概率不是编辑器问题，而是终端 profile 初始化太重。PowerShell 加载模块、Oh My Zsh 扫描 Git 状态、WSL2 下直连 \wsl$ 路径都会拖慢 shell 启动，进而让 code-runner 或调试器卡在“等待终端就绪”阶段。

实操建议：

检查 terminal.integrated.defaultProfile.windows 是否指向 powershell.exe；换成 commandPrompt 或精简版 pwsh（去掉 profile 脚本）
macOS/Linux 用户确认 ~/.zshrc 里没有 git status、pyenv init 这类阻塞命令，或用 if [ -t 1 ]; then ... fi 包裹
WSL2 用户务必用 code /home/user/project 启动，而非从 Windows 资源管理器打开 \wsl$\Ubuntu\home\user\project —— 后者走 Windows I/O 桥接，延迟翻倍