进Homestead后第一件事是确认当前镜像源是否生效：运行composer config -g repo.packagist，输出必须为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}格式JSON；若为null、空或报错，则配置错误，常见原因是键名误写为repos.packagist或遗漏type值。
进Homestead后第一件事：确认当前镜像源是否生效
别急着执行命令，先看实际配置。在Homestead里运行 composer config -g repo.packagist，输出必须是类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的完整 JSON 对象。如果返回 null、空字符串或报错，说明全局镜像根本没配对——大概率是键名写成了 repos.packagist（多了一个 s），或者漏了 composer 这个 type 值。
正确设置全局镜像源的命令和坑点
直接执行这条命令即可：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
注意三个硬性要求，缺一不可：
-
repo.packagist是唯一合法键名，repos.packagist或mirror都无效 -
composer是必须显式写出的 type 值，不能省略 - URL 必须以
/结尾，https://mirrors.aliyun.com/composer会 404
Windows 用户改完要重启终端；Linux/macOS 用户改完立即生效，但若之前用 sudo composer config -g，可能写进了 root 的 ~/.composer/config.json，而 Homestead 默认用 vagrant 用户运行，得确认配置落在对的地方。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
为什么 composer install 还卡在 “Loading composer repositories”？
常见原因不是镜像没换，而是 DNS 解析慢或缓存未清：
- Homestead 默认 DNS 不稳定，编辑
/etc/resolv.conf，把nameserver改成114.114.114.114或8.8.8.8（临时生效）；更持久的做法是往/etc/network/interfaces的dns-nameservers行加进去 - 旧缓存会继续读 packagist.org 的元数据，必须运行
composer clear-cache（不是composer cache-clear，后者已废弃） - 验证是否真走镜像：运行
composer show laravel/framework -vvv 2>&1 | grep "Downloading"，看到的域名必须是mirrors.aliyun.com类路径
项目级配置优先级更高，别被全局设置误导
如果你的项目 composer.json 里有 "repositories" 字段（哪怕只写了 {"packagist.org": false}），全局镜像就完全失效。检查方式很简单：
- 进项目目录，运行
composer config repositories.0.url，如果有输出，说明项目自己指定了源 - 此时该删掉项目级
repositories，或用composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不带-g）让它安全合并进composer.json - 改完务必
composer clear-cache，再跑composer install -vvv --no-cache看日志里实际请求的域名
真正容易被忽略的是：镜像只加速下载，不解决 Resolving dependencies 卡顿。如果卡在这一步，问题出在依赖约束写法或本地 PHP 环境，跟镜像源无关。
