post-update-cmd 要稳定执行需同时满足三条件：composer.lock 实际变更、"post-update-cmd" 键名精确配置在 scripts 下、所有脚本退出码为0；推荐用数组格式定义命令、使用@php避免PHP版本错配、敏感操作移至独立PHP文件处理。
不用每次更新都手动配——post-update-cmd 和 post-autoload-dump 这两个钩子，只要配对、写对、触发条件满足，就能稳定自动执行。问题不在“能不能”，而在“为什么你配了却没跑”。
post-update-cmd 为什么经常“不执行”
它不是“只要 run update 就跑”，而是必须同时满足三个硬性条件：
- 实际修改了
composer.lock（比如依赖版本变了、新增包、移除包）； -
"post-update-cmd"键名精确写在composer.json的"scripts"对象下，不能错拼成postUpdateCmd或漏掉-cmd后缀； - 脚本自身退出码是
0；任意一条命令返回非零（比如php artisan migrate找不到数据库），整个 Composer 命令就会中止，后续命令也不执行。
验证是否触发？加 -v 参数运行：composer update -v，看输出里有没有 Executing script 行。
用数组写命令，别用字符串
字符串形式如 "php artisan cache:clear" 看似简洁，但 shell 解析时容易出问题：路径含空格、引号嵌套、环境变量未展开，都会静默失败。
推荐始终用数组格式：
"post-update-cmd": [ ["App\ComposerScripts", "runMigrations"], ["@php", "artisan", "optimize: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
@php 是关键，别裸写 php
钩子里写 php artisan 很危险：它走系统 PATH，可能调用到和 Composer 不同版本的 PHP（比如 Composer 用的是 php8.2，而 php 指向 php7.4），导致扩展缺失或语法报错。
改用 @php：
- 它是 Composer 内置快捷方式，自动复用当前运行 Composer 的 PHP 可执行文件路径；
- 配合
@php -d memory_limit=-1可绕过内存限制，避免缓存预热 OOM； - 路径以项目根目录为基准，
@php scripts/deploy.php就行，别写./scripts/deploy.php。
敏感操作记得加 --no-interaction --force，比如 @php artisan migrate --no-interaction --force，否则卡在确认提示上。
别把高风险操作塞进钩子
post-update-cmd 是同步阻塞执行的，它会拖慢每一次 composer update 流程。以下操作尤其要小心：
- 远程 API 调用（网络超时直接卡住）；
- 全量测试（本地开发机上等 5 分钟？）；
- 数据库迁移（生产环境必须显式加
--force，且应检查$_ENV['APP_ENV']）； - 暴力删目录（比如
rm -rf vendor/cache），有些框架缓存（如 Laravel 的compiled.php）强依赖vendor/结构，删错会导致 autoload 失败。
真正稳妥的做法，是调用框架原生命令（如 @php artisan optimize:clear），它知道该清什么、不该碰什么。钩子只是触发器，逻辑收口到独立 PHP 文件里才可控、可测、可 debug。
