运行增强类插件如coderunner、rest client、python test explorer和shell launcher普遍声明onstartup或*激活事件，导致启动时强制加载并产生300ms以上延迟；禁用后需彻底重启vscode并用code --status和performance工具验证是否仍存在残留进程。
运行增强类插件（如 CodeRunner、Shell Launcher、REST Client、Python Test Explorer）在 VSCode 启动时普遍触发 onStartup 或 onCommand 激活事件，导致扩展主机进程提前加载并执行初始化逻辑——它们不是“安静的装饰”，而是启动阶段的主动参与者。
哪些运行增强插件会强制 onStartup 激活？
这类插件往往在 package.json 中声明 "activationEvents": ["*"] 或 ["onStartup"]，意味着一启动就进队列。实测中以下插件默认启用该策略：
-
CodeRunner：即使没打开任何可执行文件，也会预加载所有语言运行时配置，activationTime稳定在 380–620ms -
REST Client：启动即监听.http文件变更，并预解析全局rest-client.environmentVariables，冷启耗时常超 450ms -
Python Test Explorer：只要工作区含pytest或unittest配置，就会立即扫描测试目录，触发同步文件 I/O -
Shell Launcher：注册全部 shell 类型命令，activate()内部调用os.homedir()+fs.readdirSync()，在 Windows 上延迟更明显
注意：activationTime > 300ms 且 isActivated: true 的插件，已构成启动瓶颈；多个叠加极易突破 1200ms 用户感知阈值。
为什么禁用后仍看到 extensionHost 高 CPU？
运行增强类插件常伴随后台服务驻留或事件监听器未清理，禁用操作仅卸载 UI 层，不终止已启动的子进程。典型表现包括：
- 禁用
CodeRunner后，ps aux | grep runner仍可见残留的node --max-old-space-size=4096进程 -
REST Client卸载后，其注册的vscode.workspace.onDidChangeConfiguration回调未解绑，持续响应配置变更 - 某些插件（如旧版
Python Test Explorer）将测试发现器作为单例缓存，即使禁用也保留在内存中，直到重启 VSCode
验证方式：执行 code --status，若 extensionHost 总耗时未下降，说明有插件“假禁用”。必须配合 Developer: Toggle Developer Tools → Performance 录制重启过程，定位仍在执行的长任务。
如何安全降级运行增强功能而不丢能力？
不必全删，关键是把“开机就跑”改成“要用才启”。可行路径如下：
- 对
CodeRunner：关闭自动激活，改用命令面板触发 —— 在settings.json中设"code-runner.runInTerminal": false和"code-runner.clearPreviousOutput": true，再通过Ctrl+Alt+N按需运行 - 对
REST Client：移除"rest-client.defaultEnvironment"全局配置，改用单文件顶部的@name块定义环境，避免启动时预加载全部变量 - 对
Python Test Explorer：禁用插件，改用 VSCode 内置 Python 测试适配器（1.86+ 版本已原生支持 pytest/unittest），它按需启动、无预扫描 - 对
Shell Launcher：直接删除，VSCode 1.85+ 已内置多终端标签页和 shell 选择下拉菜单，无需额外插件
特别注意：extensions.experimental.affinity 配置对这类插件无效——它们多数未声明 extensionKind，无法被调度到独立进程，强行设置反而引发通信开销。
运行增强类插件的真实成本不在功能本身，而在它们对“启动即服务”范式的滥用。一个 onStartup 激活的插件，可能比十个 UI 装饰插件更拖慢你每天第一次打开编辑器的那几秒。最有效的优化，往往始于删掉那个你只用过三次、却每次都在后台默默加载的插件。
