确认当前生效镜像源应执行composer config -g repo.packagist，输出必须是完整json对象如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，空、null、报错或仅字符串说明配置失败；键名必须为repo.packagist（非repos）、type值必须为composer、url末尾必须带/，缺一则静默回退官方源。
怎么确认当前生效的镜像源
执行 composer config -g repo.packagist，输出必须是完整 JSON 对象，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、报错或只返回字符串（如 "https://packagist.org"），说明没配成功。
常见误判点：
-
composer config -g repos.packagist（多一个s）——命令静默失败，不报错也不输出 -
composer diagnose显示 “OK” ≠ 镜像可用，它不验证元数据同步状态或 Composer 2.x 协议兼容性 - 项目根目录下
composer.json里有repositories字段，会完全覆盖全局配置，且不提示
阿里云镜像为什么最稳
不是单次测速快，而是同步延迟低（通常 1–3 分钟）、CDN 覆盖广、对 Laravel/Symfony 等主流包响应一致。截至 2026 年中，它仍是多数生产环境的默认选择。
但要注意三个硬性条件，缺一不可：
- 键名必须是
repo.packagist（不是repos，也不是packagist.org） -
type值必须显式写成composer -
url必须以/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌
漏掉任一，Composer 2.2+ 会静默 fallback 到官方源，无任何警告。
清华、SJTUG、php.cnpkg 各自适用场景
清华源（https://mirrors.tuna.tsinghua.edu.cn/composer/）在教育网和北方地区访问极快，但部分南方用户偶发 DNS 解析慢；对 PHP 8.4 新函数签名验证更严格，偶尔比阿里云晚几小时上线新版本。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
SJTUG 源（https://packagist.mirrors.sjtug.sjtu.edu.cn/）适合 CI/CD 流水线等对稳定性要求高于速度的场景，但需确认出口 IP 是否在教育网白名单内，否则可能直接 403。
php.cnpkg（https://php.cnpkg.org）更新最勤，Laravel 11 和 monorepo 类包几乎当天入库，composer require 失败率最低；缺点是文档弱，出问题只能靠社区反馈。
不推荐再用 https://packagist.phpcomposer.com 或 https://packagist.laravel-china.org ——前者频繁 502，后者已停止维护，composer update 会直接报 Repository not found。
换源后 install 还卡在 Resolving dependencies？
镜像只加速下载，不加速依赖解析。这个阶段卡住，和网络无关，典型原因包括：
- PHP 内存不足（如
memory_limit=128M），临时加COMPOSER_MEMORY_LIMIT=-1测试 - 启用了 xdebug（
php -v可确认），会让解析慢 5–10 倍；可用php -d xdebug.mode=off $(which composer) install临时禁用 -
platform配置与实际 PHP 版本不匹配，触发降级查找逻辑 -
composer.lock里残留已下线包的引用，导致回退搜索；建议删掉vendor/和composer.lock，再跑composer install --no-cache
另外，parallel-downloads 已弃用，必须改用 http-max-concurrent-downloads：执行 composer config -g http-max-concurrent-downloads 10（推荐值 8–10）。
