真正生效的是运行时合并后的最终源地址，而非composer config -g repo.packagist显示的值；需通过composer diagnose查看“repo packagist.org”行、清缓存、排除项目级repositories覆盖及权限/路径干扰来验证。
composer config -g repo.packagist 输出不等于真正生效
运行 composer config -g repo.packagist 只显示你“写进去的值”，不是 Composer 实际请求时用的地址。常见错误是看到输出匹配镜像 URL 就以为搞定了，结果 composer install 还在连 packagist.org。
真正起作用的是运行时合并后的最终源地址，它可能被项目级 composer.json 中的 repositories 字段覆盖，也可能因缓存未清而继续读旧数据。
- 执行
composer diagnose，盯住Repo packagist.org:这一行——它才是当前实际使用的 URL - 如果这行仍显示
https://packagist.org，说明全局配置没赢过项目配置或环境干扰 - Windows 用户改完必须重启终端；Linux/macOS 下若用过
sudo composer config -g，配置写进了/root/.composer/config.json，普通用户根本读不到
验证必须走真实网络请求，不能只看配置输出
配置只是声明，生效得靠下载行为。最直接的方式是触发一次真实包拉取，并观察日志里的 Downloading 行。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先清缓存：
composer clear-cache（否则可能还在用旧packages.json快照） - 新建空目录，执行：
composer init -n && composer require monolog/monolog --no-install -vvv - 在输出里搜
Downloading，确认出现的是mirrors.aliyun.com/composer/或你设的镜像域名 - 或者更轻量：
composer show laravel/framework 11.* -vvv 2>&1 | grep "Downloading"
项目级 repositories 字段会完全屏蔽全局镜像
哪怕项目 composer.json 里只写了 "repositories": {} 或 "repositories": [{"type": "composer", "url": "https://packagist.org"}]，也会让全局 repo.packagist 配置彻底失效。
- 进项目目录后，先跑
composer config --list | grep repositories，有输出就说明项目自己控了源 - 检查
composer.json是否含repositories字段；有就删掉或注释掉再试 - CI/CD 脚本里用了
sudo composer config -g，但构建用户不是 root，配置根本不会被加载 -
composer diagnose的Repo行若仍指向官方源，八成是这个原因
缓存不清 = 白配，且错误表现很隐蔽
改完配置不清理缓存，Composer 会继续从本地 cache-dir 里读旧的 packages.json 和 dist 包元数据，导致：
-
composer install找不到新版本包 - 依赖解析卡在
Loading composer repositories... - 报错如
Could not fetch https://mirrors.xxx//p2/...（注意双斜杠，是 URL 拼接失败的典型信号） - 即使
composer diagnose显示镜像地址正确，实际请求仍发往旧地址
缓存路径本身也容易误判：别信 composer config --global cache-dir 的输出，composer diag 里 Cache directory: 那行才是真实生效路径。
