composer插件必须满足"type": "composer-plugin"、extra中声明入口类、require包含"composer-plugin-api"三条件才被激活；仅require不生效，须通过install/update加载，且需实现plugininterface并正确配置autoload。

Composer插件不是“装上就用”的普通包，它必须被 Composer 主进程识别、加载并激活——只执行 composer require 不会触发任何插件逻辑，必须配合 composer install 或 composer update 才能生效。

怎么确认一个包是不是真正的 Composer 插件

插件身份由 composer.json 中的 "type": "composer-plugin" 字段硬性决定。其他一切（类名、接口实现、文档说明）都无效，除非这个字段存在。

• 运行 composer show vendor/package-name，检查输出中是否包含 types : composer-plugin
• 若没有，哪怕代码里有 PluginInterface 实现，Composer 也完全忽略它
• 常见误判：把提供 CLI 工具（如 phpunit）或辅助函数的包当成插件——它们只是普通依赖，靠 bin 字段注册可执行文件，不参与 Composer 生命周期

为什么 composer require 后插件没反应

require 只改 composer.json 和 composer.lock，不加载、不实例化插件。真正加载发生在 install 或 update 阶段，且依赖三个条件同时满足：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• "type": "composer-plugin" 已声明
• "extra": { "class": "My\Plugin" } 指向的类存在，且命名空间与 autoload 配置严格匹配
• 该类实现了 ComposerPluginPluginInterface（注意命名空间是 ComposerPlugin...，不是 ComposerEventDispatcher...）
• 类的 activate() 方法不能有未解析的构造函数参数，否则 Composer 启动时静默失败（无报错，但插件不注册）

插件生效了但自定义命令不出现（比如 composer xxx）

插件加载 ≠ 命令注册。要让新命令出现在 composer list 中，必须额外实现 getCommands() 方法：

• 插件类需同时实现 ComposerCommandCommandProviderInterface
• getCommands() 必须返回一个 ComposerCommandCommand 实例数组（例如继承自 ComposerCommandBaseCommand）
• 命令类内部可通过 $this->getComposer() 和 $this->getIO() 访问上下文
• 运行 composer list | grep xxx 验证是否列出；没出现说明插件虽加载成功，但命令未暴露

本地开发调试时插件不更新

Composer 缓存插件实例，不会自动感知文件变更。改完代码后最常卡在这几步：

• 删掉 vendor/composer/autoload_psr4.php 和 vendor/composer/autoload_classmap.php，强制重建 autoloader
• 执行 composer dump-autoload -o 确保新路径生效
• 必须重新运行 composer install（不是 require），否则旧版本仍驻留在内存中
• 如果插件在本地路径开发（"type": "path"），记得检查 repositories 是否指向正确目录，且该目录下有合法的 composer.json

最容易被忽略的是 autoload 路径和 extra.class 的命名空间一致性——差一个反斜杠、少一级目录，插件就会彻底静默失效，连错误提示都没有。