容器中composer install失败主因常是PHP扩展缺失（如Alpine缺icu依赖致intl不可用）或composer.lock含不可达dev分支，需在Dockerfile中显式安装扩展并验证ICU版本，而非依赖--ignore-platform-reqs掩盖问题。
容器里 composer install 失败，不是网络慢或权限错，大概率是 PHP 版本/扩展和 composer.lock 记录的平台能力对不上——Docker 镜像没装全扩展，或者用了错的 base image。
为什么 Alpine 镜像里总报 ext-intl 缺失？
Alpine 默认不带 intl 扩展，哪怕你写了 docker-php-ext-install intl，也得先装好 ICU 依赖。Ubuntu 系的镜像（如 php:8.1-apache）通常自带，但 Alpine（php:8.1-alpine）必须手动补全：
- 缺
icu-dev或icu-data-full：运行apk add icu-dev icu-data-full再执行docker-php-ext-install intl - 装完要验证：
docker run --rm your-image php -m | grep intl，只看到intl不够，还得确认php -i | grep 'ICU version'有输出 - 别信
config.platform.ext-intl——它不会让 Alpine “变出” intl，只会让 Composer 跳过检查，结果 runtime 报Class 'IntlDateFormatter' not found
CI 流水线里 composer install 卡在 Resolving dependencies
这不是网络问题，是 composer.lock 里锁了 dev 分支（比如 "dev-main" 或 "dev-develop"），而 Packagist 上该分支已不可达，或 CI 环境没配 minimum-stability。后果是 SAT 求解器无限回溯。
- 上线前必跑：
composer install --dry-run，超 30 秒没输出就说明 lock 文件含不稳定引用 - 查 dev 引用：
grep -n '"reference":"dev-' composer.lock，定位到具体包后，改用稳定 tag（如v3.2.1）再composer update vendor/package --with-dependencies - CI 脚本里加校验：
php -v和composer show --platform输出对比，不一致直接exit 1
用 --ignore-platform-reqs 强上之后，线上 Class not found
这个 flag 只关掉 PHP 版本和扩展校验，但不会修复 autoload 映射、不会重写 vendor/autoload.php，更不会让缺失的扩展 magically 出现。它只是把问题从安装阶段推迟到运行时。
- 常见失败点：
ext-gd缺失 →Intervention\Image\ImageManager初始化失败；ext-xml缺失 → Symfony Serializer 直接抛错 - 真正该做的是：在 Dockerfile 里明确安装扩展，而不是靠 flag 掩盖；例如 Ubuntu 镜像加
RUN apt-get update && apt-get install -y libpng-dev libjpeg-dev && docker-php-ext-configure gd --with-jpeg-dir=/usr/include && docker-php-ext-install gd - 如果真不能装扩展（如某些托管平台），必须确认所有依赖都声明了
replace或支持 polyfill，比如用symfony/polyfill-intl-idn替代ext-intl，且包的composer.json里写了"replace": {"ext-intl": "*"}
最常被忽略的一点：Docker 构建缓存会让 php -m 结果“看起来正常”，但实际运行时用的是另一套 php.ini ——务必检查 php --ini 输出的配置路径，并确认 docker-php-ext-enable 生成的 ini 文件真被加载了。
