卡在“resolving dependencies”主因是平台环境不匹配或锁文件与容器php版本/扩展不一致，需检查php -v、扩展是否安装及platform配置，禁用插件并确保builder与runtime镜像一致。
直接改 composer.json 后在容器里跑 composer install，90% 的慢和失败都源于依赖解析阶段卡住——不是下载慢，是 PHP 环境、平台约束或锁文件不匹配导致 Composer 反复回溯、重试甚至死循环。
为什么 composer install 卡在 “Resolving dependencies” 阶段？
这不是网络问题，而是 Composer 在构建依赖图时被环境差异卡住。常见诱因包括：
-
composer.lock里记录的platform（如"php": "8.2.10"）和容器中实际 PHP 版本（php -v输出为8.2.15）不一致，触发兼容性检查回退 - 容器缺失
ext-zip或ext-openssl，但composer.json中未声明require，Composer 却在解析时发现某些包的provide声明依赖它们，于是反复尝试降级 -
composer.lock是在宿主机（macOS + PHP 8.3）生成的，而 Docker 使用php:8.2-cli-alpine，Alpine 的 musl libc 和 glibc 下的扩展 ABI 不兼容，导致包元数据校验失败 - 用了
repositories指向私有源，但容器内 DNS 或证书不可达，Composer 不报错也不超时，只沉默重试 3–5 分钟
composer install --ignore-platform-reqs 能临时绕过，但别在生产用
它确实能让解析快速通过，代价是可能装上不兼容的包版本——比如某个组件在 php:8.2 下因缺少 ext-gd 导致运行时报 Class not found，但安装阶段完全不暴露。
- 仅限调试：加
--verbose查看具体哪条 platform req 被忽略，再针对性修复 - 生产必须对齐：在
Dockerfile中显式安装所需扩展，例如RUN docker-php-ext-install zip openssl - 验证是否真对齐：构建后进容器执行
php -m | grep -E '^(zip|openssl|mbstring)$'和php -r "echo PHP_VERSION;"
真正加速解析的三个实操点
核心思路是让 Composer 在解析前就“知道答案”，而不是现场推演。
- 提前固化平台信息：在
composer.json里写死"platform": {"php": "8.2.15", "ext-zip": "1.20.0"}，并确保容器中php -v和php -i | grep 'zip version'输出严格匹配 - 禁用无意义插件：加
--no-plugins参数。很多插件（如hirak/prestissimo）在 Docker 构建中不仅没用，还会在解析阶段初始化 HTTP 客户端，拖慢速度 - 用
--dry-run预检：在 CI 流水线中先跑composer install --dry-run --no-dev --no-scripts，失败则立刻中断，避免浪费构建时间
多阶段构建中解析加速的关键陷阱
很多人以为把 composer install 放到 builder 阶段就万事大吉，但若 builder 和 runtime 阶段 PHP 版本/扩展不一致，解析结果在 runtime 阶段会失效。
- builder 阶段必须和 runtime 阶段使用**同一基础镜像标签**，例如都用
php:8.2-cli，不能 builder 用composer:2（基于 Debian）、runtime 用php:8.2-cli-alpine - 如果必须用 Alpine，builder 阶段要提前
RUN apk add --no-cache php-zip php-openssl，否则composer install解析时看到系统无 zip 扩展，会强制选一个不带 zip 依赖的旧版包 - 不要在 builder 阶段用
--prefer-source：它会让 Composer 克隆 Git 仓库而非解压 dist 包，解析时需额外 fetch commit log，显著拉长耗时
最易被忽略的一点：Composer 解析速度和 vendor/ 是否存在无关，只和 composer.lock 的完整性、平台一致性以及插件行为有关。哪怕你删掉整个 vendor 目录，只要 lock 文件和环境匹配，install 的解析阶段仍能毫秒级完成。
