多版本php共存时composer config -g镜像常失效，因-g仅作用于当前用户配置文件，而不同php版本常以不同用户（如www、runner）运行，读取各自$home/.composer/config.json；项目级配置才可靠。
多版本 PHP 共存时，composer config -g 配的镜像源大概率不生效——不是镜像地址错了，而是它压根没被当前 PHP 进程读到。
为什么 composer config -g 在多版本环境下经常“配了等于没配”
因为 -g 的含义是“当前用户全局”，不是“所有 PHP 版本全局”。不同 PHP 版本可能由不同用户启动：
- 你在终端用
php调的是 PHP 8.2，HOME是/home/yourname，配置写进~/.composer/config.json - 宝塔后台跑的是 PHP 7.4，PHP-FPM 以
www用户运行，它读的是/var/www/.composer/config.json - GitHub Actions 中的
composer install是 runner 用户执行，路径又不一样 -
phpstudy 等集成环境自带独立
composer.phar，硬编码了工作目录逻辑，直接无视系统 PATH 和你的-g配置
composer config repo.packagist 必须满足的三个硬性条件
命令不报错 ≠ 配置成功。Composer 2.x 对格式极其敏感，漏掉任一条件都会静默 fallback 到官方源：
- 键名必须是
repo.packagist（单数、无 s、无下划线），写成repos.packagist或repository.packagist全无效 - 中间的
composer是type值，不可省略，必须小写、紧挨着 URL 前面 - 镜像 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 或仍是 https://packagist.org，说明失败，立刻重试。
项目级配置才是多版本共存下的可靠方案
进项目根目录，执行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意：不加 -g）
- 该命令会修改
composer.json中的repositories字段，自动添加或合并，不覆盖已有私有源 - 必须确保
repositories是对象格式（{}），不能是数组（[]）；如果是空数组，先手动改成"repositories": {} - Composer 2.2+ 要求显式禁用官方源：最终生成的结构应为数组格式，首项为
{"packagist.org": false}，第二项才是镜像 - 提交
composer.json到 Git，所有协作者和 CI 环境拉代码后，composer install自动走镜像，无需额外操作
换源后依然卡住？清缓存和旧文件是硬性步骤
镜像只加速元数据下载，但 Composer 会优先读本地缓存和 composer.lock 中记录的旧地址。哪怕刚配好镜像，它也可能还在往 packagist.org 发请求：
- 先清缓存：
composer clear-cache - 删掉
vendor目录和composer.lock - 再执行
composer install（不是update） - 若仍卡在
Resolving dependencies，那和镜像无关，可能是内存不足（临时加COMPOSER_MEMORY_LIMIT=-1）或依赖冲突
最常被忽略的一点：项目里只要定义了 repositories 字段（哪怕只是空对象），全局配置就完全失效——这不是 bug，是 Composer 的硬编码优先级规则。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
