全局配置通过composer config -g配置但需注意执行用户权限，项目级配置才是团队协作和CI的可靠选择，临时禁用镜像可用--no-cache等参数调试。
全局配置：适合本地开发，但要注意用户权限
执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 即可写入当前用户的全局配置文件（~/.composer/config.json）。它对所有项目生效，省事直接。
但容易踩的坑是：在宝塔、Docker 或 CI 环境中，命令可能以 www、runner 或容器内用户身份运行，而你终端里用的是 $USER，结果配了等于没配。验证时别只看自己终端输出，得确认实际执行命令的用户是否也配好了——比如宝塔里跑 composer install，就得用 sudo -u www composer config -g repo.packagist ...。
常见失败现象：composer config -g repo.packagist 返回空或报 Key "repo.packagist" does not exist，说明根本没写进去。原因通常是：repos.packagist（多 s）、漏掉中间的 composer type 值、URL 少了末尾 /。
项目级配置：团队协作和 CI 的唯一可靠选择
进项目根目录（含 composer.json），运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉 -g）。它会自动往 composer.json 顶层的 repositories 字段写入镜像定义，不破坏已有私有源。
注意两点硬约束：
– 如果项目 composer.json 里 "repositories" 是数组（[]）而非对象（{}），命令会直接报错，需先手动改成空对象；
– 配完必须删掉 vendor/ 和 composer.lock，再跑 composer install，否则旧 lock 文件仍按原元数据地址解析，镜像形同虚设。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
项目级配置优先级高于全局，哪怕你本地配了全局，只要项目里有 repositories，就一定会走项目级定义——这是协作一致性的基础，不是“备选方案”，而是必须项。
临时禁用镜像：调试网络或验证问题根源
换源后仍卡在 Loading composer repositories 或 Resolving dependencies，大概率不是镜像的问题。这时候要快速排除干扰，用 --no-cache 和 --prefer-source 组合绕过缓存和二进制包逻辑：
-
composer clear-cache清掉本地元数据缓存 -
composer install --no-cache -vvv 2>&1 | grep "Downloading"观察真实请求域名是否变成镜像地址 - 若仍卡在
Resolving dependencies，立刻停手——镜像不参与依赖解析，问题出在composer.json的版本约束太宽（如"php": "^7.4 || ^8.0"）、require-dev里塞了太多未锁定的工具链，或用了大量dev-main分支依赖
临时切回官方源调试也很简单：composer config -g --unset repo.packagist。但别长期用，国内直连 packagist.org 的 TLS 握手延迟常超 300ms，元数据请求失败率高，不是“慢一点”，而是根本不可靠。
最易被忽略的一点：镜像只改下载路径，不加速依赖解析。很多开发者反复折腾镜像地址，却没意识到 composer update 卡住几十秒，真正瓶颈在本地 PHP 环境（比如 proc_open 被禁用）或 composer.json 写法本身。
