composer镜像配置在ci/cd中常因用户隔离失效，正确做法是项目级配置：确保composer.json中repositories为数组、镜像url以/结尾且https、显式禁用packagist.org并保留私有源，换源后须清缓存、删vendor与lock文件再install。
镜像源配置在自动化部署中不是“锦上添花”，而是决定构建是否卡死的关键开关。 它不加速依赖解析，只加速包文件（.zip/.tar）下载；但一旦配错，composer install 就会永远停在 Loading composer repositories with package information —— 不报错、不超时、不重试，只沉默等待 packagist.org 的响应。
为什么 composer config -g repo.packagist 在 CI/CD 里总失效
命令本身没毛病，但执行环境不认它：
- Ansible、GitLab Runner、宝塔等默认以非登录用户（如
www-data、runner）运行，-g写进的是该用户的~/.composer/config.json，而 PHP 进程可能由另一个用户启动，根本读不到 - Docker 构建中，
~/.composer/config.json不会自动从宿主机继承，每个RUN阶段都得单独配一次 - Windows 下 PowerShell/CMD 不刷新环境变量，改完要重启终端才生效
- PHP 禁用了
proc_open或putenv（常见于宝塔或容器精简镜像），config -g直接失败，但不提示
项目级配置比全局更可靠，但写法极容易翻车
把镜像写进 composer.json 是唯一能跨环境一致生效的方式，但必须满足三个硬性结构条件：
-
repositories必须是数组，不能是对象："repositories": [{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}]✅；"repositories": {"packagist": {...}}❌（Composer 直接忽略整个字段） - 国内镜像必须放在
repositories数组首位，否则优先走后面的源 - 必须显式保留官方源兜底：
{"packagist.org": false}要写在repositories外层根节点，不能塞进某个仓库对象里；设为false会导致基础包（如php扩展约束）无法解析
Docker 构建中镜像配置的实操要点
每一步都踩过坑，少一个就会导致构建卡住或缓存失效：
- Alpine 镜像必须先装证书：
RUN apk add --no-cache ca-certificates，否则SSL certificate problem: unable to get local issuer certificate会中断所有 HTTPS 请求 - 镜像配置命令必须写在
RUN中：RUN composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，且不能省略composer类型值 -
COPY composer.json composer.lock ./和RUN composer install必须紧挨着，中间插任何指令（比如RUN chmod）都会让 Docker 层缓存失效，每次重装依赖 - 多阶段构建中，
--from=builder不继承 Composer 配置，每个阶段都要重配
最常被忽略的一点：换源后，composer update 没用，必须删掉 vendor/ 和 composer.lock，再跑 composer install —— 否则它仍按旧 lock 文件里的 dist URL 去拉包，哈希校验失败，安装直接中断。
