CI中禁用composer require，因其会修改composer.json和composer.lock，破坏构建可重现性；正确做法是在开发阶段完成require并提交lock文件，CI仅执行composer install加生产参数。
CI中不能直接运行 composer require，它会修改 composer.json 和 composer.lock，破坏构建可重现性。
为什么 CI 里禁用 composer require
CI 的核心目标是「确定性构建」：相同输入（代码 + lock）必须产出相同结果。composer require 本质是开发行为，它会：
- 修改
composer.json的require或require-dev字段 - 触发依赖解析并写入新版本到
composer.lock - 可能拉取非锁定版本（尤其当没提交 lock 时）
- 导致不同分支、不同时间的构建结果不一致
错误现象：CI 脚本里写了 composer require phpunit/phpunit --dev，但没提交新生成的 composer.lock → 下次构建因 lock 缺失而失败，或本地与 CI 加载类不一致。
composer require 的安全替代方案
真需要在 CI 中“引入依赖”，说明流程设计有误。正确做法是把依赖声明前置到开发阶段，并通过以下方式落地：
- 开发时执行
composer require foo/bar，确认功能后立即提交composer.json和composer.lock - CI 中只跑
composer install --no-interaction --no-dev --prefer-dist --optimize-autoloader - 若需临时加一个调试工具（如
psy/psysh），改用composer global require（仅限 CLI 环境，不影响项目 vendor） - 极少数场景（如动态生成 SDK 包），应使用独立脚本+沙箱目录，而非在主项目中
require
CI 中误用 require 的典型修复路径
如果已有流水线在用 composer require，优先按以下顺序收敛风险：
- 检查是否只是为装 dev 工具（如
phpstan/phpstan）→ 改成require-dev并提交 lock - 确认是否因缺失
composer.lock导致被迫 require → 强制 Git 提交 lock，CI 开头加composer validate --strict - 若用于私有包安装（如
company/internal-sdk），确保仓库已配置在repositories，且版本约束明确（如"company/internal-sdk": "^1.2"） - 禁止在 Dockerfile 中出现
RUN composer require；应 COPYcomposer.json+composer.lock后再RUN composer install
真正难的不是命令怎么写，而是谁在什么环节有权决定加依赖——CI 只负责执行，不负责决策。把 require 锁死在开发环境，才是安全底线。
