线上紧急热修复却卡在依赖获取？平时就该备好Composer镜像源！-composer-PHP中文网

线上 composer install 卡住是因直连 packagist 官方源网络不稳定，需通过 composer config -g 配置国内镜像源（如阿里云）并确保 web 进程用户生效，且注意 composer 2.x 兼容性及私有仓库单独配置。

线上紧急热修复却卡在依赖获取？平时就该备好composer镜像源！

为什么线上热修复时 `composer install` 会卡住？

因为默认走的是 Packagist 官方源（https://packagist.org），而它在国内直连极不稳定，DNS 解析慢、TLS 握手超时、响应 503 都很常见。热修复场景下你没时间等重试，更不能接受因依赖拉不下来导致回滚失败。

这不是 Composer 本身的问题，而是网络路径不可控——尤其在阿里云华北、腾讯云华南等机房，出向境外请求常被 QoS 限速。

现象：执行 composer install 卡在 Downloading https://packagist.org/packages.json 或某包的 .zip 地址上，Ctrl+C 后看到大量 Connection timed out
关键点：线上环境通常禁用交互式操作，--verbose 只能帮你定位卡在哪，不能解决问题
别指望临时换源：手动改 composer.json 的 repositories 字段无效，因为 composer install 默认只认全局配置或项目根目录的 composer.json，而热修复包往往没带完整配置

怎么让线上机器「开箱即用」支持国内镜像？

核心是把镜像源写进 Composer 的全局配置，且确保该配置对所有用户（包括 www-data、nginx 等运行 Web 进程的用户）生效。

Discussion Composer

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

下载

执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（推荐阿里云镜像，稳定、同步及时）
如果线上机器是多用户环境（如共用跳板机部署），加 --global 参数可能不生效，改用 sudo -u www-data composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
验证是否生效：运行 composer config -g repo.packagist，输出应为 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
注意：不要用 composer config --unset 清掉旧配置再设，某些老版本 Composer 会因此丢失 packagist.org fallback 行为，反而更脆

`composer create-project` 和 `install` 对镜像源的使用逻辑一样吗？

不一样。前者初始化项目时会先读全局配置，但若项目自带 composer.json 且含 repositories 字段，就会优先用项目级源；后者只认全局配置 + 项目 composer.json 中显式声明的源，且无 fallback 机制。

热修复常用 composer install --no-dev --optimize-autoloader，它完全跳过 repositories 字段解析，只查全局配置和 Packagist 缓存
所以别依赖「项目里写了镜像就万事大吉」——线上打包机很可能没同步最新 composer.json，或者用了缓存的旧 lock 文件
真正保险的做法：上线前在 CI 流水线里跑一次 composer install 并提交 vendor/（不推荐）或至少确保 composer.lock 里的 dist.url 域名已替换为镜像地址（可用 sed -i 's/packagist.org/mirrors.aliyun.com\/composer/g' composer.lock）

镜像源不是万能解药：这些细节容易漏掉

镜像解决了下载速度问题，但掩盖不了 Composer 自身的并发与重试缺陷。比如小概率出现 zip 包校验失败、部分包 metadata 不同步（尤其是 dev 分支）、私有包仍需走原厂地址。

阿里云镜像目前不代理私有 GitLab/GitHub 私有库，如果你的 composer.json 引用了 vcs 类型仓库，得单独配 repositories 并确保线上能通对应域名
某些老旧项目用 composer self-update 升级到 2.x 后，发现 https://mirrors.aliyun.com/composer/ 返回 404 —— 这是因为 2.2+ 版本要求镜像支持新的 packages.json 格式，需确认镜像站是否已升级（阿里云已支持，但一些自建镜像可能未跟进）
最隐蔽的坑：Docker 构建时用了 FROM php:8.2-cli 这类官方镜像，里面根本没配任何镜像源，且 /root/.composer/config.json 在容器启动后才生成，必须在 Dockerfile 里显式 RUN 上述 composer config -g 命令