因为packagist官方源位于欧洲，dns解析慢、tls握手不稳定、cdn节点少且受防火墙干扰，导致composer install卡在packages.json元数据请求或zipball下载阶段；解决方式是全局配置国内镜像源，如执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/。
为什么 composer install 总卡在 packagist.org？
因为默认源是国外的 packagist.org，DNS 解析、TCP 连接、TLS 握手、包下载全受网络质量影响。不是 Composer 慢，是它根本连不上源——尤其在 CI/CD 环境或新部署机器上，连超时重试都来不及触发就失败了。
关键点：镜像不是“加速”，而是“替代”。国内镜像（如阿里云、腾讯云、华为云）提供完整元数据镜像 + 包文件镜像，协议兼容 Packagist，无需改代码、不破坏锁文件语义。
-
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/是最轻量方案，全局生效且不影响项目原有composer.json - 别用
composer config repo.packagist ...（无-g），那会写进当前项目composer.json的repositories字段，导致提交后污染协作环境 - 某些镜像（如华为云）要求 HTTPS 强制校验，若系统 CA 证书过旧，会报
cURL error 60，此时需更新ca-certificates或临时加--disable-tls（仅调试）
CI/CD 中如何避免镜像配置被覆盖？
很多 CI 脚本直接执行 composer install，但没指定源，结果跑在干净 Docker 镜像里还是走默认源。这不是漏配，是环境隔离太彻底。
推荐做法：在 CI 命令前显式注入镜像配置，不依赖全局或项目配置。
- GitLab CI：在
before_script加composer config -g repo.packagist composer https://mirrors.cloud.tencent.com/composer/ - Github Actions：用
run: composer config -g repo.packagist composer https://packagist.phpcomposer.com（注意该镜像已停用，应换为阿里云或华为云） - Docker 构建时：在
Dockerfile的RUN步骤中执行镜像配置，比挂载~/.composer/config.json更可靠
composer.lock 里还藏着 packagist.org 吗？
不藏。composer.lock 只记录包名、版本、checksum 和 dist URL（如 https://api.github.com/repos/.../tarball/...），不硬编码源域名。只要镜像服务能正确响应 packages.json 请求并返回一致的元数据，Composer 就能从镜像站下载 tarball，完全透明。
唯一例外：你手动在 composer.json 里写了私有仓库或 VCS 类型仓库，并指定了 url，那 lock 文件会保留那个 URL。但这是你主动定义的，和镜像无关。
- 验证方式：运行
composer install -vvv，看日志里Downloading https://mirrors.aliyun.com/...是否出现 - 如果仍看到
packagist.org，说明镜像没生效——大概率是用了composer config但忘了-g，或者 CI 环境用了不同用户身份执行命令
多个镜像之间怎么选？
阿里云、腾讯云、华为云镜像都稳定，但行为细节有差异：
- 阿里云镜像同步延迟约 5–10 分钟，适合绝大多数场景；其
https://mirrors.aliyun.com/composer/不需要额外 token 或 referer - 腾讯云镜像对部分大体积包（如 Laravel 的
laravel/framework）分片更优，但要求 User-Agent 包含Composer字符串（新版 Composer 默认满足） - 华为云镜像支持 IPv6，且在国内多运营商网络下 DNS 解析更稳，但首次访问会返回 302 重定向到 CDN 域名，若 curl 版本太旧可能失败
没所谓“最好”，选一个，配好，别来回切。频繁切换镜像反而容易触发 Composer 缓存混乱，导致 Could not find package 错误。
