配置镜像源后不生效，最常被忽略的验证方式是检查composer config -g repo.packagist是否输出完整JSON对象，如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；若仅返回字符串、空、null或报错，则配置未写入。
composer config -g repo.packagist 输出必须是完整 JSON 对象
配置镜像源后不生效，最常被忽略的验证方式就是直接看输出结构——composer config -g repo.packagist 必须返回一个合法 JSON 对象，比如：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果只返回字符串（如"https://mirrors.aliyun.com/composer/"）、空、null，或压根报错，说明配置根本没写进去。
用 composer config -g -l 看最终合并生效值
全局配置可能来自多个路径（~/.config/composer/config.json 或 ~/.composer/config.json），手动改 JSON 容易出错且 Composer 会静默跳过非法项。真正起作用的是运行时合并结果，不是某个文件内容。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer config -g -l显示所有最终生效的全局配置项，带(global)标记的才是实际读取到的 - 加
--verbose能看到它到底读了哪个文件：composer config -g -l --verbose - 查镜像是否在生效列表里：
composer config -g -l | grep "repo\|packagist"
执行 install 时观察网络请求行为
配置生效与否，最硬的证据是看 Composer 实际连了哪个域名。运行 composer install -vvv，留意日志中 Loading composer repositories 后面的 URL：
- 出现
https://mirrors.aliyun.com/composer/packages.json→ 镜像已走通 - 出现
https://packagist.org/packages.json→ 仍 fallback 到官方源，配置无效 - 卡在
Resolving packages且无后续请求 → 很可能是镜像 URL 少了末尾/，导致请求/composerpackages.json404 后静默退回到官方源
注意 PHP 环境限制导致命令“假成功”
有些服务器禁用了 proc_open 或 putenv，会导致 composer config -g 表面执行成功，但实际没写入任何配置。这种情况下，composer config -g repo.packagist 一定为空或报错。
- 检查 PHP 是否禁用关键函数：
php -r "echo function_exists('proc_open') ? 'ok' : 'disabled';" - 确认当前用户有权限写入
$COMPOSER_HOME目录（常见于用sudo执行却以普通用户运行install） - 多版本 Composer 共存时，
which composer和实际执行config的可能是不同二进制
