配置未写入成功，因键名必须为repo.packagist（单数）、type值必须显式指定composer、URL须HTTPS且以/结尾；输出为空或非JSON说明根本未存入，Composer 2.x会静默回退至packagist.org。
composer config -g repo.packagist 输出为空或不是 JSON 对象？
说明配置根本没写进去，不是“没生效”，是压根没存成功。Composer 2.x 会静默回退到 https://packagist.org，不报错也不提醒。
必须同时满足三个硬条件：
-
repo.packagist是唯一合法键名（repos.packagist、repositories.packagist都无效） - 命令末尾必须显式传入
composer作为 type 值：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - URL 必须 HTTPS 且以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（拼路径时变成/composerpackages.json，404）
验证是否真写进去了：运行 composer config -g repo.packagist。输出必须是完整 JSON 对象，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。
composer install -vvv 日志里没出现镜像域名？
说明 Composer 没走你配的镜像，而是 fallback 到了官方源，或者被项目级配置覆盖了。
执行 composer install -vvv 2>&1 | head -n 10 | grep Downloading，第一行 URL 才是真实请求地址；只看 composer config 输出没用。
检查项目根目录 composer.json 是否含 "repositories" 字段：哪怕只是空数组 []，也会完全屏蔽全局镜像。
临时清掉项目级配置：composer config --unset repositories（注意没 -g）。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
换源后仍报 404、SSL 错误或 JSON decode error？
不是网络不通，而是缓存残留、元数据损坏或镜像同步延迟导致 Composer 拿着旧路径去新源上找不存在的东西。
先执行 composer clear-cache；Windows 用户还得手动删 %LOCALAPPDATA%\Composer\cache。
删掉 vendor/ 和 composer.lock——composer.lock 里硬编码了旧 provider 地址，不删它，Composer 就一直重试失败路径。
手动验证镜像可用性：curl -I https://mirrors.aliyun.com/composer/packages.json 必须返回 HTTP/2 200；若返回 HTML 页面（如人机验证），说明该镜像不适合自动化场景。
宝塔/CI/Docker 环境里全局配置失效？
你用 root 配的全局镜像，但实际运行的是 www 用户，得用 sudo -u www composer config -g 单独配。
CI runner（如 GitHub Actions）或 Docker 容器里可能根本没有 ~/.composer 目录，全局配置天然不可靠。
更推荐做法：进项目根目录，运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加 -g），它会自动合并到 composer.json 的 repositories 字段中，key 固定为 "packagist"。
