不能共用。多PHP版本下镜像必须与PHP版本强绑定，否则composer install会用错解释器、拉错包、生成不兼容vendor目录；全局镜像只改下载地址而不控制PHP运行时，无法感知版本或校验php约束，项目级配置需写入composer.json repositories首位并禁用packagist.org，且须删vendor和composer.lock后重装。
不能共用。多 PHP 版本下，镜像配置必须和 PHP 版本强绑定，否则 composer install 会用错解释器、拉错包、生成不兼容的 vendor/ 目录。
为什么全局镜像在多 PHP 版本下反而失效
全局镜像（composer config -g repo.packagist）只改下载地址，不控制运行时 PHP。当你有 php7.4 和 php8.2 并存时：
-
composer install实际调用哪个php，取决于$PATH顺序或你是否显式指定路径 - 如果误用
php7.4执行本该适配php8.2的composer.json，即使镜像再快，也会装出一堆不支持match或enum的旧版包 - 全局镜像无法感知当前 PHP 版本，也不会校验
"php": "^8.2"是否被满足 - 项目里若已存在
repositories字段，它会直接屏蔽全局镜像，导致你以为配了却没生效
项目级镜像必须写进 composer.json，且格式不能错
项目级配置是唯一能和 PHP 版本强绑定的方式——因为它是随代码一起提交的，构建时自动生效，且优先级高于全局设置。但写法极其敏感：
- 必须把镜像对象放在
repositories数组首位，且{"packagist.org": false}是独立对象，不是字段值 - 正确写法（注意逗号、括号、斜杠）：
{ "repositories": [ { "type": "composer", "url": "https://mirrors.aliyun.com/composer/" }, {"packagist.org": false} ] } - 错误写法包括：
"repositories": {"packagist": {}}（对象而非数组）、漏掉{"packagist.org": false}、URL 少末尾/、键名写成repos.packagist - 改完后必须删掉
vendor/和composer.lock，再跑composer install——update不会重读镜像配置
CI/CD 中避免全局 config 污染的最佳实践
CI 环境常复用缓存或基础镜像，composer config -g 写入的是全局配置（~/.composer/config.json），若前序 job 已写入不兼容镜像配置，当前 job 就会继承错误状态，且无提示：
立即学习“PHP免费学习笔记（深入）”；
- 安全做法：每次运行前重置，用
composer config -g --unset repos.packagist清除，再显式设置 - 更稳妥做法：不依赖全局配置，改用
-d参数临时指定：php -d composer.repo.packagist=https://mirrors.aliyun.com/composer/ /path/to/composer.phar install - 所有自定义镜像必须支持
GET /packages.json和GET /p/<vendor>/<package>.json两个端点，且响应头需带Content-SHA256或提供.sig签名文件 - Composer 2.5+ 强制校验 provider 文件 SHA256 哈希，旧式镜像（如硬替换 URL）因不满足透传或重签要求而报
Invalid package information
真正起作用的从来不是镜像本身，而是 composer.lock + platform 配置 + 显式调用的 PHP 解释器路径。镜像只是加速手段，换源不会改变版本结果，也不会修复因 PHP 版本不一致导致的 lock 解析差异。最容易被忽略的一点：每次切换 PHP 版本后，vendor/ 和 composer.lock 必须一起删掉重装——这不是建议，是硬性要求。
