Composer镜像元数据加速必须分两级，因为元数据（如packages.json、provider-*.json）需高频小请求与强一致性，而包文件（.zip）为低频大流量且可容忍滞后；单层换源仅加速包下载，无法解决元数据请求卡顿问题。
为什么 Composer 镜像元数据加速必须分两级
因为 Composer 的元数据（packages.json、provider-*.json）和包文件（.zip）的访问模式完全不同：前者是高频小请求、强一致性要求，后者是低频大流量、可容忍短暂滞后。单层镜像（比如只换源）只能解决包下载慢，但 composer install -vvv 里反复卡在 GET https://mirrors.aliyun.com/composer/p2/xxx.json，说明元数据层还没动——这正是二级加速要补的缺口。
第一级：本地元数据缓存（Composer 自带，但常被忽略）
Composer 2.0+ 默认启用元数据缓存，但它的默认路径 ~/.composer/cache/repo/ 和默认 TTL（7 天）在 CI 或多项目环境下极易失效。不手动调优，等于没开。
-
composer config -g cache-repo-ttl 604800（设为 7 天，避免每日失效重拉） -
composer config -g cache-dir /fast-ssd/.composer-cache（务必指向 SSD，元数据读写频繁） - CI 中必须把
.composer/cache/repo/和.composer/cache/files/同时加入cache: paths，缺一不可 - 若项目含私有包，确认
composer auth已注入环境变量，否则元数据请求会因 401 被缓存为空响应
第二级：分布式中间件缓存（如 Redis + Nginx proxy_cache）
这是突破单机瓶颈的关键。阿里云等镜像源虽快，但所有请求仍经由中心节点，高峰时段 /p2/ 目录下千级 JSON 文件并发 GET 容易打满连接池。用 Redis 缓存元数据响应体 + Nginx 做边缘缓存，能让 95% 的元数据请求不触达上游镜像。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- Nginx 配置需匹配 Composer 的 HTTP 头：对
GET /p2/*.json路径启用proxy_cache_valid 200 24h，并设置proxy_cache_key "$scheme$request_method$host$uri$args" - Redis 缓存 key 建议用
composer:meta:$url_hash，value 存原始响应体 +Content-Type和ETag，避免二次解析 - 必须透传
If-None-Match和If-Modified-Since，否则无法利用镜像源的 304 响应，浪费带宽 - 不要缓存
/packages.json主索引文件超过 1 小时——它更新频繁，过期会导致新包发现延迟
验证二级缓存是否真正生效
光看 composer install 时间没用。真正要看的是元数据请求是否绕过镜像源：
- 加
-vvv运行，检查日志里Downloading https://your-nginx-proxy/p2/...是否出现，且无https://mirrors.aliyun.com/composer/p2/... - 抓包或查 Nginx access log，确认
cache status: HIT出现在大部分/p2/请求中 - Redis 执行
redis-cli --scan --pattern "composer:meta:*" | wc -l，正常应有数百至数千个 key - 删掉本地
.composer/cache/repo/后重装，若仍秒级完成，说明分布式层已兜底
最常被跳过的点：Nginx 没配 proxy_buffering off 导致 JSON 流式响应被截断；Redis 没设 maxmemory-policy allkeys-lru 导致元数据缓存被业务数据挤出；以及忘记在 Composer 全局配置里把 repo.packagist 指向你的 Nginx 地址而非阿里云源。
