执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 立即生效，自动写入全局配置文件；需验证输出为完整 JSON 对象，且注意项目级 repositories 会覆盖全局配置。
直接执行一条命令就能生效
不需要改文件、不依赖 PHP 扩展、不用重启终端，composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 这条命令跑完立刻生效。它会自动写入 ~/.composer/config.json（Linux/macOS）或 %APPDATA%\Composer\config.json（Windows），Composer 启动时优先读取这个配置。
常见错误现象：composer install 依然卡在 Loading composer repositories——大概率是命令里拼错了键名或 URL 格式。注意三点：
-
repo.packagist是唯一合法键名，不能写成repos.packagist或packagist.org - 第二个参数
composer是 type 值，不可省略 - URL 必须以
/结尾，https://mirrors.aliyun.com/composer/✅，少斜杠会拼出 404 路径
验证是否真的写进去了
别信“执行完就 OK”，必须验证。最可靠方式是运行：composer config -g repo.packagist，输出必须是完整 JSON 对象，例如：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果返回空、null 或报 Key not found，说明没写进去。
额外确认方式：
- 运行
composer diagnose，看Repo packagist.org:这一行是否显示你的镜像地址 - 临时加
--no-cache执行一次composer update --no-cache，观察日志里请求的域名是不是mirrors.aliyun.com - Windows 用户执行完要关掉当前终端再重开，否则可能仍读旧缓存
为什么项目里还是走官方源
Composer 的源优先级是：项目级 composer.json 中的 repositories > 全局配置 > 默认源。只要项目根目录下 composer.json 里有 "repositories": [...] 字段，哪怕只写了 {"packagist.org": false}，全局配置就完全失效。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
排查步骤：
- 进项目目录，运行
composer config repo.packagist，如果输出 URL，说明项目级已覆盖；输出Key "repo.packagist" does not exist，才轮到全局 - 用
grep -n "repositories" composer.json检查是否存在该字段 - CI/CD 流水线中常有人误加
repositories，导致本地快、线上慢
项目级配置更稳妥的场景
全局配置对所有项目生效，但 CI/CD、宝塔面板、GitHub Actions 等环境默认不读全局配置（用户身份不同），这时更适合进项目根目录运行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/。
这条命令会安全地向 composer.json 的 repositories 字段写入结构，不破坏已有配置。注意：
- 项目级镜像地址末尾不能带
/，https://mirrors.aliyun.com/composer✅，带斜杠会 404 - 必须显式禁用原源：
"packagist.org": false，且放在repositories数组里第一项 - 私有源和镜像源共存时，顺序很重要：Composer 按数组顺序查找，不会合并同名包
真正容易被忽略的是：全局配置只改元数据入口（packages.json），ZIP 包仍从原始 dist.url 下载——比如 GitHub 地址。国内公开镜像不托管 ZIP，所以换源后仍可能卡在下载环节。这时候得看具体依赖的 dist.url 是否可直连，而不是只盯着镜像配置本身。
