composer 3.x+ 元数据请求不由 repositories 控制，必须用 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 全局配置才能接管所有 packages.json、provider-*.json 和 p2/ 请求；repositories 仅影响非 packagist 类型源，且镜像元数据为分片延迟同步结构，验证需以 composer show packagist/support 输出为准。
Composer 3.x+ 的元数据请求根本不由 repositories 控制
很多人改了 composer.json 里的 repositories 数组，加了阿里云镜像 URL，结果 composer install 还是卡在 provider-laravel~10.0.json 上——这不是配置没生效，而是压根走错了路。Composer 2.2 起就把 Packagist 官方元数据源硬编码为 https://repo.packagist.org，repositories 列表只影响非 packagist 类型的源（比如私有 VCS 或 artifact 仓库），所有 packages.json、provider-*.json、p2/ 下的包元数据请求，完全绕过这个数组。
真正接管元数据路由的，只有 composer config -g repo.packagist 这个全局单点配置。它不是“加一个源”，而是直接重写 Composer 内部的元数据入口地址。漏掉 -g、拼错键名（比如写成 repos.packagist）、少写中间的 composer 类型标识、URL 末尾缺 /，都会导致静默 fallback 到官方源。
镜像元数据不是静态快照，而是分片 + 延迟同步的动态索引
Packagist 的元数据结构从来就不是“一个 packages.json 文件 + 一堆 ZIP 包”这么简单。真实结构是三层嵌套：
-
packages.json：只存 provider-includes 映射，比如"p/provider-laravel~10.0.json"，不包含任何实际版本信息 -
provider-*.json：按包名前缀或时间区间切片，例如provider-laravel~10.0.json里才列出laravel/framework所有 10.x 版本的 metadata URL -
p2/vendor/name/version.json：最终的版本级元数据，含 dist URL、sha256、require 等完整字段
镜像站必须完整重建这三层结构，且每层都有同步延迟窗口。阿里云通常滞后 5–10 分钟，中科大和 SJTUG 多数情况 ≤3 分钟，但小众包（如 acme/private-tool）可能根本不进镜像索引——因为镜像只同步 public 包，且依赖 crawler 主动发现。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
自建镜像的元数据校验闭环比想象中严格得多
你以为把 packages.json 和 provider-*.json 文件下载下来放 nginx 就完事？远远不够。真实可用的自建镜像必须满足三个硬性条件：
- dist 包的 URL 必须可回源、可缓存、可重签：官方 dist 链接是带
X-Amz-Expires的临时签名 URL，镜像服务必须能实时抓取、本地缓存，并生成等效新签名，否则composer install直接报Failed to download xxx: The "https://" file could not be downloaded - 所有 JSON 文件的 sha256 值必须与 packagist.org 完全一致：哪怕只是加了个空格、转了下编码、多塞了个 HTTP header，Composer 都会拒绝解析，且错误提示里不告诉你哪一环出问题
- 文件系统必须支持软链接：ZComposer 等主流镜像工具依赖
distdir+ symlink 跳转机制管理海量 ZIP 包，NTFS、部分 NAS 或容器卷不支持 symlink，会导致 500 错误
你看到的 curl -I https://your-mirror/packages.json 返回 200，不代表它能被 Composer 正确消费；唯一验证方式是跑一次干净的 composer require monolog/monolog:^3.0 --no-install，让 Composer 自己走完全部元数据拉取链路。
别用 composer diagnose 判断镜像是否可用
composer diagnose 只检查配置语法、本地网络连通性、缓存目录权限，它不会去请求 provider-laravel~10.0.json，更不会校验 p2/ 下某个具体版本的元数据是否存在。常见误判场景：
- 执行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer（少斜杠）→composer diagnose显示 OK，但实际所有 provider 请求 404，自动 fallback 到官方源 - 镜像站同步滞后，
laravel/framework:10.42.0已发布 8 分钟，但镜像还没生成对应provider-laravel~10.0.json→composer require laravel/framework:10.42.0报Could not find package，而composer diagnose依然绿灯 - 项目
composer.json里残留了旧的repositories配置，覆盖了全局镜像，且不报任何警告
真正有效的验证命令只有两个：composer config -g repo.packagist 看输出是否为带斜杠的完整 JSON；composer show packagist/support 看 URL 字段是否含镜像域名。其它都是障眼法。
