Composer插件需声明"type": "composer-plugin"、实现PluginInterface并正确配置autoload，仅require不生效，必须install/update后才能加载；提供命令还需实现getCommands()方法。
Composer 插件不是靠“安装”来扩展功能的，而是通过 composer install 或 composer update 自动加载并启用的——前提是它被正确声明为插件，并满足 autoload 和 plugin 类型约束。
怎么判断一个包是不是 Composer 插件
插件必须在 composer.json 中明确声明 "type": "composer-plugin"，且实现 Composer\Plugin\PluginInterface。只靠 require 一个包，不等于它就会生效。
- 运行
composer show vendor/package-name，检查输出里是否有types : composer-plugin - 如果没写
type，哪怕代码里有 Plugin 类，Composer 也完全忽略它 - 常见伪插件：只是提供命令行工具（如
phpunit）或辅助函数的包，它们不是插件，只是普通依赖
为什么 composer require 后插件没反应
插件需要被 Composer 主进程识别并实例化，这个过程发生在 install/update 阶段，而不是 require 命令本身。而且插件必须能被自动加载。
-
composer require vendor/plugin-name只是写入composer.json和composer.lock - 必须紧接着执行
composer install（或composer update vendor/plugin-name），插件类才会被注册 - 确保插件的
autoload配置正确，特别是psr-4映射到含Plugin类的命名空间 - 插件类不能有构造函数依赖未解析的参数，否则 Composer 启动时会静默失败（无报错，但不生效）
插件生效但命令没出现（比如 composer xxx）
插件要提供自定义命令，必须实现 getCommands() 方法并返回 Composer\Command\Command 实例数组。光注册插件 ≠ 注册命令。
- 检查插件源码中是否重写了
getCommands()，且返回非空数组 - 确认命令类继承了
Composer\Command\BaseCommand（或兼容的基类） - 运行
composer list查看命令是否列出；若没有，说明插件虽加载成功，但未正确暴露命令 - 某些插件需额外配置（如在根项目
composer.json中加"extra"字段）才能启用特定功能
本地开发调试插件时最常卡在哪
插件代码改了，composer update 却没触发重载——因为 Composer 缓存了插件实例，且不会自动检测文件变更。
- 删掉
vendor/composer/autoload_psr4.php和vendor/composer/autoload_classmap.php强制重建 autoloader - 用
composer dump-autoload -o确保新类路径生效 - 插件类修改后，必须重新运行
composer install（不是require），否则旧版本仍驻留在内存中 - 调试时加
echo或error_log到activate()方法开头，比看文档更快定位是否加载
插件机制依赖 Composer 的生命周期钩子和 autoloading 精确性，错一个环节就静默失效；与其反复试 require，不如先确认 type、autoload、getCommands() 这三处是否都对得上。
