根本原因是命令结构三要素缺一不可：键名必须为repo.packagist（单数）、type值必须显式写composer、url末尾必须带/；任一错误均静默失效，查配置返回空或null且不报错。
composer config -g repo.packagist 命令为什么总不生效
根本原因不是网络或权限问题，而是命令结构缺一不可：键名必须是 repo.packagist（单数、无 s），type 值必须显式写成 composer，URL 必须以 / 结尾。任意一处错，配置就静默失败——查 composer config -g repo.packagist 会返回空或 null，但不会报错。
常见错误包括：
- 写成
repos.packagist（多一个s）→ 写入无效字段，完全被忽略 - 漏掉
composer类型参数 → Composer 2.0+ 会 fallback 到官方源，等于白配 - URL 少了末尾斜杠，比如
https://mirrors.aliyun.com/composer→ 请求路径拼成/composerpackages.json，直接 404
项目级配置比全局更可靠的实际原因
全局配置看似省事，但在真实协作和部署场景中容易翻车：
- 项目里若已有
"repositories": {"packagist.org": false}或空对象，会直接屏蔽全局镜像 - CI 流水线中不同节点用户不同（如
wwwvsroot），-g配的配置可能根本没被读到 -
composer.json中的repositories字段无法被 Git 跟踪，新人拉代码后行为不一致
正确做法是进项目根目录，运行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意：去掉 -g）
它会自动在 composer.json 的 repositories 对象里安全追加 "packagist" 条目，不覆盖已有私有源。
验证镜像是否真在用的唯一可靠方式
别只看命令有没有报错，得确认请求实际发到了哪里：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 执行
composer install -vvv或composer update -vvv - 在输出日志里搜
GET或Downloading，看 URL 是不是你配的镜像地址（如https://mirrors.aliyun.com/composer/packagist.json） - 如果看到
packagist.org或https://repo.packagist.org，说明镜像没生效
临时验证某个镜像是否可用，也可跳过配置直接试：composer install --repository-url=https://mirrors.huaweicloud.com/repository/php/composer/ -vvv
这个参数会完全忽略所有已存配置，强制走指定地址。
当前推荐镜像及已失效地址提醒
截至 2026 年 4 月，以下镜像仍稳定可用：
- 阿里云：
https://mirrors.aliyun.com/composer/（最稳，CDN 覆盖全，同步快） - 腾讯云：
https://mirrors.cloud.tencent.com/composer/ - 华为云：
https://mirrors.huaweicloud.com/repository/php/composer/（注意路径含/repository/php/）
已明确失效的地址（访问即 404）：
-
https://packagist.phpcomposer.com（bootcss 停服） https://pkg.phpcomposer.com
换源后首次运行若提示 hash 不匹配，删掉 vendor/ 和 composer.lock 重来即可。真正容易被忽略的是：镜像只加速包下载，不解决依赖解析慢的问题——那得靠 composer update --with-dependencies 或升级到 Composer 2.5+ 的新解析器。
