composer config -g repo.packagist 命令常不生效，根本原因是键名（必须为单数repo.packagist）、type值（必须显式写composer）和url（必须https且末尾带/）三要素缺一即静默失效，验证需执行composer config -g repo.packagist并确认输出为完整json对象。
composer config -g repo.packagist 命令为什么经常不生效
根本原因不是网络或镜像站问题，而是命令写错后 Composer 静默失败——不报错、不提示、只当没这回事。repo.packagist 键名漏掉 repo. 前缀、多写一个 s 变成 repos.packagist、漏掉中间的 composer type 值、URL 少末尾 / 或用 http 代替 https，都会导致配置写入无效字段。
验证是否成功只需一行：composer config -g repo.packagist。输出应为完整 JSON 对象（如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}），若返回空、null 或报 Key does not exist，说明根本没写进去。
-
composer config -g repos.packagist ...→ 多个 s，无效 -
composer config -g repo.packagist https://...→ 缺composertype，fallback 到默认源 -
composer config -g repo.packagist composer http://...→ Composer 2.0+ 拒绝 HTTP，直接跳过
项目级 repositories 字段为何比全局配置更可靠
全局配置依赖执行用户与运行用户一致——你在终端用 root 执行了 composer config -g，但宝塔后台用 www 用户、CI 流水线用 runner 用户、Docker 容器里甚至没有 ~/.composer 目录，配置就完全不可见。
项目级配置直接写进 composer.json，提交 Git 后团队成员和 CI 环境行为一致，且优先级高于全局配置，不会被绕过。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（无-g）会自动合并到"repositories"对象中，key 固定为"packagist" - 如果
composer.json里已有"repositories": []（数组格式），该命令会失败；需先手动改成"repositories": {}再重试 - 千万别手写
"packagist.org": false—— 这会彻底禁用基础包索引，连laravel/framework都装不上
repositories 数组顺序 ≠ 查找顺序，而是“命中即停”
很多人以为把阿里云镜像写在 repositories 数组第一行就一定优先，其实不是。Composer 不是按数组顺序逐个请求、等超时再试下一个；它对每个仓库并发发起元数据请求（如 /packages.json），只要某个源返回 HTTP 200 + 有效 JSON（哪怕只是空列表），就立刻采用该源，后续全跳过。
所以真正决定谁胜出的，是响应速度和有效性，不是位置。但有个硬前提："packagist.org": false 必须作为独立对象显式写在 repositories 数组末尾，否则官方源仍会隐式兜底，且一旦它返回元数据（哪怕只是同名占位包），你的私有源或镜像就永远没机会响应。
-
"repositories": [{"type":"composer","url":"https://mirrors.aliyun.com/composer/"},{"packagist.org":false}]✅ 正确结构 -
"repositories": {"packagist":{...},"packagist.org":false}❌ 键名错误、格式错乱，composer validate会失败 - 私有源要真正生效，必须确保其 URL 能稳定返回 200 + 含目标包的 JSON，否则即使排第一也输给了镜像
换镜像后 vendor 和 composer.lock 为什么必须删掉重装
composer.lock 文件里存的是包下载地址的哈希值，不是纯版本号。如果之前用的是 packagist.org 的元数据生成的 lock 文件，现在切到阿里云镜像，但没删 lock，Composer 仍会尝试从旧地址下载，结果 404 或校验失败。
同样，vendor/ 目录里可能残留旧源拉下来的文件，autoload 映射和符号链接也可能不一致，直接 composer install 会跳过重装、沿用旧状态，导致行为异常。
- 换镜像后首次运行前，务必执行：
rm -rf vendor composer.lock - 再跑
composer install（不是update），让 Composer 重新解析、拉取、生成新 lock - CI 脚本里建议加
composer clear-cache，避免本地缓存干扰
Resolving dependencies 卡住的问题。如果你发现 composer update 在那个阶段耗时几十秒，那和镜像无关，得查 composer.json 里的约束写法、PHP 版本兼容性或本地内存限制。
