composer config -g repo.packagist 不生效是因为必须同时满足三个硬性条件：键名必须为 repo.packagist（不能多s）、第二个参数必须显式写 composer（type值）、URL必须HTTPS且末尾带/；任一缺失即静默回退官方源，验证需输出完整JSON对象。
composer config -g repo.packagist 为什么总不生效
这条命令不报错，但实际没切源，90% 是因为三个硬性条件漏掉一个：repo.packagist 键名写成 repos.packagist（多一个 s 就静默忽略）；composer 这个 type 值没写，命令变成 composer config -g repo.packagist https://mirrors.aliyun.com/composer/，新版 Composer 直接 fallback 到官方源；URL 缺末尾斜杠，比如 https://mirrors.aliyun.com/composer 会拼出 /composerpackages.json 导致 404。
验证是否真写进去了，只看这一行输出：composer config -g repo.packagist。结果必须是完整 JSON 对象，例如：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果为空、null、报错，或还是 https://packagist.org，说明根本没写进去。
怎么确认镜像真的在用
别信“我执行过了”，要看真实请求路径。运行 composer install -vvv，滚动到日志底部，搜索 Downloading 或 Reading packages.json，确认 URL 域名是 mirrors.aliyun.com、mirrors.tuna.tsinghua.edu.cn 等镜像站，而不是 packagist.org。
更直接的办法是清缓存后重试：composer clear-cache，再跑 composer install -vvv 2>&1 | grep "Downloading"。如果还出现 https://packagist.org/p/ 或 packages.json，说明镜像配置压根没起作用。
CI/CD 或宝塔里镜像为啥还是走官方源
全局配置只写入当前用户的 ~/.composer/config.json。GitHub Actions 的 runner 用户、GitLab CI 的 git 用户、宝塔面板的 www 用户，都读不到你本地 root 或个人账户下的配置。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
排查方法：在对应环境里先切换到实际执行用户，再运行命令验证：
-
sudo -u www composer config -g repo.packagist（宝塔） -
sudo -u runner composer config -g repo.packagist（GitHub Actions 自托管 runner）
正确做法是 CI 脚本中不依赖全局配置，改用临时参数——它优先级最高且不污染环境：composer install --repository=https://mirrors.aliyun.com/composer/ --no-dev --prefer-dist --optimize-autoloader --no-interaction。
项目级配置怎么安全加镜像而不破坏私有源
如果你的 composer.json 已有 repositories 字段（比如配了私有 Git 包或 Satis 源），千万别用 composer config -g repo.packagist ——它会全量替换整个字段，清空原有配置。
正确做法是进项目根目录后，运行不带 -g 的命令：composer config repo.packagist composer https://mirrors.aliyun.com/composer/。Composer 会自动识别现有结构：
- 若原
"repositories": {}是空对象，它新增"packagist"键 - 若原
"repositories": []是数组，它向末尾追加新项，不覆盖已有 Git/VCS 源
改完必须删掉 vendor/ 和 composer.lock，再跑 composer install（不是 update），否则旧 lock 文件里的哈希可能和镜像元数据不匹配。
