composer config -g repo.packagist 输出为空或报错说明配置根本未写入，根本原因是键名必须为单数repo.packagist、type值必须显式写composer、url须https且末尾带/，三者缺一即静默失效；验证需输出完整json对象如{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}。
composer config -g repo.packagist 输出为空或报错？说明根本没写进去
这不是网络问题，是命令没命中 Composer 的配置键名规则。Composer 2.0+ 对 repo.packagist 键名极其严格：必须是单数、小写、不能多一个 s（repos.packagist 会被静默忽略），且必须带 -g 参数。
常见失败原因：
-
composer config repo.packagist composer https://mirrors.aliyun.com/composer/漏了-g，只改了当前目录的composer.json -
composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/多写了一个s，键名无效 -
composer config -g repo.packagist https://mirrors.aliyun.com/composer/少了中间的composertype 值，Composer 直接 fallback 到官方源
验证方式只有一条：composer config -g repo.packagist。输出必须是完整 JSON 对象，例如：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。返回空、null 或 Key "repo.packagist" does not exist，就等于没配成功。
明明有输出，但 composer install 还在连 packagist.org？检查项目级 repositories 是否覆盖全局
只要项目根目录的 composer.json 里存在 "repositories" 字段（哪怕值是空对象 {} 或 "packagist.org": false），全局镜像就会被无条件屏蔽——不是“优先级低”，是彻底跳过，且不提示。
排查步骤：
- 进项目目录，运行
composer config repositories，看packagist.org对应的url是什么 - 用
grep -A5 '"repositories"' composer.json查是否硬编码了旧源（比如已下线的https://packagist.phpcomposer.com） - 临时清除项目级设置：
composer config --unset repositories（注意没有-g），再试composer install
特别注意：create-project 默认读取模板里的 composer.json，所以初始化 Laravel 或 ThinkPHP 时，即使全局配了镜像，也会走模板自带的源。
curl 测试返回 404 或超时？别信 composer diagnose，它根本不发请求
composer diagnose 只校验 PHP 环境和缓存路径，完全不读镜像配置，也不发任何网络请求。它显示 OK ≠ 镜像可用。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
真实验证方式只有一条：curl -I https://mirrors.aliyun.com/composer/packages.json。必须返回 HTTP/2 200 或 HTTP/1.1 200 OK。
常见错误响应：
-
HTTP/2 404：URL 缺末尾/，比如https://mirrors.aliyun.com/composer→ 实际请求变成/composerpackages.json -
Curl error: Could not resolve host：镜像地址已变更，比如华为云现用https://repo.huaweicloud.com/repository/php/，不是旧版mirrors.huaweicloud.com
如果 curl 通了但 composer install 仍卡住，记得先执行 composer clear-cache——缓存里存的是旧源元数据，不清掉不会更新请求地址。
加 -vvv 后日志里还是 packagist.org？说明配置未生效或被覆盖
最可靠的运行时验证方式是加 -vvv 参数观察真实请求 URL。例如运行 composer -vvv require monolog/monolog，日志中出现的 GET https://xxx/composer/packages.json 才是你实际连接的地址。
如果日志里仍是 GET https://packagist.org/packages.json，说明：
- 全局配置写错（键名、type、URL 格式任一不符）
- 项目
composer.json中repositories字段存在且未禁用官方源 - CI/CD 环境（如 GitHub Actions）未显式执行配置命令，它不继承你的本地
-g设置
复杂点在于：Composer 2.2+ 已废弃 repo.packagist，改用 repositories.packagist.org.type 和 repositories.packagist.org.url 双字段，但很多文档还在教旧写法。如果你用的是新版本，composer config -g repo.packagist 有输出也纯属“历史残留”，实际不生效。
