composer镜像未生效主因是配置静默失败：键名必须为repo.packagist（单数）、type值必填composer、url须https且结尾带/，三者缺一不可；验证需输出完整json，否则仍直连packagist.org。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer install 拉取慢，90% 不是网络差，而是镜像根本没生效——换源命令写错、缓存没清、或项目级配置被忽略，都会导致它继续直连 packagist.org。
composer config -g repo.packagist 命令为什么总不生效？
这条命令极易静默失败，不报错也不提示，但实际没写进配置。必须同时满足三个硬条件：-
repo.packagist不能写成repos.packagist（多一个s就彻底忽略） - 中间的
composer是 type 值，不是可选参数，漏掉就 fallback 到官方源 - URL 必须是 HTTPS + 末尾带斜杠：
https://mirrors.aliyun.com/composer/✅；https://mirrors.aliyun.com/composer❌（少斜杠会拼出 404 路径）
composer config -g repo.packagist，输出必须是类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的完整 JSON 对象。空、null 或仍是 https://packagist.org 都说明没写进去。
换源后 composer install 还卡在 downloading？
最常被跳过的一步：composer clear-cache 没执行。缓存里还存着旧的元数据（packages.json、dist URLs），Composer 会优先读缓存，哪怕配置已改，它仍试图从旧地址拉校验信息，结果卡在 DNS 解析或 TLS 握手。
- 执行
composer clear-cache清掉本地缓存 - 如果项目已有
vendor/和composer.lock，建议一并删掉再重装 - 检查是否被项目级
repositories字段覆盖：运行composer config --list和composer config --list --global对比，确认实际生效的是哪个 - CI 或宝塔环境以
www用户运行时，composer config -g写的是root配置（路径为/root/.composer/config.json），www根本读不到；应切到对应用户下执行：sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
项目级镜像配置为什么更可靠？
全局配置无法被 Git 跟踪，团队协作或 CI 流水线中容易失效。项目级配置写进composer.json，行为一致且可复现。
- 进项目根目录，执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g） - 该命令会自动在
composer.json顶层追加"repositories"字段，key 固定为"packagist"，不会覆盖已有私有源 - 如果
composer.json已有"repositories"数组，别手动覆盖；否则私有包仓库可能不可见 - 改完后删掉
vendor/和composer.lock，再跑composer install，看日志里下载域名是不是mirrors.aliyun.com
Resolving dependencies 卡住跟镜像无关
这个阶段完全不走网络，是 Composer 在本地穷举满足所有约束的版本组合。镜像只加速下载，不解决求解慢。
- 避免宽泛版本约束，比如
"^1.0 || ^2.0"或"*"，会让求解器指数级爆炸 - 慎用
dev-main、dev-develop等未锁定分支，它们会触发大量元数据刷新 - 检查
config.platform.php是否与当前 PHP 版本一致，不一致会导致额外兼容性推演 - 老旧的
composer.lock可能引发全量重算，先试composer update --lock轻量更新
composer.json 的 require 规则和本地 PHP 环境。
