不能在php-fpm容器启动时配置composer镜像，因为php-fpm是常驻进程不执行composer命令，且www-data用户家目录不可写导致全局配置无效；依赖应在构建阶段安装，镜像源仅对build时的install/update生效。
为什么不能在php-fpm容器启动时配置Composer镜像
因为php-fpm是常驻进程，不执行composer命令；composer config -g写入的是~/.composer/config.json，而多数基础镜像里www-data用户家目录为空或不可写，配置根本不会生效。更关键的是：运行时根本不需要Composer——依赖早已在构建阶段装好，镜像源只对composer install或composer update起作用，而这俩命令只该出现在Docker build里。
Dockerfile中设置镜像的正确时机和写法
必须在RUN指令中、composer install之前显式配置，且保证在同一层（避免缓存失效）：
RUN composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ \ && composer install --no-dev --no-scripts --optimize-autoloader
- 阿里云镜像源是当前唯一可用的官方推荐源（2026年7月1日起旧镜像已停用）
- 不要依赖宿主机的
~/.composer/config.json，Docker构建过程完全隔离 - 如果用多阶段构建，只需在builder阶段配置；final阶段根本不该装composer
- 项目级配置（在
composer.json里加"repositories"）比全局配置更稳定，尤其适合CI/CD流水线
config.platform.php不填等于埋雷
即使你用了php:8.2-cli镜像，若composer.json里没声明"config": {"platform": {"php": "8.2.15"}}，Composer仍会按当前环境推测能力，可能装入仅兼容PHP 8.3的语法（比如readonly属性），导致运行时报ParseError。
- 验证方式：构建后进容器执行
composer show --platform，输出必须和目标运行环境PHP版本、扩展版本严格一致 - 构建前务必跑一次
composer update --lock并提交更新后的composer.lock - Alpine镜像需提前
RUN apk add --no-cache ca-certificates git unzip，否则SSL校验或git clone直接失败
多阶段构建中builder和runner必须同源
常见错误是builder用php:8.2-cli，runner却用php:8.2-fpm-alpine——虽然PHP主版本一样，但SAPI类型、扩展集、libc实现都不同，会导致autoloader生成异常，或ext-zip缺失引发类加载失败。
- builder和runner必须同base（比如都用
php:8.2-cli-alpine和php:8.2-fpm-alpine） - builder阶段要确保关键扩展已启用：
zip、mbstring、pdo等 - final阶段只
COPY --from=builder /app/vendor /app/vendor，别复制composer.phar或vendor/bin/下的dev工具 - 运行用户必须切换：
RUN adduser -D -u 1001 -s /bin/sh app，再USER app，否则vendor/权限错乱
config.platform字段的完整性与composer.lock的及时更新——这两项出问题，容器能跑起来，但某个深夜的某个请求就会突然抛出解析错误，排查起来毫无头绪。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
