composer config -g repo.packagist 常因键名拼写（必须是 repo.packagist，非 repos）、type 值缺失、url 缺末尾 / 或用户/环境不一致而静默失效；推荐项目级配置 + clear-cache + 重装 vendor。
全局配置 composer config -g repo.packagist 大概率不生效，不是镜像地址问题，而是执行用户、PHP 环境或拼写细节没对上。
为什么 composer config -g repo.packagist 总是空或无效
这条命令看似简单，但漏掉任一要素就静默失败：键名必须是 repo.packagist（单数 repo，不是 repos），composer 是必需的 type 值，URL 必须 HTTPS 且末尾带 /。写成 repos.packagist 或漏掉 composer，配置会写进无效字段，composer config -g repo.packagist 查出来就是 null 或空对象，install/update 仍走 https://packagist.org。
验证是否真生效，只看这一条命令输出：
composer config -g repo.packagist
正确结果必须是类似：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
- 输出为空、
null或报错 → 配置根本没写进去 - 输出是
https://packagist.org→ 全局配置被项目级repositories覆盖了 - URL 缺末尾
/→ Composer 2.2+ 可能拼出/composerpackages.json，直接 404
宝塔、CI、多用户环境下别碰 -g 全局配置
你在终端用 root 执行了 composer config -g，但宝塔后台“一键部署”是以 www 用户运行的，它读的是 /home/www/.composer/config.json，根本看不到 root 的配置；CI 脚本里用 sudo composer config -g，结果写进了 root 家目录，而构建容器里实际跑命令的是 runner 用户，照样失效。
更可靠的做法是进项目根目录，运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
它会自动往 composer.json 的 repositories 字段安全合并（前提是原 repositories 是对象，不是数组）。这个改动可提交 Git，所有人拉代码后行为一致。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 如果
composer.json里已有"repositories": []（数组），命令会报错，得先手动改成"repositories": {} - 别手写
"packagist.org": false—— 这会彻底关掉官方源，镜像临时不可用时，composer install直接失败 - 改完记得删掉
vendor和composer.lock再重装，否则旧 lock 文件里的 hash 可能和镜像元数据不匹配
composer clear-cache 这步不能跳
缓存里存着旧的 packages.json 和 provider 元数据，Composer 会优先读本地缓存再校验远程地址——哪怕你已经切了镜像，它仍可能反复尝试从 https://packagist.org 拉取索引，卡在 DNS 解析或 TLS 握手阶段。
执行：
composer clear-cache
注意：composer cache-clear 是旧命令，已废弃，用了也没用。
- 验证是否清干净：检查
~/.composer/cache/目录是否为空，或运行composer --version后立刻composer install -vvv --no-cache，看日志里请求的是哪个域名 -
--no-cache是临时绕过缓存验证的最快方式，适合排查
Ansible 自动化部署时的三个硬坑
直接用 shell 模块调 composer config -g 在 Ansible 里大概率白干：Ansible 默认以非交互、非登录 shell 执行，~/.composer/config.json 可能写进了 root 家目录，但实际 PHP 进程跑在 www-data 下，压根读不到。
推荐用 community.general.composer 模块，它自动检测 PHP 路径、校验 composer.json 存在性，且支持 no_dev、optimize_autoloader 等关键参数：
-
working_dir必须指向含composer.json的目录，且该目录对运行 Ansible 的用户有读写权限 - 若 PHP 不在默认路径，必须显式指定
php_executable: /usr/local/bin/php - 中文镜像源必须写进
config.json（即项目级配置），不能只靠命令行参数或环境变量，否则下次install仍走国外源
真正容易被忽略的是：改完配置后，composer.lock 里的包哈希值仍来自旧源，不删不重装，速度问题根本不会消失。
