Composer install在Docker中卡在“Resolving dependencies”主因是默认直连packagist.org超时，且Docker不复用宿主机缓存；应配置阿里云镜像、确保ca-certificates已安装、严格遵循COPY composer.lock先于composer.json的顺序，并验证Composer正确安装。
为什么composer install在Docker里总卡在“Resolving dependencies”
这不是 Composer 本身慢，是默认连 packagist.org 在国内 DNS 和 CDN 路由下几乎必超时。Docker 构建不复用宿主机缓存，每次都是全新连接，且没有重试机制。
- 最稳方案：在
RUN指令前加环境变量，比如RUN COMPOSER_REPO_PACKAGIST=https://mirrors.aliyun.com/composer/ composer install - 别用已停用的镜像源，例如
https://packagist.phpcomposer.com（2026 年起不可用） - Alpine 镜像必须先装证书：
RUN apk add --no-cache ca-certificates，否则报SSL certificate problem - 如果项目有
composer.lock，就只跑install，别在构建阶段跑update，否则破坏可重现性
command not found：容器里根本没有composer命令
官方 PHP 镜像（如 php:8.3-cli）默认不预装 Composer，得手动装；装完还得确保它在 $PATH 里。
- 推荐安装方式：
RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer - Alpine 需先装依赖：
RUN apk add --no-cache curl openssl - 验证是否装好：
RUN composer --version，构建失败就说明路径或权限没对 - 别把
composer.phar放进项目目录再php ./composer.phar——这会导致不同容器行为不一致，也难统一升级
COPY顺序错导致退化成composer update
如果 composer.json 和 composer.lock 的复制顺序不对，Composer 就会忽略 lock 文件，退化为 update 行为，版本失控。
- COPY 顺序必须是：
COPY composer.lock .→COPY composer.json .→RUN composer install - 否则 Composer 会发现 lock 文件缺失或过期，自动 fallback 到 resolve 全部依赖
- 多阶段构建中，只
COPY --from=builder /app/vendor /app/vendor，不复制~/.composer或缓存目录 - 别在
WORKDIR里直接git clone项目后再composer install——这会让所有依赖安装步骤无法被缓存
PHP 版本或扩展不匹配引发“Your requirements could not be resolved”
常见于本地开发用 PHP 8.2，但 Docker 里用的是 PHP 7.4，而 composer.lock 里锁定了仅支持 8.0+ 的包版本。
- 检查
composer.lock顶部的platform字段，确认是否显式声明了 PHP 和扩展版本 - 若没有，构建前先运行
composer update --lock并提交更新后的composer.lock - 在 Dockerfile 中提前装好必需扩展，比如
RUN docker-php-ext-install zip mbstring openssl -
composer install --ignore-platform-reqs是临时绕过，不推荐用于生产；应让容器环境真正对齐 lock 文件约束
Alpine 镜像的证书和 COPY 顺序是最容易被忽略的两个点，前者导致 SSL 失败，后者直接让依赖版本失控。这两个问题在构建失败时往往不报明确错误，只表现为卡住或安装了意外版本。
