实际生效配置须以composer diag输出为准：cache directory:行显示真实缓存路径，composer config -g repo.packagist必须输出合法json对象；环境变量、项目级repositories、url末尾斜杠缺失或权限问题均会导致配置静默失效。
composer config --global 输出不等于实际生效配置
运行 composer config --global cache-dir 或 composer config --global repo.packagist 看到的值，只是配置文件里写的值，不是 Composer 当前真正读取并使用的路径或镜像。它可能被 COMPOSER_HOME、COMPOSER_REPO_PACKAGIST 等环境变量覆盖，也可能因用户权限错位（比如用 sudo 配置但普通用户运行）而完全不加载。
验证是否真生效，必须看 composer diag 输出的 Cache directory: 行，以及 composer config -g repo.packagist 的 JSON 结构是否合法——空、报错、或输出官方源，都说明没生效。
COMPOSER_HOME 路径错配导致全局配置“写对了却读错了”
这是最隐蔽也最常发生的环境变量问题：你执行了 composer config -g repo.packagist，命令成功返回，但后续 composer install 依然连官方源。根本原因是 COMPOSER_HOME 指向了一个你没意识到的路径，比如 CI/CD 中设成了 /tmp/.composer，或宝塔里 PHP 进程以 www-data 用户运行，却读的是 /var/www/.composer 而非你的家目录。
- 先运行
echo $COMPOSER_HOME（Linux/macOS）或echo %COMPOSER_HOME%（Windows），确认变量值是否存在且为绝对路径 - 再运行
composer config --global home，看输出是否与上一步一致；不一致就说明环境变量干扰了默认逻辑 - 若变量存在但路径不可写，Composer 会静默降级到临时目录，此时
composer global require安装的命令根本不会出现在vendor/bin下
项目级 repositories 字段强制屏蔽全局镜像
即使 composer config -g repo.packagist 显示正确，只要项目根目录的 composer.json 里有 "repositories" 字段，无论其值是 []、{} 还是 {"packagist.org": false}，Composer 都会直接跳过全局镜像，回退到默认源或按项目定义解析——没有协商，没有 fallback。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
快速定位：
- 运行
composer config repositories，看输出是否含https://repo.packagist.org（即未被重写） - 执行
grep -A5 '"repositories"' composer.json，检查是否硬编码了空数组或禁用项 - 临时禁用：运行
composer config --unset repositories（注意无-g），再试composer require -vvv | grep "GET https"
镜像 URL 缺少末尾斜杠引发静默回退
配置时漏掉 /，比如写成 https://mirrors.aliyun.com/composer，Composer 会拼出错误请求路径 /composerpackages.json，返回 404 后安静切回官方源——不报错、不提示，日志里只显示 Could not fetch。
真实生效的 URL 必须同时满足：
- 协议为
HTTPS（http://会被拒绝） - 末尾带
/（https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌） - 可手动验证：
curl -I https://mirrors.aliyun.com/composer/packages.json应返回200 OK
环境变量、缓存、项目级配置、URL 格式——这四点任一出错，都会让 Composer 表面“配置成功”，实则请求照旧发往 packagist.org。排查时别跳步，尤其别信 composer diagnose，它压根不校验镜像是否真在用。
