需在插件中使用 composer\util\outputhandler::getoutput()->write() 输出日志，而非 echo 或 var_dump；确保插件正确注册、实现 plugininterface、事件回调签名无误，并用 writeerror('[my-plugin]...') 标识日志便于 grep 过滤。
怎么让 Composer 显示插件内部的执行日志
Composer 默认隐藏插件（如 PluginInterface 实现类）的调试输出，-vvv 本身不自动透出插件里 echo 或 error_log 的内容。真正起作用的是 Composer 自身的日志通道——它只转发自己框架层的日志（比如命令调度、事件触发），不接管插件代码的 stdout/stderr。
实操建议：
- 在插件代码中改用
Composer\Util\OutputHandler::getOutput()获取 Composer 的输出实例，再调用write()或writeln()，这样日志才能被-vvv捕获并按级别显示 - 避免直接
echo "debug"或var_dump()，它们会被静默吞掉，或混在终端乱序输出里难以定位 - 如果插件监听了
post-install-cmd这类事件，确保事件回调函数签名正确，否则整个插件可能被跳过，-vvv里连“插件已加载”都看不到
为什么 -vvv 有时没反应，或者只看到部分插件日志
常见错误现象：运行 composer install -vvv，但插件里的调试信息完全不出现，甚至插件根本没被执行。
原因和应对：
- 插件未被正确注册：检查
composer.json中是否在require里声明了插件包，并确认该包的extra.installer-types或type: composer-plugin设置无误 - 插件类未实现
Composer\Plugin\PluginInterface，或activate()方法抛了异常——此时 Composer 会静默禁用插件，-vvv只会显示 “Skipped plugin … due to errors”，不会打印异常堆栈 -
-vvv日志等级只影响 Composer 自身行为（如远程请求头、依赖解析步骤），不改变插件代码的执行逻辑；插件若在deactivate()阶段出错，也不会被记录
如何验证插件是否真的被加载并响应事件
光看 -vvv 输出不够，得主动探测插件生命周期。
实操建议：
- 在插件的
activate()方法第一行加一句：$io->writeError('<info>[DEBUG] Plugin activated</info>');，writeError()能绕过输出缓冲，强制刷到终端 - 监听
CommandEvent时，打印$event->getCommandName()，确认是不是你预期的命令（比如install而不是update） - 用
composer show --plugins查看已激活插件列表，如果插件不在其中，说明加载失败，这时候再查vendor/composer/autoload_plugins.php里有没有对应条目
-vvv 下插件日志和 Composer 主流程日志混在一起，怎么区分
默认情况下，所有输出都是平铺的，插件日志和 Composer 解析器日志穿插出现，很难追踪一条完整链路。
关键技巧：
- 在插件日志前统一加标识，比如：
$io->writeError('[my-plugin] Doing X...');，后续用grep '\[my-plugin\]'过滤 - 避免在
activate()里做耗时操作（如远程请求），否则会卡住整个 Composer 启动流程，-vvv会停在 “Loading config” 后不动，让人误以为卡死 - 注意 PHP 版本兼容性：低版本 Composer（-vvv 里也看不到任何痕迹
插件调试最麻烦的点往往不在日志开关，而在于 Composer 加载机制本身不透明：它用反射动态实例化类、用静态数组缓存插件状态、事件分发不抛异常。一旦某个环节断了，-vvv 就只剩静默。
