全局启用阿里云镜像需执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，缺-g、少末尾/或键名错误均静默失效；验证须三者同时满足：config输出完整json、diagnose显示阿里云地址、-vvv日志含mirrors.aliyun.com。
直接执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就能全局启用阿里云镜像，但漏 -g、少末尾斜杠、写错键名 repo.packagist 中的任意一个，都会静默失效——不报错，也不加速。
全局配置命令必须带 -g 且 URL 末尾要有 /
这条命令写入的是当前用户的全局配置文件（Linux/macOS 是 ~/.config/composer/config.json，Windows 是 %APPDATA%\Composer\config.json），不是项目级的 composer.json。
-
-g缺失 → 配置只写进当前目录的composer.json，换个项目就失效 -
https://mirrors.aliyun.com/composer少了末尾/→ 请求路径拼成/composerpackages.json，返回 404，自动 fallback 到官方源 - 键名写成
repos.packagist（复数）→ Composer 2.x 完全忽略，查composer config -g repo.packagist返回空或null -
composer这个 type 值不能省 → 否则配置结构不合法，部分版本会静默丢弃
验证是否真生效，别靠“好像快了”
真正有效的判断依据只有三个，缺一不可：
- 运行
composer config -g repo.packagist，输出必须是完整 JSON 对象，例如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - 运行
composer diagnose，看 “Repo” 行是否显示阿里云地址；若仍是https://packagist.org，说明被项目级repositories覆盖了 - 运行
composer install -vvv 2>&1 | grep "Downloading"，日志里出现的域名必须是mirrors.aliyun.com—— 这才是最终确认
项目级配置会覆盖全局，但合并逻辑很微妙
进项目根目录后执行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉 -g），它会往 composer.json 的 repositories 字段里写入 "packagist" 键。
- 如果
composer.json原来有"repositories": {"my-private": {...}}（对象形式），该命令会安全 merge，不会清空原有内容 - 如果
repositories是数组（[{"type": "..."}]），这条命令会直接覆盖整个字段，导致私有源丢失 - 如果
composer.json里写了"repositories": {"packagist.org": false}，等于显式禁用默认源又没指定替代，结果就是Could not find package - 删掉
repositories字段后，必须执行composer clear-cache，否则旧缓存仍可能触发原始请求
临时切换只对单次命令有效，-vvv 不是可选项
适合 CI、排查或测试新镜像时用，完全绕过所有配置：
- 命令示例：
composer create-project laravel/laravel demo --repository=https://mirrors.aliyun.com/composer/ -vvv -
--repository参数优先级最高，会忽略全局和项目级设置 - 不加
-vvv时，日志只显示 “Downloading xxx”，你看不到实际请求的域名，根本无法确认是否走镜像 - 如果提示
Could not find package，大概率是镜像同步延迟（通常 5–10 分钟），不是配置问题
最常被忽略的点：项目级 repositories 配置一旦存在，全局镜像就失效；而 composer config -g 命令本身不校验语法，写错 JSON 格式会导致后续所有 composer 命令直接崩溃报 JSON decode error。
