阿里云镜像配置必须严格满足三要素：键名repo.packagist（单数）、type值composer、url以/结尾的https地址，缺一即静默失效；验证需执行composer config -g repo.packagist输出完整json。
大促期间代码发布掉链子，90%不是业务逻辑问题，而是 Composer 在下载依赖时卡住或 fallback 到 packagist.org 导致超时、失败、版本不一致。 用阿里云镜像能解决大部分问题，但必须配对——配错就等于没配。
composer config -g repo.packagist 命令为什么总不生效
不是网络慢，是三个硬性条件缺一不可：
-
repo.packagist必须是单数，写成repos.packagist或repositories.packagist.org都静默失败 - 命令末尾必须显式带上
composer这个 type 值，省略它会导致 Composer 2.0+ 直接 fallback 到官方源 - URL 必须是 HTTPS 且以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（拼出/composerpackages.json直接 404）
验证是否写入成功，只看这一条：composer config -g repo.packagist。输出必须是完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、报错，全都不算生效。
CI/CD 流水线里镜像配置落地不了的根因
镜像本身没问题，问题出在配置没落到执行用户上下文：
- Docker 构建阶段不能靠
COPY ~/.composer/config.json—— 容器销毁即丢，必须显式运行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - GitHub Actions 要缓存
~/.composer/cache，不是vendor/；否则每次冷启动都重走默认源 - 宝塔或 Jenkins 后台任务常以
www用户运行，但你用root配的全局镜像写在/root/.composer/config.json，www根本读不到
项目级配置比全局更稳，尤其适合电商大促场景
大促前发布窗口窄、容错率低，不能依赖“某人本地配过”，必须让配置可追踪、可复现：
- 进项目根目录，运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g） - 该命令会自动在
composer.json顶层写入"repositories": {"packagist": {...}}，不覆盖已有私有源 - 如果项目已存在
"repositories"数组，别手动改，用命令追加，否则可能误删内部包源（如internal/utils） - Git 提交
composer.json后，所有开发者、CI 节点行为完全一致
换源后 still stuck at “Resolving dependencies”？那和镜像无关
镜像只加速下载，不解决依赖解析慢的问题。大促前紧急更新依赖时，如果 composer update 卡在 Resolving dependencies 几分钟，基本可以确定是以下原因：
-
composer.json里 PHP 版本约束太宽，比如"php": "^7.4 || ^8.0 || ^8.1"，触发大量版本回溯 -
require-dev塞了太多工具链（如phpstan,infection），且未锁定版本 - 用了
dev-master或@dev这类不稳定版本，导致元数据反复刷新
这类问题换任何镜像都没用，得收窄约束、锁定版本、拆分 require-dev 到独立脚本里执行。
电商大促最怕的不是慢，而是不可控——一次 fallback、一次 hash 不一致、一次权限错位，都可能让发布卡在凌晨两点。镜像不是万能钥匙，但配错就是第一道裂缝。
