全局镜像配置必须满足三要素：-g参数不可省、键名严格为repo.packagist（单数）、type值必须显式写composer且url末尾带/，缺一即静默失效；验证需执行composer config -g repo.packagist输出完整json。
配不成功不是网络问题，是命令写错了三个硬性条件——漏掉任意一个，composer config -g repo.packagist 都会静默失败，不报错、不提示、也不生效。
全局镜像配置必须满足的三要素
这条命令不是“大概对就行”，而是强制校验：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
-
-g不能省：缺了就只改当前目录下的composer.json，换项目就失效 -
repo.packagist是唯一合法键名（注意是repo单数，不是repos；也不能写成packagist.org） -
composer是 type 值，不是注释或可选项——省略后 Composer 2.0+ 会 fallback 回官方源 - URL 必须是 HTTPS，且末尾斜杠
/不可少（少斜杠会导致请求/composerpackages.json，404）
验证是否写入成功，直接运行：composer config -g repo.packagist。输出应为完整 JSON 对象，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果返回空、null 或报 Key does not exist，说明没写进去，立刻检查拼写和斜杠。
项目级配置为什么更可靠
全局配置在宝塔、GitHub Actions、Docker CI 等场景下极易失效——因为它们用的是 www、runner 或容器内用户，根本读不到你本地 root 或 $USER 的配置。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 进项目根目录（含
composer.json），执行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g） - 该命令会自动在
composer.json顶层写入"repositories"字段，key 固定为"packagist"，不会覆盖已有私有源 - 如果项目已有
"repositories": []（数组形式），命令会报错；此时需先手动改成"repositories": {}（空对象）再重试 - 改完必须删掉
vendor/和composer.lock，再跑composer install（不是update）
换源后仍卡在 Resolving dependencies？和镜像无关
镜像只加速包下载，不参与依赖解析。如果你发现 composer update 卡在 Resolving dependencies 几十秒甚至几分钟，问题出在本地环境或 composer.json 写法：
-
"php": "^7.4 || ^8.0"这类宽泛版本约束会让 Composer 尝试大量组合，拖慢解析 -
require-dev里塞了太多未锁定版本的工具链（如"phpunit/phpunit": "^10.0"） - 用了大量
dev-main或dev-develop分支依赖
这类问题换任何镜像都无效，得收紧约束、锁定版本、精简 require-dev。
别踩这些坑
几个高频错误点，容易被忽略但后果严重：
- 手写
"packagist.org": false—— 这会彻底关掉所有源，镜像不可用时整个安装流程直接中断 - 用过时镜像地址，比如
https://packagist.phpcomposer.com（2023 年已下线） - 在 CI 脚本里用
sudo composer config -g，结果写进了root配置，而构建用的是runner用户 - 改完镜像不删
composer.lock，导致 hash 校验失败或元数据不匹配
最稳妥的做法：项目级配置 + 提交 composer.json 到 Git + 每次换镜像后清 lock 文件重装。
