ci/cd 中 composer install 失败主因是环境差异：需加 –no-interaction –no-progress –optimize-autoloader –no-scripts，私有包用 composer_auth 注入，必须提交 composer.lock，docker 中分层缓存 + –prefer-dist，且 config.platform.php 锁定 php 版本。
为什么 composer install 在 CI/CD 里总卡住或失败？
CI 环境没用户交互、没缓存、网络策略严，composer install 默认行为很容易崩。比如它会试图读取 auth.json、触发脚本、检测平台扩展，而这些在容器里全不可用。
- 确保始终加
--no-interaction --no-progress --optimize-autoloader --no-scripts -
--no-scripts很关键：很多项目在post-install-cmd里跑php artisan optimize或生成配置，但 CI 不需要，还可能因缺少环境变量直接报错 - 如果依赖里有私有包，别把
auth.json塞进仓库，改用 CI 变量注入：COMPOSER_AUTH='{"http-basic":{"repo.example.com":{"username":"x","password":"y"}}}' - 避免用
composer update：CI 应该只装锁文件，不是重算依赖树；否则每次构建结果不一致，还拖慢流程
composer.lock 文件没提交？CI 会直接拒绝安装
Composer 在无 composer.lock 时退化为 update 行为，不仅慢，还会引入意料外的版本变更 —— 这在 CI 里是硬性错误。
- 检查
git status是否真包含了composer.lock（尤其 PHP 8.2+ 新项目默认可能忽略） - Git 忽略规则里不能有
composer.lock相关条目，连**/composer.lock都得删 - 若用 monorepo 工具（如
monorepo-builder），确认它没自动删锁文件
Docker 构建中反复下载包？用好 --prefer-dist 和分层缓存
Docker 每次 RUN composer install 都从零拉包，镜像体积暴涨、构建时间翻倍。
- 显式加上
--prefer-dist：跳过git clone，直接下 zip 包，更快更稳定 - 把
vendor/放进 .dockerignore 是误区 —— 它不影响构建阶段缓存，反而让每步都失效 - 正确做法：把
composer.json和composer.lock单独 COPY 到一层，再RUN composer install，这样只要锁文件不变，缓存就复用
PHP 版本不匹配导致 composer install 报 Your requirements could not be resolved
Composer 会根据当前 PHP 版本过滤包版本，CI 容器里 PHP 小版本（如 8.1.23 vs 8.1.0）差异有时就让 ^8.1 解析出不同结果。
- 在
composer.json的config.platform.php显式锁定目标运行环境版本，例如："config": {"platform": {"php": "8.1.10"}} - CI 脚本里先
php -v校验，再执行安装，避免低版本 PHP 容器误跑高版本依赖 - 不要依赖
php:latest：Docker Hub 上这个 tag 经常指向新 Minor 版，CI 突然失败就是它干的
依赖解析和锁文件行为本身不复杂，但一旦混进 CI 的权限限制、缓存机制、容器生命周期里，所有“应该正常”的地方都会变成条件分支。最常漏掉的是 platform 配置和 --no-scripts 开关 —— 它们不报错，但会让构建产物和本地不一致。