activationEvents比插件开关更关键，因为禁用插件仅隐藏UI，而activationEvents才真正控制插件代码何时被require进内存；如“onLanguage:javascript”仅打开.js文件时激活，“onCommand:extension.formatCode”仅触发命令时加载，“workspaceContains:**/tsconfig.json”则更精准匹配项目需求。
为什么 activationEvents 比插件开关更关键
禁用插件只是让 UI 不显示，但很多插件仍会在启动时读取 package.json、注册监听器、甚至预热语言服务器——资源已消耗，只是没暴露功能。真正控制“是否加载”的开关是 activationEvents，它决定插件代码何时被 require 进内存。
常见错误是以为关掉插件就万事大吉，结果 ESLint 或 Prettier 依然在后台扫描整个工作区，拖慢打开第一个 JS 文件的速度。
-
"onLanguage:javascript"：仅当打开.js文件时激活，适合语言类插件 -
"onCommand:extension.formatCode"：只在用户手动触发命令时加载，适合工具类插件（如coze-loop） -
"workspaceContains:**/tsconfig.json"：检测到项目含 TypeScript 配置才激活，比onLanguage:typescript更精准（避免误激活单个.ts临时文件）
如何验证某个插件是否真被延迟加载
光看 settings 里是否勾选“启用”没用。必须进命令面板执行 Developer: Show Running Extensions，观察目标插件的 Activation Time 和 Runtime 列：
- 如果
Activation Time是0或极小值（如2ms），说明它在 VSCode 启动时就加载了，activationEvents配置可能无效或被其他插件触发 - 如果
Runtime显示idle，且打开对应文件后才变成active，才是真正的懒加载成功 - 注意：部分插件（如
GitLens）默认监听onStartupFinished，即使你没开任何文件也会启动——这是设计使然，不是 bug
extensions.experimental.affinity 的实际作用边界
这个配置常被误解为“优先加载”，其实它只影响进程调度优先级：数值 1 表示强制在主进程运行（高开销、低隔离），5 表示推荐在扩展主机进程运行（默认，更安全），99 表示强制独立进程（极少用）。它不改变加载时机，也不解决冲突。
真正影响性能的是加载顺序和事件触发条件，而非 affinity 数值。盲目调高 affinity 反而可能因主进程阻塞导致编辑器卡死。
- 对 CPU 密集型插件（如大型 LSP 客户端），保持默认
5更稳 - 若某插件频繁崩溃，可尝试设为
99隔离，但会增加进程开销 - 永远不要为多个插件同时设
1，这等于把所有重活压给主进程
插件间 activationEvents 冲突的真实场景
两个插件都声明 "onLanguage:json"，VSCode 会按安装顺序依次激活——但若前者启动慢（比如要下载 schema），后者会被阻塞。更隐蔽的问题是：一个插件监听 "onStartupFinished"，另一个监听 "onLanguage:typescript"，结果前者一启动就拉起 TS 语言服务，导致后者还没等用户打开 .ts 文件，就已经被连带激活。
- 检查冲突：在命令面板运行
Developer: Toggle Developer Tools→ Console，过滤activation，看哪些事件被意外触发 - 典型冲突组合：
ESLint+Prettier+Auto Import都监听onDidOpenTextDocument，打开文件瞬间三者并发执行 - 解法不是删插件，而是用
files.associations把非核心文件类型映射为plaintext，从源头切断激活链
动态加载不是“装了再关”，而是从插件设计源头控制它的呼吸节奏。最易被忽略的点是：VSCode 的激活事件系统没有“取消订阅”机制，一旦触发，后续所有监听都会排队执行——所以第一个被激活的插件，往往决定了整个工作区的响应基线。
