官方PHP镜像（如php:8.2-cli）已预装Composer，直接使用；若用Alpine等精简镜像，需apk add composer或通过官方脚本安装，并配置国内镜像源、隔离COMPOSER_HOME、多阶段构建优化依赖管理。
怎么在 Docker 容器里装上 composer
直接用官方 PHP 镜像就能省掉大部分麻烦——它已经预装了 composer。比如 php:8.2-cli 或 php:8.3-cli 这类镜像，进容器执行 composer --version 就能验证。
如果你用的是精简版基础镜像（比如 alpine 或自己编译的 PHP），就得手动装：
- Alpine 下走
apk add composer，但注意 Alpine 的composer包可能滞后，且不带某些插件（如composer-plugin-api） - Debian/Ubuntu 系镜像建议用官方安装脚本：
curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer - 别用
php composer-setup.php后只放./composer.phar在项目目录——这会导致不同容器行为不一致，也难统一升级
Dockerfile 里写 RUN composer install 为什么总失败
常见错误是把 composer install 放在构建末尾，又没挂载 vendor 或设对工作目录，结果装完就丢。
更关键的是：PHP 扩展缺失、平台配置不匹配、或用了 --no-dev 却漏了运行时依赖。
- 确保
RUN前已启用必要扩展，比如mbstring、xml、zip（Laravel、Symfony 都要） - 加
--ignore-platform-reqs是临时解法，但会掩盖真实兼容问题；长期应统一platform配置到composer.json的config.platform字段 - 如果项目用
composer.lock，就别在 Docker 构建时跑update——固定版本靠install，否则镜像不可重现 - 多阶段构建中，
composer install应放在 builder 阶段，再把vendor复制过去，别让最终镜像带上 dev 依赖和源码
composer 安装慢 / 超时 / 报 Could not fetch
国内环境默认连 packagist.org 经常卡住或失败，不是网络问题，是 DNS 和 CDN 路由导致的。
- 最稳方案：在
Dockerfile构建时注入国内镜像源，比如 RUNcomposer config -g repo.packagist composer https://packagist.phpcomposer.com（注意该地址已停，换用https://mirrors.aliyun.com/composer/） - 别在
~/.composer/config.json里硬编码——Docker 构建不读宿主机配置；必须显式RUN composer config或 COPY 配置文件 - 如果用
composer create-project，记得加-vvv看具体卡在哪一步；有时是 GitHub API 限流，需配GITHUB_TOKEN环境变量 - Alpine 镜像下还可能因 ca-certificates 版本旧导致 HTTPS 握手失败，RUN
apk update && apk add ca-certificates再试
怎么让 composer 不污染基础镜像的全局配置
多人协作或 CI 场景下，一个项目改了全局 composer 配置（比如换了源），会影响其他项目构建——这不是预期行为。
- 用
--no-plugins和--no-scripts控制非必要行为，尤其避免执行post-install-cmd里可能写的危险命令 - 优先用
COMPOSER_HOME环境变量隔离配置路径，比如RUN COMPOSER_HOME=/tmp/composer composer install，这样不会动系统级设置 - 如果项目有自定义插件或脚本，确认它们不依赖宿主机路径或未声明的扩展；否则构建时会静默跳过或报错
- CI 中建议每次构建前清空
~/.composer/cache，或挂载空 volume，避免缓存损坏导致奇怪的依赖解析错误
真正麻烦的不是装不上 composer，而是它在不同阶段读取不同配置、缓存行为不透明、又和 PHP 扩展强耦合——稍不注意，本地能跑的 Dockerfile 到 CI 就卡在 Resolving dependencies。
