真正生效的唯一证据是-vvv日志中第一行Downloading的真实URL；需同时满足repo.packagist单数键、type为composer、URL以https://开头且结尾带/、执行composer clear-cache，并确认项目级repositories未覆盖。

看 composer -vvv 日志里的真实 GET URL

配置写进去了不等于 Composer 正在用它——真正生效的唯一证据，是命令执行时实际发出的 HTTP 请求地址。其他所有检查（比如 composer config -g repo.packagist 输出）都只是“你写了什么”，不是“它用了什么”。

执行一次带详细日志的操作，例如：

composer clear-cache && composer require monolog/monolog -vvv

然后在输出里搜索 Downloading，找到第一行类似这样的内容：

Downloading https://mirrors.aliyun.com/composer/packages.json

只要 URL 里出现的是你配的镜像域名（如 aliyun.com、cloud.tencent.com），就说明源已生效。如果看到的是 packagist.org 或 repo.packagist.org，那配置根本没起作用。

查 composer config repositories 确认项目级是否覆盖

即使全局配对了，只要项目根目录的 composer.json 里有 repositories 字段，Composer 就会优先用它，全局配置被完全忽略。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• composer config repositories 在项目目录下运行，有输出就说明项目级源在起作用
• 输出里如果包含 "packagist.org": { "type": "composer", "url": "https://packagist.org" } 或空对象 {}，哪怕只是 "repositories": []，也会导致镜像失效
• 想快速清掉项目级干扰：临时重命名项目下的 composer.json，再跑 composer config -g repo.packagist 验证全局是否真通

确认 composer config -g repo.packagist 输出合法 JSON

这个命令输出必须是完整、可解析的 JSON，且满足四个硬性条件：

• 字段名是 repo.packagist（单数，不能是 repos.packagist 或 repositories.packagist.org）
• type 值必须显式为 "composer"
• url 必须以 https:// 开头，且末尾带 /（例如 https://mirrors.aliyun.com/composer/，少斜杠会 404）
• 输出不能是空、null、Could not find package 报错，也不能是旧版残留的 repositories.packagist

如果输出不符合，说明配置没写进去，或者写错了位置。

别忘了 composer clear-cache

改完配置后不清理缓存，Composer 仍会从旧缓存读取 packages.json 快照，导致：

• composer install 卡在 Loading composer repositories...
• 明明换了源，却报 Package not found（其实是缓存里没更新元数据）
• composer show 列不出包，或版本列表明显滞后

缓存路径通常在 ~/.composer/cache/，但直接执行 composer clear-cache 更可靠——它会清掉所有相关缓存，包括 repo 元数据和 zip 包。

最常被跳过的一步，恰恰是最容易让前面所有操作白费的一步。