能，但仅限于本地开发一致性和预检阶段；适合代码规范检查、自动加载优化、环境校验等轻量可复现操作，不能替代CI/CD，但可减少流水线中重复的基础准备动作。
Composer scripts 能不能替代 CI/CD 中的部分任务？
能，但仅限于「本地开发一致性和预检阶段」。Composer scripts 本质是 shell 命令的封装，运行在 PHP 进程启动前、依赖安装后或命令触发时，适合做代码规范检查、自动加载优化、环境校验这类轻量、可复现、不依赖外部服务的操作。它不是 Jenkins 或 GitHub Actions 的替代品，但能显著减少 CI 流水线中重复的「基础准备动作」。
-
composer install后自动执行php -d memory_limit=-1 vendor/bin/phpcs，比在 CI YAML 里每行写一遍更易维护 -
post-autoload-dump钩子里调用php artisan config:clear（Laravel）或bin/console cache:warmup（Symfony），避免部署后首次请求慢 - 不建议在
pre-install-cmd里拉取私有 Git 包或上传构建产物——权限、网络、超时都不可控
哪些钩子时机最实用？优先级怎么排？
按实际触发频率和稳定性排序：
-
post-autoload-dump：最可靠。每次composer dump-autoload或install/update后必执行，且类加载器已就绪，适合生成代理类、刷新缓存、校验接口实现 -
post-install-cmd和post-update-cmd：次之。注意二者行为差异：post-install-cmd只在全新安装时触发（vendor/不存在），而post-update-cmd在更新依赖时也执行，但可能因部分包未更新导致逻辑错乱 -
pre-autoload-dump：慎用。此时vendor/composer/autoload_*.php尚未生成，无法安全调用第三方库，仅适合清理旧缓存或检查 PHP 版本
脚本里调用其他 CLI 工具要注意什么？
路径、权限、退出码三者必须显式处理：
- 不要用
./vendor/bin/phpunit，改用vendor/bin/phpunit（相对路径在 Composer 执行时会被重置） - 所有脚本命令末尾加
&& exit ${?}，否则某个工具失败（如phpcs发现警告）但返回 0，后续步骤仍会继续 - 避免硬编码
/usr/local/bin/node，改用which node或直接写node，让系统 PATH 决定 - 如果脚本需要读取
.env，别指望getenv()自动生效——Composer 运行时不加载框架环境，得用phpdotenv显式加载，或改用$_SERVER['APP_ENV'] ?? 'dev'这类兜底值
为什么本地跑通的 scripts 在 CI 上总失败？
根本原因通常是环境假设不一致：
- 本地有全局安装的
php-cs-fixer，CI 里只靠vendor/bin/php-cs-fixer，但没声明为require-dev，导致命令不存在 -
post-root-package-install钩子里用了readline()等交互函数，CI 环境无 TTY，直接挂掉 - 时间区设置不同：脚本里用
date('Y-m-d')生成文件名，本地是 Asia/Shanghai，CI 是 UTC，导致缓存命中失败 - 某些脚本依赖
git命令获取当前分支，但 CI runner 拉取的是 shallow clone（--depth=1），git branch返回空
真正麻烦的从来不是写脚本，而是让同一段 scripts 在 dev、CI、prod 三种上下文里都保持语义一致——尤其是当某条命令在 prod 环境里被禁用（比如不允许执行 phpunit），又不能靠注释临时删掉。
