Composer插件启用唯一依赖"type": "composer-plugin"，provide字段仅影响依赖解析，不触发插件加载或activate()调用。
Composer 本身不提供“虚拟包”作为插件架构的官方机制；所谓“用虚拟包实现插件架构”，其实是对 composer-plugin 类型包与 provide 字段误读或过度延伸的结果。真正起作用的是插件类型声明 + 接口实现 + 事件订阅，不是靠虚拟包（virtual package）触发加载。
为什么 provide 字段不能激活插件逻辑
provide 只用于声明“本包提供了某个抽象包的能力”，比如 "psr/log": "^2.0"，它影响依赖解析和冲突检测，但不会导致类自动加载、接口实现或 activate() 调用。即使你在插件的 composer.json 中写：
{"provide": {"my-vendor/my-plugin-interface": "1.0"} }
这也不会让 Composer 把它当插件处理——只要 "type": "composer-plugin" 缺失，整个包就只是个普通依赖，extra.class 被忽略，PluginInterface 不会被检查。
type: composer-plugin 是唯一生效入口
Composer 加载插件的判断逻辑非常明确：只扫描所有已安装包中 "type": "composer-plugin" 的那些，并尝试从其 extra.class 指定的类名实例化对象，再验证是否实现 Composer\Plugin\PluginInterface。其他任何字段（包括 provide、replace、conflict）都不参与该流程。
- 没设
type→ 插件类永远不会被实例化，activate()永远不执行 -
extra.class指向的类不存在或命名空间不匹配 → Composer 报错Class not found并跳过该插件 - 类存在但没实现
PluginInterface→ Composer 静默忽略，不报错也不激活
常见混淆场景：用 provide 声明“插件能力”反而破坏兼容性
有些开发者试图用 provide 让多个插件“互斥”或“可选替代”，例如：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
{"provide": {"acme/composer-hook-system": "1.0"}}
这会导致依赖解析时把提供该能力的任意包都视为满足条件，可能意外替换掉真正需要的插件，尤其在 composer update 时引发不可控行为。更严重的是，如果两个插件都 provide 同一个虚拟名，Composer 可能只选其一，而另一个的 activate() 根本不会运行——你以为装了两个插件，其实只有一个生效。
真实项目中应避免这种设计。插件启用与否，应由项目 require 显式控制，而不是靠 provide 触发隐式替换。
想解耦插件接口？用正式的 interface 包，别用虚拟包
如果你希望定义一套插件契约（比如多个团队开发不同插件但遵循同一事件规范），正确做法是：
- 单独发布一个
acme/composer-plugin-contract包，其中只含interface和EventSubscriberInterface扩展 - 各插件包
require它，并在activate()中调用$dispatcher->addSubscriber($this) - 主项目通过
require明确引入所需插件，不依赖provide推导
这样既保持类型安全，又避免 Composer 解析器因虚拟包语义模糊而做出错误决策。真正的扩展点永远在 PluginInterface::activate() 和事件订阅里，不在 provide 字段中。
