run-script 不触发事件钩子，仅执行 scripts 中定义的命令；需改用 install/update 等原生命令或手动串联 @ 脚本；&& 实现错误中断，; 则强制执行；脚本按 JSON 数组顺序运行且短路处理；pre-* 阶段不可依赖 autoload.php；调试推荐 --verbose 和 echo "$PWD" >&2。
run-script 命令本身不触发事件，只执行脚本定义体
很多人以为 composer run-script build 会像 composer install 那样自动触发 pre-build 和 post-build，其实不会。它只运行 scripts.build 字段里写的命令，前后钩子完全不激活。
这是最常被误解的一点：Composer 的事件（如 pre-install-cmd）只在对应命令执行时由 Composer 内部调度，而 run-script 是“手动调用”，属于旁路操作。
- 想走事件流？改用
composer install或composer update等原生命令，并在scripts中注册对应事件钩子 - 想保留
run-script但手动补全流程？得自己在scripts.build里显式写"@php build.php && @composer run-script post-build" - 注意
@前缀：它让 Composer 把后续字符串当作内部脚本名解析，而不是 shell 命令；没加@就是直接交给 shell 执行，无法触发其他脚本
多个脚本串联时，&& 和 ; 的行为差异直接影响错误中断
在 scripts 中写 "php compile.php && php minify.php" 和 "php compile.php; php minify.php" 看似差不多，但失败处理完全不同：
-
&&：前一个命令退出码非 0（比如编译失败），后一个根本不会执行 —— 这是多数人想要的“阻断式”流程 -
;：不管前一个是否成功，后一个照常运行 —— 容易掩盖问题，比如压缩一个根本不存在的文件 - Composer 默认把每个脚本当独立进程执行，所以
set -e或set -o pipefail在 shell 脚本里有效，但在 JSON 的scripts字段中无效，别指望它能跨命令生效
自定义事件优先级由 composer.json 中声明顺序决定，但仅限同一事件类型
Composer 不支持给 pre-install-cmd 里的多个脚本设执行序号或权重。它按 composer.json 里数组顺序依次执行：
"scripts": {
"pre-install-cmd": [
"@clean-cache",
"php check-env.php",
"@build-config"
]
}
上面三个会严格按这个顺序跑。但要注意：
- 如果
check-env.php失败（exit code ≠ 0），后续@build-config不会执行 —— Composer 对事件内脚本也做短路处理 - 不同事件之间没有隐含顺序，比如
pre-install-cmd总在install前，但你不能假设pre-install-cmd一定在pre-autoload-dump之前，因为后者属于另一条事件链，触发时机不同 - 不要在
pre-*里依赖vendor/autoload.php—— 此时 autoloader 可能还没生成，require会失败
调试脚本执行路径最有效的办法是加 --verbose 和临时 echo
Composer 不提供类似 bash -x 的逐行追踪，但 --verbose（或 -v）能暴露真实执行命令和当前工作目录：
composer run-script build -v
输出里会出现类似：
Running script php build.php $ cd /path/to/project && php build.php
这时就能确认是否在预期目录下执行、环境变量是否就位。更直接的办法是在脚本开头加：
echo "PWD: $(pwd)" >&2 echo "PHP_BINARY: $PHP_BINARY" >&2
注意重定向到 &2（stderr），避免和脚本正常输出混在一起；另外，composer run-script 默认不继承父 shell 的所有环境变量（比如自定义的 MY_ENV），需要显式传入：MY_ENV=prod composer run-script build。
实际项目里，顺序乱往往不是 Composer 机制问题，而是没分清「命令驱动」和「事件驱动」两条路径，或者忽略了 shell 运算符的语义边界。
