composer镜像配置不能只改一次config.json，因团队环境、ci/cd节点和docker容器启动顺序差异导致全局配置易被覆盖或解析异常；需用脚本动态探测可用镜像源并安全写入，兼顾fallback与多环境策略。
Composer 镜像配置为什么不能只改一次 config.json
因为团队成员本地环境、CI/CD 构建节点、Docker 容器启动顺序不同，composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 这类命令在 CI 中可能失效——全局配置被容器层覆盖，或因非交互式 shell 导致 COMPOSER_HOME 路径解析异常。硬编码镜像地址也难应对阿里云镜像临时不可用、腾讯云备用镜像切换等场景。
用 shell 脚本动态检测并设置镜像源
核心思路：不依赖用户手动执行，让脚本自动探测网络可达性 + 优先级策略，再调用 composer config 写入。关键点在于避免写死 URL，且必须处理 composer 命令未安装或权限不足的 fallback。
- 先用
curl -I -s -o /dev/null -w "%{http_code}" https://mirrors.aliyun.com/composer/packages.json检查 HTTP 状态码是否为200 - 失败则试
https://mirrors.tencent.com/composer/，再失败才回退到官方源https://packagist.org - 使用
composer config --global repo.packagist而非--unset后重设，避免清空用户自定义 repo 配置 - 脚本开头加
set -e，但对curl检测需用|| true防止整个脚本退出
PHP 脚本方式统一管理多环境镜像策略
当项目需区分 dev/staging/prod 环境（比如 dev 允许走代理镜像，prod 必须用内网 Nexus），纯 shell 不易维护。此时用 PHP 写一个 setup-mirror.php 更可控——它能读取 .env、调用 Composer\IO\NullIO 模拟交互，并复用 Composer 自身的配置写入逻辑。
- 依赖
composer require composer/composer（仅 dev 环境），避免重复实现 JSON 配置解析 - 关键代码段：
$config = Factory::createConfig(new NullIO()); $config->merge(['repositories' => [['type' => 'composer', 'url' => $mirrorUrl]]]); $config->setRepositories($config->getRepositories());
- 注意：不要直接修改
vendor/composer/installed.json，那是运行时缓存，应操作composer.json或全局config.json - 在
post-root-package-install脚本中调用，确保每次composer install前都校准
CI/CD 中绕过镜像配置失败的兜底方案
GitHub Actions 或 GitLab CI 的 job 可能因 DNS 缓存、临时墙、镜像服务升级导致 composer config 失败，进而中断整个构建。不能让镜像配置成为单点故障。
- 在 CI 的
before_script中，用timeout 10s composer config --global --no-plugins repo.packagist $MIRROR_URL || echo "镜像配置超时，跳过" - 显式传参覆盖：所有
composer install改为composer install --repository-url=$MIRROR_URL，该参数优先级高于配置文件 - Docker 构建时，在
Dockerfile中用RUN mkdir -p $COMPOSER_HOME && echo '{"repositories": [{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}]}' > $COMPOSER_HOME/config.json，比运行时配置更稳定
镜像地址本身不是重点，重点是让「配置行为」可预测、可中断、可降级。任何把 composer config 当作原子操作来用的地方，都容易在并发或网络抖动时卡住。
