全局配置最稳命令是composer config -g repositories.packagist.org '{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}'，需严格满足键名正确、json格式合法、url末尾带斜杠，并执行composer clear-cache验证；项目级配置更适团队协作。
直接切阿里云镜像源最稳，但 composer config -g repo.packagist 命令九成失败不是网络问题，是漏了 -g、写错键名、或 URL 少了末尾斜杠 —— 这三处任意一个出错，都不报错，只静默走官方源。
为什么 composer config -g repo.packagist 没生效？
这不是命令“没运行”，而是 Composer 2.2+ 对配置项识别极严格，写错一点就完全忽略：
-
repo.packagist必须是单数repo（不是repos.packagist或packagist.org） - 必须显式传入
composer作为 type 值：命令里缺这个字，就 fallback 到 packagist.org - URL 必须以
/结尾，否则请求路径拼成/composerpackages.json直接 404 - 没加
-g参数 → 只改当前项目composer.json，换目录就失效 - 执行后没跑
composer clear-cache→ 本地元数据缓存仍指向旧源
全局配置推荐命令（Composer 2.2+ 兼容）
用 repositories.packagist.org 键名更稳妥，避免版本兼容问题：
- 设阿里云源：
composer config -g repositories.packagist.org '{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}' - 设腾讯云源（带 fallback）：
composer config -g repositories.packagist.org '{"type": "composer", "url": "https://mirrors.cloud.tencent.com/composer/"}' - 验证是否写入：
composer config -g repositories.packagist.org，输出应为完整 JSON，不是空或报错 - 务必补上：
composer clear-cache，否则一切白配
项目级配置才是团队协作的正确姿势
全局配置看着省事，但 CI 流水线、宝塔面板、多项目混用时极易出问题 —— 镜像不一致会导致 composer.lock hash 不同、部署失败：
- 进项目根目录，运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意：不加-g） - 它会自动向
composer.json的"repositories"字段写入"packagist"子项，不覆盖已有私有源 - 前提是原
"repositories"是对象（如{"packagist": {}}），不是数组；如果是数组，命令会报错，需先手动转格式 - 提交
composer.json到 Git，新人拉代码后行为完全一致 - 换源后首次
composer install若报 hash 不匹配，删掉vendor/和composer.lock重来
临时调试别动配置，用 -r 参数就行
适合 CI 脚本、帮同事排查、或只试一次 create-project：
- 单次指定源：
composer create-project laravel/laravel myapp -r https://mirrors.aliyun.com/composer/ - 仅当前项目生效（不写进
composer.json）：composer config repo.packagist composer https://mirrors.ustc.edu.cn/composer/（去掉-g） - 加
-vvv看真实请求：composer update -vvv，日志里Downloading行必须含你配的域名 -
--repository-url参数对require无效，只对install/update生效
最易被忽略的一点：镜像只加速下载，不解决 Resolving dependencies 卡顿 —— 那是依赖解析算法或 composer.json 写法问题，和镜像源无关。
