官方php镜像（如php:8.3-cli）已预装composer，直接可用；alpine等精简镜像需手动安装并确保放入/usr/local/bin且可执行，否则报command not found；务必通过docker run --rm镜像composer --version验证，run composer --version须在dockerfile安装后立即执行确认生效。
官方 PHP 镜像（如 php:8.3-cli）已自带 composer，直接可用；若用 Alpine 或自定义镜像，则必须手动安装并确保它在 $PATH 中，否则 composer --version 会报 command not found。
怎么确认容器里有没有 composer
别猜，直接验证：
- 运行
docker run --rm php:8.3-cli composer --version—— 成功输出版本号，说明镜像自带 - 换成
php:8.3-cli-alpine就大概率失败，因为 Alpine 官方镜像不预装 Composer - 如果报错
command not found，不是网络或权限问题，是根本没装或没放对路径
Dockerfile 里怎么正确安装 composer
关键不是“下载”，而是“让它能被全局调用”：
- Debian/Ubuntu 系（如
php:8.3-cli）：用官方脚本，RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer - Alpine 系（如
php:8.3-cli-alpine）：先装依赖RUN apk add --no-cache curl openssl ca-certificates，再执行同上安装命令 - 别写
RUN php composer-setup.php后只留./composer.phar—— 它不在$PATH，composer命令依然不可用 - 验证是否生效：
RUN composer --version必须放在安装命令之后、构建阶段内执行，不能靠“宿主机有就以为容器也有”
为什么 RUN composer install 总卡住或失败
常见原因不是代码写错，而是环境和缓存没对齐：
-
composer.lock没在RUN composer install前COPY进来 —— Docker 会退化成update，破坏可重现性 - 没配国内镜像源：
RUN composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意：旧地址packagist.phpcomposer.com已停用） - PHP 扩展缺失：比如
mbstring、xml、zip没装，Laravel或Symfony依赖直接报错 - 平台版本不一致：
composer.lock记录的是 PHP 8.2，但镜像用的是 8.1，且没设"config": {"platform": {"php": "8.2.0"}}
多阶段构建中 vendor 怎么安全复制过去
最终镜像不该带 composer、dev-dependencies 和源码缓存：
- 第一阶段用
FROM composer/composer:2-bin as builder或FROM php:8.3-cli as builder -
COPY composer.json composer.lock ./→RUN composer install --no-dev --prefer-dist --optimize-autoloader - 第二阶段
FROM php:8.3-fpm，只COPY --from=builder /app/vendor ./vendor - 别在最终镜像里留
composer.json或composer.lock—— 它们只是构建输入，不是运行时必需
最容易被忽略的点：Alpine 镜像下 HTTPS 握手失败不是网络问题，是 ca-certificates 包没更新；多阶段构建时若没显式 WORKDIR，COPY --from=builder 可能复制错路径；composer install 前漏掉 --no-dev，会让生产镜像带上 PHPUnit 等开发工具。
