多版本 php 共存时 composer 镜像配置失效，根本原因是 composer config -g 仅作用于当前用户 $home/.composer/config.json，而不同 php 版本/环境（宝塔、ci、ide）可能以不同用户运行，读取不同配置文件；项目级配置（composer config repo.packagist）或系统级配置（/etc/composer/config.json）更可靠。
多版本 PHP 共存时，Composer 镜像配置失效，不是镜像地址问题，而是配置被写到了错误的用户上下文或 PHP CLI 环境未对齐——你可能在终端用 php 走的是 PHP 8.2，但宝塔/CI/IDE 内置终端调用的是 PHP 7.4，而 Composer 又只读当前 PHP 进程能访问到的那个 ~/.composer/config.json。
为什么 composer config -g 在多版本环境里经常“配了等于没配”
根本原因是 -g（global）不指“全局 PHP”，而是“当前用户全局”。不同 PHP 版本进程若以不同用户身份运行（比如宝塔用 www 用户、GitHub Actions runner 用 runner 用户、本地终端用 yourname），它们各自读取的 ~/.composer/config.json 完全不同。更隐蔽的是：某些 PHP 集成环境（如 phpstudy、XAMPP）自带独立的 Composer 副本，根本不走系统 PATH 中的 composer，自然也无视你配好的用户级配置。
-
composer config -g写入的是~/.composer/config.json，路径取决于执行命令时的$HOME - Web 服务（Nginx/Apache）下 PHP-FPM 进程通常以
www-data或www用户运行，它读的是/var/www/.composer/config.json（Linux）或C:\Windows\System32\config\systemprofile\.composer\config.json（Windows），和你终端里的$HOME不是一回事 - phpstudy 等集成环境默认把 Composer 打包进 PHP 目录，其
composer可执行文件硬编码了--working-dir和用户目录逻辑，-g配置可能被忽略
项目级配置才是多版本共存下的可靠方案
绕过用户上下文差异最直接的方式，是把镜像声明写进项目本身——它不依赖任何外部配置，只要 composer.json 存在，所有 PHP 版本、所有用户、所有 CI 环境都会一致读取。
- 进项目根目录，运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意：不加-g） - 该命令会在
composer.json顶层自动添加"repositories"字段，key 必须为"packagist"，不能是"aliyun"或其他别名 - 如果项目已有
"repositories"数组（比如含私有源），命令会安全追加，不会覆盖或破坏原有结构 - 提交
composer.json到 Git，团队成员git pull后无需任何额外操作，composer install自动走镜像
系统级配置（Composer 2.2+）适用于统一管理多个用户
当你的机器上存在固定几个服务用户（如 www-data、jenkins、runner），且它们都需走同一镜像时，系统级配置比逐个用户配更省事，也避免权限混乱。
- 创建或编辑：
/etc/composer/config.json（Linux/macOS）或C:\ProgramData\ComposerSetup\config.json（Windows） - 内容必须是合法 JSON，例如：
{"repositories": {"packagist.org": {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}}} - 设权限：
sudo chmod 644 /etc/composer/config.json，确保各服务用户可读 - 验证：切换到目标用户（如
sudo -u www-data bash），再运行composer config -g repo.packagist，应输出镜像 URL
验证是否真生效，别只看命令返回
执行完配置后，很多人只检查 composer config -g repo.packagist 输出就认为 OK，但实际请求仍发往 packagist.org。关键要抓真实网络行为：
- 清缓存：
composer clear-cache，否则旧元数据可能掩盖问题 - 干跑一次更新：
composer update --dry-run --no-cache -v，观察日志中Loading composer repositories后面的 URL 是否为你配的镜像域名（如mirrors.aliyun.com） - 用
curl -I https://mirrors.aliyun.com/composer/packages.json测试镜像本身是否可访问，排除 DNS 或防火墙干扰 - 若仍卡在
Resolving dependencies，那和镜像无关——那是composer.json里约束太松或循环依赖导致的解析爆炸，换源解决不了
多版本共存时，最易被忽略的其实是 PHP CLI 的函数禁用问题：宝塔、phpstudy 默认禁用 proc_open 和 putenv，Composer 连初始化都失败，镜像再快也没用。先确认 php -m | grep -E "openssl|tokenizer" 和 php -r "echo proc_open('echo 1', [], $p) ? 'ok' : 'fail';" 都正常，再谈镜像配置。
