post-update-cmd 仅在 composer.lock 被实际修改时触发，需满足三条件：执行 update（或带 --with-dependencies 的 install）、键名正确置于 scripts 下、脚本 exit code 为 0；推荐用数组格式定义命令，避免 shell 解析问题，并注意与 post-autoload-dump 的触发时机差异。
post-update-cmd 不会在每次 composer install 时运行，只在 composer.lock 实际被修改后才触发；配置错位置、命令失败退出、或误以为它等同于 post-install-cmd，是导致它“不工作”的三大主因。
post-update-cmd 触发条件很严格
它不是“只要 run update 就执行”，而是必须同时满足三个条件：
-
composer update（或带--with-dependencies的install）真正改写了composer.lock -
"post-update-cmd"键名精确写在composer.json的"scripts"对象下（不能在config或顶层） - 脚本本身 exit code 为 0；否则整个 Composer 命令会中止——CI 环境里这点常导致流程卡死
常见假阴性：你只跑 composer install，vendor 已存在且 lock 没变，那 post-update-cmd 根本不会被调用。验证是否触发？加 -v 参数看输出里有没有 Executing script 行。
脚本值写成数组比字符串更安全
用字符串如 "php artisan migrate" 看似简单，但 shell 解析可能出问题（比如含空格的路径、引号嵌套）。推荐始终用数组格式：
"post-update-cmd": [ ["App\ComposerScripts", "runMigrations"], ["php", "artisan", "cache:clear"] ]
这样每条命令都是独立进程，参数不经过 shell，也方便调试。如果用 PHP 类方法，注意类必须能被自动加载（即已声明在 autoload 里），且方法签名要接受一个 $event 参数（ComposerScriptEvent 实例）。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
别在脚本里做耗时或不可靠操作
post-update-cmd 是同步阻塞执行的，它拖慢的是开发者的每一次 composer update 流程：
- 避免下载远程资源、跑全量测试、或调用外部 API
- 数据库迁移这类高风险操作，务必加环境判断（如检查
$_ENV['APP_ENV']），生产环境必须显式加--force - 清理缓存可以做，但别用
rm -rf vendor/cache这种暴力方式——有些包缓存（如 Laravel 的 compiled.php）依赖 vendor 结构，删错目录会导致后续 autoload 失败
更稳妥的做法是调用框架原生命令，比如 php artisan optimize:clear，它知道该清什么、不该碰什么。
和 post-autoload-dump 的区别常被混淆
这两个钩子常被日志混在一起看，但行为完全不同：
-
post-update-cmd：只在composer update导致 lock 变更后执行一次 -
post-autoload-dump：每次composer install/update后只要 autoloader 文件被重生成就会触发（包括增删包、改autoload配置）
如果你要做的事跟类加载强相关（比如生成代理类、扫描注解），优先用 post-autoload-dump；如果只是“更新完依赖后顺手干点事”，才选 post-update-cmd。两者可共存，但别指望它们执行时机一致。
