Composer如何配置脚本仅在特定条件执行_Composer脚本特定条件执行配置大全

Composer脚本无法原生支持条件判断，因scripts字段仅将字符串交由系统shell执行，而CI中环境变量未导出、Windows语法不兼容、autoload未加载等问题导致if语句失败；应改用PHP回调函数显式检测环境变量并控制流程。

先说一个核心结论：Composer脚本本身不具备原生的条件判断能力。** 这意味着，你无法在 `composer.json` 里直接配置“仅当 `APP_ENV=prod` 时才执行”这样的逻辑。所有条件判断，都必须由脚本自身来实现，而不是指望Composer能帮你自动解析和跳过。

为什么 scripts 字段里写 if [ "$APP_ENV" = "prod" ]; then php artisan down; fi 会失败

问题出在理解偏差上。Composer的 `scripts` 字段并非一个shell解释器，它只是把配置的字符串当作命令，原封不动地交给系统shell去执行。听起来好像一样？但魔鬼藏在细节里。实际运行时，你会遇到一连串的“意外”：

• 环境变量“失踪”：在CI/CD流水线中，你设置的 `APP_ENV` 环境变量很可能没有导出到Composer启动的子shell里，导致 `$APP_ENV` 展开后是个空值，条件判断自然失效。
• 平台语法“打架”：你写的Bash语法 `if [ ... ]`，在Windows环境下基本会直接报错退出，因为默认的CMD或PowerShell根本不认这套语法。
• 运行时环境“未就绪”：Composer在执行脚本时，默认并不会加载你项目的 `autoload.php` 文件。这意味着，即便你在脚本里尝试用PHP的 `$_ENV` 或 `getenv('APP_ENV')` 来读取，也可能什么都拿不到。
• 错误码“误判”：就算你费尽心思写成 `sh -c "if [ ... ]"`，shell条件语句的退出码（0成功，1失败）会被Composer直接当作整个脚本的成功或失败标志，可能导致后续命令被意外中断，或者静默跳过。

看，试图在脚本字符串里嵌入shell条件判断，就像在沙滩上盖房子，基础太不牢靠了。

用 PHP 回调 + 显式环境检测替代 shell 条件语句

那可靠的方法是什么？答案是：把判断逻辑收口，放到一个能被Composer自动加载的PHP类方法里。 让PHP代码在运行时显式地检测环境，并决定后续动作。这才是正道。

• 第一步：确保类可被加载。将你的工具类注册到 `composer.json` 的 `autoload["psr-4"]` 配置中，例如：`"App\Scripts\": "src/Scripts/"`。
• 第二步：遵循固定签名。这个类方法必须是 `public static`，并且接受一个 `Composer\Script\Event` 类型的参数。
• 第三步：安全地获取环境变量。不要依赖 `$_SERVER` 或 `$_ENV`，它们可能为空。更推荐使用 `getenv('APP_ENV')`，或者通过事件对象获取配置：`$event->getComposer()->getConfig()->get('platform') ?? []`。
• 第四步：妥善控制流程。想跳过执行？直接 `return` 即可。避免使用 `exit(0)`，这可能会干扰Composer自身的流程。

来看一个具体例子。在 `composer.json` 中这样配置：

"post-autoload-dump": "App\\Scripts\\EnvGuard::checkAndDown"

对应的PHP类方法实现如下：

public static function checkAndDown(Event $event): void
{
    if (getenv('APP_ENV') !== 'prod') {
        $event->getIO()->writeError('Skipped: not in production');
        return;
    }
    passthru('php vendor/bin/artisan down --no-interaction');
}

这样一来，只有生产环境才会执行 `artisan down`，逻辑清晰且跨平台兼容。

如何让同一个脚本在 dev 和 prod 下行为不同

另一个常见需求是：同一个脚本，在开发和生产环境下需要有不同的行为。这里有个误区：别指望 `composer install --no-dev` 会自动帮你禁用脚本。 这个参数只影响开发依赖的安装，不会跳过 `post-install` 或 `post-autoload-dump` 这类钩子脚本。

正确的适配姿势应该是主动判断：

• 判断开发模式：可以检查 `COMPOSER_DEV_MODE` 环境变量，当 `getenv('COMPOSER_DEV_MODE') === '0'` 时，表示当前正运行在 `--no-dev` 模式下。
• 检查工具存在性：对于只在开发环境需要的工具（如 `phpunit`, `infection`），在执行前先用 `is_executable('vendor/bin/phpunit')` 校验一下是否存在。
• 生产环境命令需“加固”：像 `cache:clear` 这类生产部署常用命令，务必加上 `--no-interaction` 和明确的 `--env=production` 参数，避免脚本卡在交互提示，或者读取了错误的 `.env` 配置。
• 避免硬编码调试标志：切忌在脚本里写死 `APP_DEBUG=true`。调试状态应从 `.env` 文件或环境变量中实时读取。

CI 场景下绕过交互式命令的真正解法

说到非交互执行，很多人加了 `--no-interaction` 参数后发现命令还是卡住了，这是为什么？根本原因在于，某些框架命令（比如Lara vel/Symfony的数据库迁移）在非TTY环境下，依然会尝试去读取标准输入（stdin）。要彻底解决，需要组合拳：

• 强制重定向标准输入：使用 `< /dev/null` 来确保stdin为空。例如：`php vendor/bin/artisan migrate --force < /dev/null`。
• 设置超时以防死锁：尤其在Docker容器内网络不稳定时，用 `timeout 30s` 包裹命令，防止进程无限期挂起。
• 显式声明CI环境变量：在GitHub Actions等CI配置中，明确设置 `env: { CI: 'true', APP_ENV: 'production' }`。然后在你的PHP脚本里，可以通过检查 `getenv('CI') === 'true'` 来识别CI环境。
• 将逻辑下沉到命令内部：最稳健的方式，是让命令本身支持“预检”或“跳过”逻辑。例如，Lara vel的迁移命令支持 `--pretend` 选项，可以先模拟运行验证SQL，再决定是否真正执行。

最后，还有一个极易踩坑的细节： Composer脚本运行时的当前工作目录（`getcwd()`），不一定就是你 `composer.json` 文件所在的目录。在使用了符号链接部署，或者Docker Volume挂载等复杂场景下，你写的相对路径 `./.env` 可能根本指向了一个不存在的文件。

所以，所有涉及路径的操作，最安全的做法是使用 `__DIR__` 魔术常量，或者通过Composer事件对象动态获取：`$event->getComposer()->getConfig()->get('vendor-dir')`。这才是万无一失的做法。