Composer事件监听需通过EventSubscriber接口实现插件，而非scripts脚本；插件须设"type":"composer-plugin"，在activate()中注册订阅者，监听PrePackageInstallEvent等可干预事件，调试需用composer show --plugins验证加载。
Composer 的事件监听靠的是 EventSubscriber 接口，不是钩子脚本
很多人以为在 composer.json 里写 "scripts" 就算监听事件了，其实那只是命令执行前后的简单回调；真要拦截、响应或干预安装/更新流程（比如自动清理缓存、校验包签名、生成 autoload 映射快照），必须实现 EventSubscriber 接口并注册为插件。Composer 自身的事件机制是基于 Symfony EventDispatcher 的，只有插件能订阅核心事件（如 PackageEvents::PRE_INSTALL_CMD）。
-
EventSubscriber必须放在一个独立的 Composer 插件包里（即含composer.json且"type": "composer-plugin"） - 插件主类需实现
Composer\Plugin\PluginInterface，并在activate()中通过$eventDispatcher->addSubscriber(new MySubscriber())注册 - 不能直接在项目根目录写个类然后 require 进来——Composer 插件加载阶段早于项目 autoloader 初始化
哪些事件真正可监听且有实际干预能力
不是所有事件都允许修改行为。CommandEvent 类型（如 PreInstallCommandEvent）只读，适合日志或准备动作；真正能“介入流程”的是 InstallerEvent 和 PackageEvent 子类，但注意：Composer 2.x 起多数安装逻辑已移入异步队列，PostInstallEvent 触发时包文件早已写入 vendor/，想阻止某个包安装？只能在 PrePackageInstallEvent 里抛出 RuntimeException。
- 推荐监听：
PrePackageInstallEvent（可 abort）、PostAutoloadDumpEvent（可改生成的 autoload 文件）、ScriptExecutionEvent（比 scripts 更早，可劫持脚本参数） - 慎用：
PostInstallEvent—— 此时 vendor 已落盘，hook 仅剩“善后”意义 - 别碰：
PreFileDownloadEvent等底层事件——文档未公开、接口不稳定、v2.2 后部分已被废弃
插件加载失败的典型错误和定位方法
插件没生效，90% 是因为 Composer 根本没加载它。最常见原因是插件包未被识别为插件类型，或者依赖版本冲突导致 autoloader 加载失败。Composer 不报错，只默默跳过，这点特别坑。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 检查插件的
composer.json是否含"type": "composer-plugin"和"require": { "composer-plugin-api": "^2.0" } - 运行
composer show --plugins，确认插件出现在列表里；如果没出现，说明未被发现或加载失败 - 加调试：在插件
activate()开头写file_put_contents('/tmp/plugin-activated', 'yes');，再执行composer install，看文件是否生成 - 注意 PHP 版本兼容性：插件代码若用了
match或??=，而宿主项目用 PHP 7.4，就会静默失败
EventSubscriber 实现里最容易漏掉的细节
写一个 getSubscribedEvents() 返回数组看似简单，但键名拼错、事件类引用错、或没处理 static 上下文，都会让监听完全失效，而且毫无提示。
- 事件名必须用全限定类名字符串：
'Composer\Script\Event' => 'onScript'，不能写成'ScriptEvent'或小写 - 回调方法必须是
public，且参数类型提示要严格匹配（例如PrePackageInstallEvent $event），否则 Symfony Dispatcher 会跳过调用 - 不要在回调里直接 echo/print_r —— Composer 可能已关闭 stdout，输出会被丢弃；用
$io->writeError()才能确保看到 - 如果需要访问当前项目配置，别用
Factory::createConfig()，而要用$event->getComposer()->getConfig()，否则拿到的是默认配置而非项目级配置
插件机制本身不复杂，但 Composer 的加载时机、事件分发链路、以及静默失败策略，会让调试变成一场路径排查游戏。最稳的做法：先确保 composer show --plugins 能看到你的插件，再往 getSubscribedEvents() 里加一个最简单的事件，用 $io->writeError() 打点，最后才动业务逻辑。
