Composer如何配置自动化部署脚本_Composer自动化部署脚本配置实战-composer-PHP中文网

composer install 在部署机上失败主因是生产环境默认禁用 dev 依赖和脚本，导致 post-install-cmd 等钩子不执行；需显式启用或拆分关键逻辑到独立 script 并用 composer run-script 调用。

composer如何配置自动化部署脚本_composer自动化部署脚本配置实战

Composer install 为什么在部署机上总失败

因为生产环境默认禁用 dev 依赖和脚本，而很多自动化部署逻辑藏在 post-install-cmd 或 post-update-cmd 里。不显式启用，这些钩子根本不会执行。

实操建议：

部署时务必加 --no-dev --optimize-autoloader，但若脚本依赖 phpunit 或 infection 等开发工具，就得单独判断：把真正需要的命令拆到 scripts 段，并用 composer run-script xxx --no-dev 显式调用
检查 composer.json 中的 scripts 是否含 pre-* 类钩子——它们在 install 前触发，一旦失败整个流程中断，建议改用 post-*
CI/CD 环境变量（如 CI=true）可能影响某些包行为，可在脚本中加 if [ "$CI" = "true" ]; then ... fi 做兜底

如何让 Composer 自动执行部署后操作（如清缓存、生成配置）

靠 post-install-cmd 和 post-update-cmd 是最直接的方式，但要注意执行时机和权限边界。

常见错误现象：本地 composer install 能清 Laravel 缓存，上线后却报 Permission denied —— 因为部署用户和 Web 服务器用户不同，storage/ 目录权限没同步。

实操建议：

在 composer.json 的 scripts 里定义可复用的命令：

"scripts": {
  "deploy:post-install": [
    "@php artisan config:clear",
    "@php artisan cache:clear",
    "@php artisan view:cache"
  ]
}

部署脚本中调用：composer install --no-dev --optimize-autoloader && composer run-script deploy:post-install
避免在 scripts 中写绝对路径或硬编码环境判断；改用 php -r "echo getenv('APP_ENV') ?: 'prod';" 动态读取

vendor 目录要不要提交到 Git？怎么跳过某些包的安装

不提交 vendor/ 是标准做法，但有些私有包或构建产物（如前端打包后的 dist/）需要特殊处理。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

使用场景：你用 composer require myorg/private-bundle，但该包只提供 zip 下载，没有 packagist 入口，且含大量静态资源。

实操建议：

用 composer config repositories.myrepo artifact ./packages/*.zip 声明本地包源，再 require，避免每次拉 Git
跳过特定包安装：设 COMPOSER_IGNORE_PLATFORM_REQS=1 很危险；更安全的是在 composer.json 加 "platform-check": false（v2.2+），或对单个包用 "replace": {"ext-imagick": "*"}
若某包只用于开发构建（如 vite-plugin-php），确保它只在 require-dev 中，并在部署时用 --no-dev 彻底排除

部署脚本里调用 Composer 报 “Could not open input file: composer.phar”

说明当前环境没装 Composer，或装了但不在 $PATH。别急着全局安装——容器或无 sudo 权限的部署机上，应优先走局部加载。

实操建议：

在部署脚本开头加检测：if ! command -v composer &> /dev/null; then curl -sS https://getcomposer.org/installer | php -- --filename=composer --install-dir=. ; fi
后续所有调用统一用 php composer --version，而非 composer --version，规避 PATH 问题
如果用 GitHub Actions，别信 php-actions/composer 的默认行为——它会覆盖 COMPOSER_HOME，导致插件缓存失效；显式设 COMPOSER_HOME: ${{ github.workspace }}/.composer

真正容易被忽略的是：Composer 脚本里的 php 命令是否指向预期版本。线上常存在多个 PHP 版本，php -v 和 which php 结果可能不一致，建议在关键脚本开头加 #!/usr/bin/env php 并用绝对路径调用二进制（如 /opt/php82/bin/php）。