根本原因是三个硬性条件任一缺失：键名必须为单数repo.packagist、type值必须显式写composer、URL必须HTTPS且末尾带/；任一出错即静默回退官方源，验证需输出完整JSON对象。
composer config -g repo.packagist 为什么总不生效
根本原因不是网络卡，而是命令漏了三个硬性条件：键名必须是 repo.packagist（不能多写 s 变成 repos.packagist），composer 是必填的 type 值（不是可选参数，也不能当注释删掉），URL 必须以 https:// 开头且末尾带 /（比如 https://mirrors.aliyun.com/composer/✅，少斜杠就拼出 /composerpackages.json 导致 404❌）。
验证是否真写进去了，只看这一条命令输出：composer config -g repo.packagist。正确结果必须是完整 JSON，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、报错、或只返回一个 URL 字符串，都说明配置失败。
常见踩坑点：
- Windows 用户执行后没重启 PowerShell/CMD，环境读不到新配置
- 宝塔、Docker 或 GitHub Actions 中以
www或runner用户运行，-g写的是你本地用户的~/.composer/config.json，权限不一致直接失效 - PHP 禁用了
proc_open或putenv（常见于容器或面板环境），config -g会静默失败或报错，需检查php.ini并重启服务
项目级配置为何更可靠，尤其对开源项目
开源项目协作时，全局镜像配置基本不可靠——别人 clone 下来没配过镜像，CI 流水线用的是 runner 用户，Docker 构建镜像里压根没有 ~/.composer 目录。项目级配置写进 composer.json，Git 可追踪、所有环境一致读取。
但要注意：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不带 -g）会**全量替换** repositories 字段，不是追加。已有私有源或 VCS 配置会被清空。
安全做法是手动编辑 composer.json：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 确保
"repositories"是数组（[]），不是对象（{}）；若已是对象，先改成空数组 - 把国内镜像放在首位：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - 显式保留官方源兜底：
{"packagist.org": false}不要写，否则基础包拉不到；应写{"type": "composer", "url": "https://packagist.org/"}放在数组末尾 - 已有
composer.lock时，换源后必须删掉vendor/和composer.lock，再跑composer install（不是update）
换源后仍卡在 “Loading composer repositories” 怎么排查
这不是镜像没生效，是 Composer 还在读旧缓存和旧 composer.lock 里的地址。哪怕你刚配好镜像，它仍可能从 packagist.org 的元数据里解析依赖，卡住超 30 秒。
必须做三件事：
- 先执行
composer clear-cache—— 清缓存是唯一有效手段，composer update -v不会自动刷新 - 删干净
vendor/和composer.lock（Windows 用rd /s/q vendor && del composer.lock） - 加
-vvv重试：composer install -vvv，盯紧日志里请求的域名是不是mirrors.aliyun.com或其他镜像域名；如果还出现packagist.org，说明composer.json里repositories结构异常，或写了"packagist.org": false却没配对的"packagist"镜像
多个镜像源怎么配才真正起作用
Composer 不并行查源，而是按 repositories 数组顺序逐个尝试，第一个能返回包信息的源就用它，后面全跳过。所以“多个镜像”不是负载均衡，是 fallback 链。
推荐结构（以 Laravel 开源项目为例）：
"repositories": [
{
"type": "composer",
"url": "https://mirrors.aliyun.com/composer/"
},
{
"type": "composer",
"url": "https://mirrors.tuna.tsinghua.edu.cn/composer/"
},
{
"type": "composer",
"url": "https://packagist.org/"
}
]
注意点：
- 阿里云放最前（通用性强、同步快），清华源次之（北方教育网优化），官方源最后兜底
- 不要混用不同类型的源（比如同时加
path和composer类型），某些私有包或abandoned标记包会绕过镜像直连官方源 - 镜像同步有 5–30 分钟延迟，新发布版本（如
laravel/framework v11.0.0）可能还没同步，可用composer show laravel/framework -vvv观察真实请求域名
复杂点在于：镜像配置不是“开关”，而是一套优先级+fallback+缓存强耦合的机制。最容易被忽略的是——哪怕你改对了所有配置，只要没清缓存、没删 lock 文件、没验证 -vvv 日志，就永远不知道实际走的是哪个源。
