提升打包效率的Composer镜像配置技巧-composer-PHP中文网

composer install慢90%因镜像未生效：键名必须为repo.packagist（单数）、type值必填composer、url须含末尾/，三者缺一即静默回退至packagist.org；验证需config -g输出完整json且install -vvv日志显示镜像路径。

提升打包效率的composer镜像配置技巧

composer config -g repo.packagist 命令为什么总不生效

它不报错，但 install 还是慢得像在直连 packagist.org —— 90% 是因为三个硬条件漏掉一个：repo.packagist 键名写成 repos.packagist（多一个 s）、中间漏掉 composer 这个 type 值、URL 少了末尾的 /。

验证是否真写进去了，别信“命令没报错”：运行 composer config -g repo.packagist，输出必须是完整 JSON 对象，比如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、或还是 https://packagist.org，说明压根没写成功。

repo.packagist 必须是单数、全小写，拼错就静默忽略
第二个参数 composer 是 type 声明，不是可选，漏了就 fallback 到官方源
URL 必须以 / 结尾，https://mirrors.aliyun.com/composer/ ✅，https://mirrors.aliyun.com/composer ❌（会拼出错路径，404 后自动退回去）

CI/CD 中镜像配置为何经常失效

全局配置写在 ~/.composer/config.json，但它只对当前用户生效。GitHub Actions runner、GitLab CI 的 git 用户、宝塔的 www 用户，都读不到你本地 root 或个人账户下的配置。

排查方法：在对应环境里先切到实际执行用户，比如 sudo -u www whoami，再运行 composer config -g repo.packagist 看输出。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

给 www 用户配镜像：sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
CI 脚本中别依赖全局配置，改用临时参数：composer install --repository-url=https://mirrors.aliyun.com/composer/
更稳妥的是项目级配置：composer config repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/（在项目根目录下执行）

并发下载提速但参数名已改

parallel-downloads 已被弃用，Composer 2.2+ 只认 http-max-concurrent-downloads。设了旧参数不报错也不生效，这是最常踩的坑。

正确启用方式：composer config -g http-max-concurrent-downloads 10，推荐值 8–10。超过 12 容易触发镜像限流或本地 DNS 超时。

该配置只对 composer install 有效，composer update 仍需串行计算依赖图
某些企业网络对并发敏感，若出现 file_get_contents(): SSL operation failed，降到 6 或 8
设完建议立刻执行 composer clear-cache，否则旧缓存可能仍走海外源

缓存清理不是万能键，但必须配合镜像一起用

composer clear-cache 只清 ~/.composer/cache/ 里的 zip 和元数据，它对网络问题、镜像未配、PHP 扩展异常完全无效——只在缓存损坏时才真有用。

真正需要清缓存的场景：Invalid signature 报错、中断后残留不完整的 .zip、切换镜像后元数据冲突（比如旧缓存还指向 packagist.org）。

设完镜像后必须立刻执行 composer clear-cache，否则旧缓存仍走海外源
CI 流水线中应缓存 ~/.composer/cache，而不是 vendor/ —— 后者与 PHP 版本、扩展状态强耦合，容易导致上线后 Class not found
composer install --no-autoloader --no-scripts 在 CI 部署阶段可省下 30%+ 时间，跳过生成 autoload 文件和执行钩子

镜像配置本身很简单，但生效链条上任何一个环节断掉——用户权限、参数名、斜杠、缓存残留——都会让提速努力归零。最容易被忽略的是：换镜像只加速下载，不加速 Resolving dependencies；卡在这一步，就得收紧版本约束、关 xdebug、删 require-dev，而不是继续调镜像。