必须配置镜像源，因直连 packagist.org 存在高延迟；全局配置需满足三条件：键名 repo.packagist（单数）、type 值不可省略、URL 为 HTTPS 且末尾带斜杠；验证用 composer config -g repo.packagist，输出应为完整 JSON 或正确 URL；项目级配置更可靠，须删 vendor 和 composer.lock 后重装；生效与否看 composer install -vvv 日志是否出现镜像域名。
composer install 卡在 “Loading composer repositories” 或 “Downloading” 阶段，基本可以确定是还在直连 https://packagist.org——不是你网速差，是物理延迟+TLS握手慢导致元数据拉不下来。配镜像源不是“锦上添花”，而是必须做的第一步。
执行 composer config -g repo.packagist 为什么没生效？
90% 的失败不是网络问题，是命令写错三个硬性条件，且 Composer 会静默 fallback 到官方源，不报错也不提示：
-
repo.packagist键名必须是单数，写成repos.packagist（多一个 s）就完全无效 -
composer是 type 值，不是可选参数，漏掉它，新版 Composer 直接忽略配置 - URL 必须是 HTTPS，且末尾必须带斜杠
/，比如https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（拼出 404 路径）
验证是否写入成功，只看这一条命令输出：composer config -g repo.packagist。结果必须是完整 JSON 对象（如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}）或至少是该 URL 字符串。如果返回空、null、报错或仍是 https://packagist.org，说明没写进去。
项目级配置比全局更可靠，尤其在宝塔/CI 环境
全局配置写在 ~/.composer/config.json，但宝塔后台以 www 用户运行，GitHub Actions 用 runner 用户，它们根本读不到你本地 root 或 admin 的配置。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 进项目根目录（含
composer.json），执行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意：不加-g） - 这条命令会自动在
composer.json顶层写入"repositories"字段，key 固定为"packagist"，不会覆盖已有私有源（前提是原repositories是对象结构） - 改完必须删掉
vendor/和composer.lock，再跑composer install（不是update），否则旧 lock 文件里的 hash 可能和镜像元数据不匹配
composer install -vvv 日志里看不到镜像域名？说明没真生效
镜像是否起作用，不能靠猜，得看日志里实际请求的 URL：
- 运行
composer install -vvv，滚动到底部，找类似这行：Reading packages.json from cache at /home/user/.composer/cache/repo/https---mirrors-aliyun-com-composer/packages.json - 如果日志里还出现
https://packagist.org/packages.json或https://packagist.org/p/xxx.json，说明 fallback 了，配置没起效 - 临时验证某个镜像是否可用，用
--repository-url参数最直接：composer install -vvv --repository-url=https://mirrors.tuna.tsinghua.edu.cn/composer/
换源后仍卡在 Resolving dependencies，和镜像无关——那是 PHP 版本约束太宽、dev 分支太多、或 require-dev 工具塞太满导致的依赖解析慢，得去调 composer.json 本身。
