临时切换用--repository参数单次生效，永久配置执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，该命令写入全局配置文件并优先于项目级配置。
Composer 默认源在国内下载极慢，甚至超时失败，直接切到国内镜像源就能解决——但不是所有镜像都可用，也不是换完就一劳永逸。
怎么临时切换镜像源（单次命令有效）
开发中偶尔需要验证某个包是否能正常安装，或临时绕过公司代理限制，用 -vvv 加 --repository 最直接：
- 临时用阿里云镜像：
composer create-project laravel/laravel demo --repository=https://mirrors.aliyun.com/composer/ - 临时用腾讯云镜像：
composer install --repository=https://mirrors.cloud.tencent.com/composer/ - 注意：
--repository会完全忽略全局配置，只对本次命令生效；若包在镜像中尚未同步（尤其新发布版本），会报Could not find package xxx
如何永久设置全局镜像（推荐方式）
永久生效最稳妥的是改 Composer 的全局配置，不是改 composer.json，也不是靠环境变量：
- 执行：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 验证是否生效：
composer config -g repo.packagist应输出对应 URL - 如果之前手动改过
~/.composer/config.json，优先以该文件为准；-g参数就是操作这个文件 - 某些企业内网会拦截 HTTPS 重定向，可尝试 HTTP 地址（如
http://packagist.phpcomposer.com），但仅限测试环境，不安全
为什么换了镜像还是卡在「Loading composer repositories」
这不是镜像问题，而是 Composer 在解析 composer.json 时触发了递归依赖分析，尤其当项目含大量私有包、或启用了 minimum-stability: dev 时：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先运行
composer diagnose，重点看Checking platform settings和Checking git settings是否报错 - 禁用插件排查：
composer install --no-plugins，有些插件（如hirak/prestissimo）已废弃且与新版 Composer 冲突 - 清理缓存：
composer clear-cache，旧缓存可能残留损坏的元数据 - 镜像本身有延迟：阿里云镜像通常 5–10 分钟同步一次，若刚发布新版本，等一会儿再试
团队协作时镜像配置别提交进 composer.json
composer.json 中的 repositories 字段是项目级配置，一旦写死，所有成员强制走同一源——这在跨地域团队或 CI 环境里极易出问题：
- 不要写：
"repositories": [{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}] - 正确做法：靠文档约定 + 全局配置，或在 CI 脚本开头加
composer config -g repo.packagist ... - 如果项目必须用私有包，应单独定义私有源，而非覆盖 packagist 主源：
composer config --global repositories.my-private '{"type": "composer", "url": "https://private.example.com"}'
镜像只是加速手段，真正影响 Composer 体验的，往往是本地 PHP 配置（如 opcache.enable=0）、DNS 解析异常、或公司防火墙策略。换完源仍慢，先 ping mirrors.aliyun.com 看通不通，再查 composer --version 是否为 2.x —— 1.x 版本即使配了镜像，部分元数据请求仍会回源。
