VSCode编辑器性能诊断与启动项延迟控制-VSCode-PHP中文网

先执行code --disable-extensions验证是否插件导致，若秒开则100%是扩展问题；再运行developer: show running extensions，重点排查activation time超1000ms或状态为activating/activation failed的插件。

vscode编辑器性能诊断与启动项延迟控制

VSCode 启动卡在 “Activating Extensions” 或编辑器响应迟钝，大概率不是硬件问题，而是某个扩展在启动阶段执行了同步 I/O、网络请求或全量文件扫描——这类行为会直接阻塞主线程，导致整个 UI 冻结。

怎么看哪个插件在拖慢启动

别猜，直接看 VSCode 自己的诊断数据。按 Cmd+Shift+P（macOS）或 Ctrl+Shift+P（Windows/Linux），输入并选择 Developer: Startup Performance。它会打开一个带时间轴的面板，列出主进程、渲染器、扩展激活等各阶段耗时。

重点关注 “Extension Activation” 区域里耗时超过 300ms 的条目；再配合 Developer: Show Running Extensions 查看哪些扩展状态长期卡在 “Activating…”。常见高嫌疑对象包括：GitLens、ESLint、Prettier、Remote - SSH，尤其是它们的 activationEvents 里含 onStartup 或 * 的版本。

如果某个扩展在 Startup Performance 里显示 “Activating (sync)” —— 基本可以确定它用了同步 fs 操作，必须禁用或换替代方案
Remote - SSH 在未连接远端时仍会尝试重连，建议在非远程场景下全局禁用
语言类扩展（如 Python、Java Extension Pack）若项目不涉及对应语言，禁用后启动可快 1–3 秒

files.watcherExclude 配置为什么经常失效

写了 "files.watcherExclude": {"**/node_modules/**": true} 却还是卡？常见原因有三个：路径没写对、规则被覆盖、系统 inotify 句柄不够。

第一，VSCode 的 watcher 排除是**前缀匹配 + glob 展开**，不是正则；**/node_modules/** 能匹配 /project/node_modules/foo/index.js，但写成 node_modules（缺前后通配符）就无效。第二，用户级 settings.json 和工作区级 .vscode/settings.json 同时存在时，后者优先级更高——检查你是不是在错误位置改了配置。

Linux/macOS 下运行 cat /proc/sys/fs/inotify/max_user_watches，若低于 524288，watcher 会静默退化为轮询，CPU 直接飙满
macOS 上某些插件（如 Live Server）会绕过 files.watcherExclude 自行启动 chokidar 实例，得单独关掉它
禁用 files.useExperimentalFileWatcher（设为 false）有时反而更稳，尤其在老旧内核或虚拟机中

延迟加载 extensionKind 怎么配才真正生效

"remote.extensionKind" 不是开关，而是一个“调度策略声明”：它告诉 VSCode “这个扩展只应在 workspace 环境里加载”，从而跳过本地冷启动阶段。但它只对支持多实例模式的扩展有效（如 ms-python.python、ms-vscode.vscode-typescript-next），对 prettier.prettier-vscode 这类纯前端格式化插件无效。

VSCode

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

下载

正确写法是在用户级 settings.json（不是工作区）中添加：

"remote.extensionKind": {
  "ms-python.python": ["workspace"],
  "ms-vscode.cpptools": ["workspace"]
}

注意：该配置仅在你使用 Remote-SSH / WSL / Containers 时起作用；若你从不连远程，这条配置毫无意义，还可能干扰本地语言服务发现逻辑。

扩展 ID 必须完全准确，大小写敏感，可在扩展详情页 URL 里找到（如 https://marketplace.visualstudio.com/items?itemName=ms-python.python 中的 ms-python.python）
值必须是数组，不能写成字符串 "workspace"，否则 VSCode 会忽略整条配置
改完后需**完全退出 VSCode 进程**（macOS 上 Cmd+Q，Windows 上右键任务栏图标退出），再重新打开才生效

轻量启动模式不是临时方案，而是诊断基准线

code --disable-extensions --disable-gpu --no-sandbox 这个命令的价值，不是让你日常这么用，而是建立一个“干净基线”：如果它启动秒开，说明问题 100% 出在扩展或 GPU 渲染层；如果它依然慢，就得查文件系统、磁盘 I/O 或用户数据目录损坏。

日常误操作是把它加进 Dock 或桌面快捷方式当主力入口——这等于放弃所有语言服务、Git 集成和调试能力。它唯一合理用途是：每次怀疑性能回归时，用它快速验证是否由某次更新或配置变更引发。

Mac 用户注意：--disable-gpu 在 M 系列芯片上常导致文字模糊、滚动撕裂，应优先试 --enable-gpu-rasterization
Windows 上若用 --disable-gpu 后反而更卡，大概率是显卡驱动冲突，此时应清理 %APPDATA%\Code\GPUCache
真正需要长期启用的，只有 --disable-extensions —— 它能帮你确认是否该重装某个扩展，而不是反复调参

最常被忽略的一点：VSCode 的“启动完成”不等于“功能就绪”。很多语言服务器（如 tsserver、pylsp）会在窗口渲染后继续后台加载数秒，期间跳转、补全、悬停都不可用。这时看 Developer: Toggle Developer Tools → Console 里的 warning 日志，比盯着进度条有用得多。