Composer怎么配置自动脚本 Composer自动化运维工作流

生产环境部署时 post-install-cmd 不执行，不是脚本写错了，而是默认被跳过。 因为 Composer 在 --no-dev 模式下会同时禁用所有 scripts（包括 post-* 钩子），除非显式启用或改用 composer run-script 手动触发。

为什么线上部署时 post-install-cmd 总会静默失败？本地跑 composer install 能清缓存、生成配置，放到 CI/CD 流水线里就无声无息地跳过——这背后其实是一个很常见的配置盲区。根本原因在于：生产部署通常带 --no-dev 参数，而 Composer v2+ 默认在该模式下忽略所有 scripts，哪怕它们老老实实写在根 composer.json 里也不会被触发。

post-install-cmd 为什么上线后不运行

这里有几个容易踩的点需要捋清楚：

• 检查是否误加了 --no-scripts：这个参数会彻底关闭所有钩子，连 post-update-cmd 也一并失效，比想象中更常见。
• post-install-cmd 只在 composer install 成功后触发，但如果 lock 文件缺失或 vendor 目录已经存在，它可能根本不会进入 install 流程。
• CI 环境中 .git 目录经常被裁剪（shallow clone），导致 post-install-cmd 里依赖 .git 的逻辑（比如复制 git hooks）直接报错，而且报错信息往往不直观。

scripts 字段必须放在根 composer.json 顶层

很多人习惯把 scripts 嵌套进 extra 或 config 里，或者干脆写在某个依赖包的 composer.json 中——这些都不会生效。Composer 只认项目根目录下 composer.json 的顶层 scripts 对象，这一点没有回旋余地。

• 支持的 key 必须是标准事件名：post-install-cmd、post-update-cmd、post-root-package-install、post-create-project-cmd。自定义脚本名（如 deploy:clear-cache）不会自动触发，只能靠 composer run-script deploy:clear-cache 显式调用。
• 数组值按顺序执行，字符串值会被 shell 解析——如果命令里含空格或引号，建议拆成数组项，否则解析结果可能出乎意料。

执行权限和路径问题比想象中更常见

php artisan cache:clear 在本地跑得顺风顺水，部署时却抛出 Permission denied——大概率不是代码问题，而是用户、路径或 PHP CLI 配置不匹配。

• 脚本始终在项目根目录执行，可 storage/ 目录的属主可能是 www-data，而部署用户是 deploy，不提前处理就会炸。一个稳妥的做法是在部署脚本里加 chown -R deploy:www-data storage/。
• 避免直接用 php artisan，改成 php ./artisan 或 php -d memory_limit=-1 ./artisan，防止 CLI 的 php.ini 覆盖 web 配置，导致内存限制或扩展加载出问题。
• 别依赖当前 shell 的 $PATH，比如 chmod 可能找不到，写死 /bin/chmod 更稳妥。

复杂逻辑务必抽离为独立 PHP 文件

脚本里写一长串 find | xargs php -l 或嵌套一堆 if 判断，在 Windows CI 或低权限容器里基本不可靠。PHP 回调方法又要求类可被 autoload，容易因加载顺序出错，得不偿失。

• 最稳定的做法：写一个 scripts/deploy.php，开头 require __DIR__.'/../vendor/autoload.php';，然后把所有逻辑封装进去。
• 在 composer.json 里调用 "php scripts/deploy.php" 即可。这样做的好处是：完整利用 PHP 生态——异常捕获、日志、配置读取全都能用，还完全规避了 shell 兼容性和环境变量污染的问题。

真正难的不是写脚本，而是让同一段命令在本地开发、CI 构建、Docker 部署、线上服务器四个环境里都稳定跑通。路径、权限、用户、PHP 配置、Git 状态——任何一个变量没对齐，post-install-cmd 就会变成“看起来写了，其实没跑”的幽灵逻辑。