Composer镜像配置失效主因是键名错（应为repo.packagist）、缺type值“composer”、URL末尾无/，三者任一出错均静默回退官方源；项目级repositories字段会完全屏蔽全局配置，且必须清缓存、删lock与vendor后重装才生效。
不配镜像，Composer 在国内基本跑不起来——不是慢，是大概率卡在 Loading composer repositories 或直接报 403、timeout。
composer config -g repo.packagist 命令为什么总不生效
90% 的失败不是网络问题，而是命令写错三个硬性点，且 Composer 2.x 会静默 fallback 到官方源，不报错也不提示：
-
repo.packagist键名不能拼成repos.packagist（多一个s就失效） - 中间那个
composer是type值，不是可选参数，漏掉就白配 -
URL必须是 HTTPS + 末尾带斜杠：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会导致路径拼成/composerpackages.json，404）
验证是否写入成功，直接运行：composer config -g repo.packagist。输出必须是完整 JSON 对象，如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、或只返回字符串，说明没写进去。
项目级配置比全局更可靠
全局配置（composer config -g）写在 ~/.composer/config.json，所有项目共享，但 CI、宝塔、Docker 容器里常以 www 或 runner 用户运行，根本读不到 root 的配置。
项目级配置写进 composer.json，可提交 Git，行为一致：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 进项目根目录，执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意：不加-g） - 它会自动向
composer.json的repositories字段追加，不覆盖已有私有源 - 如果
repositories原来是空对象{}，命令会 merge；如果是数组[]，需先手动改成对象再运行 - 改完必须删掉
vendor/和composer.lock，再跑composer install，否则旧 lock 文件里的哈希和镜像元数据不匹配
换源后仍卡在 Resolving dependencies
镜像只加速元数据拉取和 ZIP 下载，不解决依赖解析慢的问题。如果 composer update 卡在 Resolving dependencies 几十秒以上，和镜像无关，典型原因有：
-
php版本约束太宽，比如"php": "^7.4 || ^8.0"，让 Composer 尝试大量组合 - 大量未锁定的 dev 分支依赖，如
"monolog/monolog": "dev-main" -
require-dev里塞了太多工具包，尤其含废弃插件如fxp/composer-asset-plugin（它不走镜像，还额外请求 Bower/NPM 源）
这类问题得调 composer.json 本身，不是换镜像能解决的。
临时验证镜像是否真在用
别信“命令跑完了”，得亲眼看到请求发到了镜像域名：
- 加
-vvv参数运行任意命令，比如：composer show monolog/monolog -vvv - 日志里找
GET请求行，确认 URL 域名是mirrors.aliyun.com或mirrors.tuna.tsinghua.edu.cn，而不是packagist.org - 临时单次切换可用
--repository-url参数，例如：composer create-project laravel/laravel myapp --repository-url=https://mirrors.aliyun.com/composer/
最易被忽略的是：换源后不删 composer.lock 和 vendor 直接重装，结果哈希校验失败、包找不到——镜像同步再快，也救不了旧 lock 文件里的旧元数据。
