post-install-cmd 仅在 composer install 且 composer.lock 不存在或过期时触发；composer require 触发 post-update-cmd；post-update-cmd 在 autoload dump 前执行，post-autoload-dump 更适合类初始化；post-package-install 不可靠，应避免使用。
post-install-cmd 不会在“安装插件”时触发
很多人以为 composer require some/package 是一次“安装”，所以 post-install-cmd 会跑——其实不会。这个命令本质是先改 composer.json，再执行 composer update some/package，触发的是 post-update-cmd，不是 post-install-cmd。
真正走 post-install-cmd 的场景只有：composer install 且 composer.lock 不存在、或内容过期需重生成（比如删了 lock 文件、或改了 require 后再 install）。
-
composer require→ 触发post-update-cmd（如果配置了） -
composer install（首次/lock 变更）→ 触发post-install-cmd -
composer install（vendor 存在、lock 完全匹配）→ 不触发任何脚本（除非加--scripts）
post-update-cmd 和 post-autoload-dump 谁先执行？
post-update-cmd 在依赖下载、解包、写入 vendor/ 后立即执行；post-autoload-dump 则必须等 vendor/autoload.php 重建完成才触发——也就是说，它一定在 post-update-cmd 之后，且只要 autoload 有更新就必跑（哪怕只改了 autoload 配置、没动依赖）。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 执行顺序固定为：
post-update-cmd→autoload dump→post-autoload-dump - 如果你的脚本要读取新装包里的类，别在
post-update-cmd里直接new SomeClass()，因为 autoloader 可能还没刷进去；改用post-autoload-dump更稳妥 -
post-autoload-dump也响应composer dump-autoload，适合做纯 PHP 初始化（如注册自定义加载器、生成运行时配置）
post-package-install 几乎不可靠，别依赖它
post-package-install 名义上是“某个包装完就触发”，但实际只在 composer update 过程中部分操作路径下被调用，且 $event->getOperation() 返回的 InstallOperation 实例经常为 null 或字段为空。官方文档不推荐使用，Composer 自身也未保证其稳定性。
- 它不触发于
composer require的常规流程（因内部用了UpdateCommand的简化路径） - 无法可靠获取刚安装包的版本、源类型（dist vs source）、安装路径
- 替代方案：用
post-update-cmd+ 解析vendor/composer/installed.json，或监听post-autoload-dump后检查类是否存在
钩子执行失败会导致整个命令中断
所有以 -cmd 结尾的钩子（如 post-install-cmd）默认是“阻塞式”的：任一命令退出码非 0，后续命令和 Composer 主流程都会中止。这点和 post-autoload-dump 不同——后者失败不影响 autoload 文件生成。
- Shell 命令记得加
|| true消除非关键错误（如cp .env.example .env || true） - PHP 回调方法必须显式
exit(0)或返回布尔值，否则异常未捕获会直接中断 - CI 环境尤其要注意：有些命令（如
php artisan key:generate）在无配置时会报错退出，得提前检查.env是否存在
post-update-cmd 做轻量文件复制与检查，post-autoload-dump 做类相关初始化，彻底绕开 post-package-install 这个坑。钩子不是万能胶，时机和可靠性比“看起来能用”重要得多。 
