Composer镜像配置必须严格满足三要素：键名repo.packagist、type值为composer、URL以/结尾，缺一不可，否则静默失效；项目级需置入repositories数组首位并禁用packagist.org，且须删vendor和composer.lock后重装。
composer config -g repo.packagist 必须带斜杠和 type 参数
Composer 2.0+ 不再接受裸 URL，只认完整结构的仓库定义。执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 这条命令时，末尾的 / 和中间的 composer（即 type 值）缺一不可。漏掉斜杠会导致请求 https://mirrors.aliyun.com/composer/packages.json 返回 404；漏掉 composer 参数则写入的是字符串而非对象，后续 composer config -g repo.packagist 输出会是纯 URL，不是 JSON，镜像实际不生效。
parallel-downloads 设为 10 是多数场景甜点值
这个参数只对 composer install 起作用，本质是并发发起 HTTP 下载请求。Composer 2.2+ 默认是 5，基本等于单线程。实测设为 10 可压满千兆宽带，且极少触发临时文件竞争错误。设成 15 在高配环境可行，但 Docker 或低内存 CI 环境容易报 file_put_contents(/tmp/): failed to open stream；设成 20+ 几乎必然失败。验证是否启用：加 -vvv 运行 composer install，日志里会出现类似 Downloading https://mirrors.aliyun.com/composer/dists/ (10 concurrent) 的提示。
换源后必须立刻执行 composer clear-cache
镜像只加速新请求，旧缓存里的元数据（比如 packages.json）还是指向 packagist.org，Composer 会继续用它去拉 provider 列表，结果仍是慢速回源。执行 composer clear-cache 后，下次 install 或 update 才会重新从镜像站拉取完整索引。这一步常被跳过，导致“明明换了源还卡在 Downloading”。注意：如果之前用过已停服的 https://packagist.phpcomposer.com，缓存里可能残留失效地址，清缓存尤其关键。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
有些包就是不走镜像，得单独处理
镜像只接管 repo.packagist.org 元数据和 dist 包下载，以下情况完全绕过镜像：
- 包的
composer.json显式声明了repositories字段（如私有 Git 地址），且没加"packagist.org": false - 依赖中含
"type": "path"的本地路径仓库 - 包被标记为
abandoned，Composer 会尝试回源拉元数据做兼容 - 新发布的包尚未同步到镜像（通常延迟 5–30 分钟），
composer show vendor/package -vvv会显示请求发往repo.packagist.org
遇到这类情况，别反复调镜像配置，先用 -vvv 看真实请求地址，再针对性解决——比如配 GitHub Token 防限流，或手动等同步完成。
