镜像未生效是因命令漏写三要素：repo.packagist（单数）、type值composer、URL以/结尾的HTTPS地址，缺一则静默失效，验证需执行composer config -g repo.packagist并确认输出完整JSON。
卡在 Downloading 或 Resolving dependencies through SAT，90% 不是网络差，而是镜像根本没生效——命令漏了 composer 类型标识、repo.packagist 写成复数、URL 缺末尾 /，三者任一出错，配置就静默失效。
composer config -g repo.packagist 命令必须写全三要素
这不是“可选参数”，而是硬性三元组：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/。漏掉任意一个，composer config -g repo.packagist 查出来就是空或 null，install/update 仍走 packagist.org。
-
-g：必须加，否则只改当前项目composer.json，不是全局 -
repo.packagist：键名必须是单数、全小写、不能带s（repos.packagist或repositories都无效） -
composer：这是type字段值，不是注释，省略会导致 fallback 到官方源 -
https://mirrors.aliyun.com/composer/：URL 必须 HTTPS，且末尾必须有/，否则拼接路径出错（比如变成/composerpackages.json），直接 404
换了镜像还是卡在 installing xxx (v1.2.3)
说明 Composer 正在尝试下载包文件，但 composer.lock 里还记着原始 packagist.org 的 dist URL。镜像只代理元数据和 ZIP 包分发，不改 lock 文件里的地址。
- 执行
composer update --lock强制刷新 lock 文件中的下载链接 - 某些包启用了
dist+source双模式，镜像只代理dist（ZIP），而source（Git）仍直连 GitHub —— 这类包无法通过换镜像加速 - 如果项目含私有包、
path类型仓库，或"packagist.org": false显式禁用，Composer 会绕过镜像，直连 GitHub 或自定义源
验证镜像是否真正生效
别信“命令跑过了”，唯一可靠方式是看输出：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer config -g repo.packagist，输出必须是完整 JSON 对象，如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - 若输出为空、
null、false，或含packagist.org，说明没写对 - 执行
composer install -vvv，日志里出现的域名必须是镜像域名（如mirrors.aliyun.com），而不是packagist.org -
composer diagnose中 “Repo.packagist.org” 行显示 “OK” 并附带镜像地址，才表示成功
项目级配置优先级高于全局，容易被忽略
只要项目 composer.json 里存在 "repositories" 字段（哪怕只是空数组 []），全局镜像就会被跳过。这是最常被踩的坑。
- 检查项目根目录下
composer.json是否含"repositories"键；若有，确认其中是否显式写了"packagist.org": false或其他源 - 若需保留项目级配置又想用镜像，得把镜像地址显式加进该数组，并确保顺序靠前
- 私有包场景下，全局镜像 + 项目级
repositories叠加，可能触发Package not found，排查成本远高于直接删掉项目级配置
镜像同步本身有 5–30 分钟延迟，新发布的包可能还没同步到镜像站；另外，PHP 扩展缺失（如 openssl 或 curl 版本过低）会导致 HTTPS 握手失败，现象是“超时”，实为协议层报错——这些点不排查，光换镜像没用。
