Composer插件需同时满足type为composer-plugin、正确autoload及install/update触发三条件才生效；仅require不激活，须检查composer show输出的types字段、autoload映射、getCommands()实现及缓存清理。
Composer 插件不会因为 composer require 就自动生效，必须满足类型声明、自动加载、安装触发三重条件，缺一不可。
怎么确认一个包是不是真正的 Composer 插件
只看包名或文档说“支持 Composer”没用，关键看它是否被 Composer 主进程识别为插件：
- 运行
composer show vendor/package-name，检查输出中是否有types : composer-plugin - 没有这个字段，哪怕代码里有
Plugin类、实现了PluginInterface，Composer 也完全忽略 - 常见伪插件：如
phpunit/phpunit、phpstan/phpstan，它们只是普通依赖，靠bin字段注册命令，不是插件 - 私有仓库的包若未在
repositories中声明，composer require会报Package not found，不是插件问题，是源不可见
为什么 composer require 后插件没反应
composer require 只改 composer.json 和 composer.lock，不加载、不实例化插件。真正激活发生在 install 或 update 阶段：
- 执行
composer require vendor/plugin-name后，必须紧接着运行composer install（或composer update vendor/plugin-name） - 插件类必须能被自动加载：检查其
composer.json中autoload（尤其是psr-4）是否映射到含Plugin类的命名空间 - 插件构造函数不能依赖未解析的服务（如
Composer\IO\IOInterface以外的参数），否则静默失败——无报错，但不注册 - 修改插件代码后，需删掉
vendor/composer/autoload_psr4.php和vendor/composer/autoload_classmap.php，再运行composer dump-autoload -o，否则旧类路径仍生效
插件生效了但自定义命令不出现（如 composer xxx）
插件加载成功 ≠ 命令注册成功。命令暴露是独立逻辑：
- 插件类必须实现
getCommands()方法，且返回非空数组，每个元素是Composer\Command\Command实例（通常继承Composer\Command\BaseCommand） - 运行
composer list查看命令是否列出；没出现说明getCommands()没被调用或返回空 - 某些插件需额外配置才能启用命令，例如在项目根
composer.json的extra字段中加开关（查插件文档） - 命令类若引用了未 autoload 的辅助类（比如在
src/外写了Command），也会导致命令注册失败，但无明确提示
本地开发调试插件时最常卡在哪
插件行为高度依赖 Composer 运行时状态，本地改完代码却没效果，90% 是缓存和加载链没断干净：
- Composer 不检测文件变更，
composer update不会重载已加载的插件类——必须删掉vendor/composer/autoload_*.php并重建 - 改了
composer.json中的autoload映射后，不运行composer dump-autoload -o，新路径永远不会进自动加载器 - 插件类若依赖其他插件或扩展（比如需要
composer-plugin-api版本 ≥2.4），而当前 Composer 版本低，会跳过加载，但不报错 - 用
composer install --no-dev测试时，如果插件被错误地放在require-dev里，它根本不会被加载——插件必须在require中
插件机制本身不复杂，但所有环节都静默失败：没声明 type、autoload 错路径、getCommands() 返回空、甚至 PHP 版本不匹配，都只会表现为“没反应”。排查时优先看 composer show 输出和 composer list 结果，比猜更可靠。
