必须将{"packagist.org": false}作为独立对象置于repositories数组首位，再添加镜像源，否则Composer 2.2+会因硬编码兜底导致回退官方源；改完需删vendor和composer.lock后执行composer install，否则lock文件仍沿用旧dist URL。
团队开发中，Composer镜像配置必须写进 composer.json 的 repositories 数组，且首项为 {"packagist.org": false} —— 这是唯一能跨环境、跨成员、跨CI/CD保持行为一致的方案。靠全局配置、环境变量或手动改配置文件，都会在某个环节失效。
为什么 repositories 必须是数组，且第一项必须是 {"packagist.org": false}
Composer 2.2+ 把 packagist.org 当作硬编码源，仅写个镜像 URL 不会禁用它。只有显式声明 {"packagist.org": false} 作为独立数组项，才能切断回退路径。
-
repositories必须是数组（[]），写成对象（{}）会被完全忽略 - 第一项必须是
{"packagist.org": false}，不能合并到第二项里（比如{"packagist.org": false, "type": "composer", ...}是无效的） - 第二项起才是镜像源，例如：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} -
url值末尾必须带/，否则拼接出的路径如/composer/packages.json会 404，触发静默 fallback
改完 composer.json 后，为什么一定要删 vendor 和 composer.lock
composer.lock 里存的是每个包的完整 dist URL（比如 https://api.github.com/.../zipball/），它是旧配置下生成的。Composer 安装时优先读 lock 文件，完全不重新解析 repositories —— 即使你刚加了镜像，它仍按 lock 里写的地址去下载。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须执行：
rm -rf vendor composer.lock，再运行composer install（不是update） -
composer update会复用旧 lock 中的元数据，无法触发新镜像的元数据拉取 - CI 脚本里要显式加这一步，否则缓存会复用旧 lock，构建结果不可控
如何防止全局镜像污染项目行为
只要项目 composer.json 中定义了 repositories 数组，Composer 就会彻底忽略全局的 repo.packagist 配置。但问题在于：有人可能在全局配了镜像，又在项目里写了另一个镜像，结果部分命令（如 composer require）因上下文不同读取逻辑不一致，引发混用。
- 建议团队统一执行：
composer config --global --unset repo.packagist - 验证是否清空：
composer config --global repo.packagist输出应为空或https://packagist.org - CI 脚本开头加一句
composer config --global --unset repo.packagist，防止单独配置残留 - 私有 VCS 源（如 GitLab 私库）不受影响，因为它们是
type: "vcs"，和repo.packagist无冲突
最容易被忽略的点是：改完 composer.json 后只跑 composer update —— 这根本不会生效；还有就是 url 少了个 /，导致请求 404 后静默 fallback 到官方源，日志里却看不出异常。
