composer config -g repo.packagist 命令必须严格满足四个条件才生效：键名是 repo.packagist（非 repos）、显式指定 composer 类型、URL 末尾带 /、必须加 -g 参数；否则静默回退至官方源且不报错。
composer config -g repo.packagist 为什么总不生效
不是镜像源慢，是命令写错一个字符就静默 fallback 到 https://repo.packagist.org，且完全不报错。常见失效原因有四个硬性条件漏一即废：
-
repo.packagist键名不能写成repos.packagist（多一个 s 就彻底被忽略） - 中间的
composer是type值，必须显式写出，不能省略或替换成composer2 -
https://mirrors.aliyun.com/composer/末尾斜杠/不可少——少了会拼出/composerpackages.json导致 404 -
-g参数不能漏——漏了只改当前项目composer.json，换目录、换用户就失效
验证是否成功：运行 composer config -g repo.packagist，输出必须是完整 JSON 对象，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null、报 Key not found 或仍显示官方地址，说明根本没写进去。
项目级配置如何避免覆盖私有仓库
只要 composer.json 里存在 repositories 字段（哪怕只是 "repositories": {}），全局镜像就会被屏蔽。手动编辑极易格式出错，正确做法是进项目根目录后执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不加 -g）
这条命令会自动合并：
- 若原 repositories 是空对象，它转为标准结构并插入 packagist 条目；
- 若已是数组（如含私有 Git 源），它追加新项，不破坏原有顺序；
- 绝对不要手写 "packagist": false——这会导致 php、ext-json 等基础扩展校验失败。
改完必须立刻运行 composer update --lock，否则 composer.lock 仍记录旧源地址，下载时实际不走镜像。
并发下载与缓存路径必须同步配
镜像配对了，但 composer install 还卡在 Downloading，大概率是旧缓存还在拉海外索引，或并发线程太低压不住带宽：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先清缓存：
composer clear-cache - 设并发数：
composer config -g parallel-downloads 8（推荐值；设为 10 容易触发file_put_contents(/tmp/): failed to open stream） - 显式配置缓存路径：
composer config -g cache-files-dir ~/.composer/cache/files（确保路径真实可写，否则每次下载都不落盘）
内网可信环境可关 HTTPS 校验减负：composer config -g secure-http false，但生产对外服务严禁启用。
CI/CD 和宝塔里全局配置为啥不起作用
全局配置写在 /root/.composer/config.json，但它只对 root 用户生效。宝塔「一键部署」、PHP 管理器、计划任务默认以 www 用户运行，根本读不到 root 的配置。
解决方法很直接：确认实际执行用户（比如 whoami 或查日志 UID），再针对性配置：
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
GitHub Actions 等 CI 环境默认不读全局配置，需在 workflow 中显式设置 COMPOSER_HOME，或改用项目级配置 + --no-scripts --no-autoloader 减负。
最易被忽略的是：镜像只管“从哪下”，不管“下什么”——composer.lock 里的哈希、平台版本、缓存路径三者不对齐，哪怕镜像再快，也会退化为暴力重装 vendor。
