生产环境安全使用composer镜像需配置可信https镜像源并保留官方签名验证，禁用全局repo.packagist替换，仅代理元数据；项目级配置更可控，docker中须显式run配置且确保ca-certificates先行安装。
直接在 Docker 构建阶段配阿里云镜像，composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 是唯一可靠写法，漏一个字符或少个 / 就失效。
为什么不能复用宿主机的 ~/.composer/config.json
Docker 构建时默认不挂载宿主机的 ~/.composer 目录，COMPOSER_HOME 指向容器内默认路径（通常是 /root/.composer），宿主机配置完全不可见。硬 COPY 配置文件又容易因权限、格式错误引入问题。
实操建议：
- 所有镜像配置必须在
RUN指令中显式执行，例如：RUN composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 别写成
repos.packagist（多一个s）或漏掉composer这个 type 值 - URL 末尾必须带
/，https://mirrors.aliyun.com/composer（缺斜杠）会失败 - 配完立刻跟
composer clear-cache，否则旧缓存里的packagist.org元数据仍生效
项目级 repositories 会彻底屏蔽全局镜像
只要 composer.json 里有 "repositories" 字段，无论内容是否为空、是否指向官方源，全局配置都会被无视——Composer 不报错，也不提醒，这是设计行为，不是 bug。
常见踩坑点：
-
"repositories": [{"type": "composer", "url": "https://packagist.org"}]→ 看似没动镜像，实际已退回到直连官方源 -
"repositories": {"packagist.org": false}→ 直接禁用 Packagist，连ext-json这类平台扩展校验都会失败 - CI/CD 中误提交带旧镜像地址的
composer.json，构建失败后第一件事就是检查这个字段
Dockerfile 中 RUN composer install 卡住的真正原因
卡在 Loading composer repositories 不是网络慢，90% 是 OpenSSL + CA 证书问题，尤其 Alpine 镜像。
验证和修复步骤：
- 先确认 PHP 启用了 OpenSSL：
RUN php -m | grep openssl - Alpine 必须显式装证书：
RUN apk add --no-cache ca-certificates - 加
-vvv日志看真实请求地址：RUN composer install -vvv 2>&1 | grep -i mirrors，输出里没出现mirrors.aliyun.com就说明镜像没生效 - 别依赖
COMPOSER_REPO_PACKAGIST环境变量——它只影响部分版本，且优先级低于config -g
CI/CD 和多阶段构建中的隔离要点
并发构建 job 共享 /root/.composer 会导致镜像配置互相覆盖，尤其 Jenkins 或 GitLab CI。
安全做法：
- 用临时
COMPOSER_HOME：RUN COMPOSER_HOME=/tmp/composer-home-$$ composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 构建命令必须带完整参数：
composer install --no-dev --optimize-autoloader --classmap-authoritative --no-interaction - 多阶段构建中，
composer install放在 builder 阶段，最终镜像只 COPYvendor/，不保留 Composer 二进制和缓存
最易被忽略的是：Alpine 镜像里 ca-certificates 包必须在 composer config 之前安装，顺序错了证书就加载不上，后续所有 HTTPS 请求都静默失败。
