如何让基于ReactPHP的异步应用快速搭建？使用非阻塞Composer镜像！

如果你手上正好有一个ReactPHP项目准备启动，却卡在composer install这一步怎么都跑不动，别急着怀疑写法。其实这问题十有八九跟异步框架本身没什么关系，而是你最开头的那一步——依赖安装——被网络给绊住了。

ReactPHP本身并不关心你用的是不是“异步镜像”，但本地开发能不能顺畅跑起来，全看composer install在第一步元数据加载时是否被卡住。而这地方，恰恰是新手最容易忽略的环节。

为什么一跑composer install就卡住？

不是ReactPHP慢，也不是你代码写错了。问题出在默认源packagist.org在国内的TLS握手容易失败，或者干脆HTTP/2返回404。也就是说，composer install在Loading repositories阶段就趴下了，根本进不到autoload生成那一步，更别说启动React\Http\HttpServer了。

• 现象：执行composer install之后，光标一动不动超过10秒，既不报错也没进度
• 本质：Composer尝试拉取https://packagist.org/packages.json的元数据，但连接被重置或直接超时
• 后果：你改完HttpServer代码，但require vendor/autoload.php永远跑不通，误以为是ReactPHP本身配置有误

composer config -g repo.packagist必须写对三个关键点

全局镜像配置这条命令，最容易出现的问题是静默失效。换句话说，你以为换源成功了，其实根本没用。90%“换源无效”的案例，都是拼写或协议写错了。判断是否生效的唯一标准，就是输出完整JSON配置。

• 正确命令：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
• 三个硬约束：repo.packagist（别多写一个s）、composer（type值不能省）、URL必须是HTTPS且末尾带斜杠/
• 怎么验证：composer config -g repo.packagist 输出应该是类似 {"type":"composer","url":"https://mirrors.aliyun.com/composer/"} 的对象。如果输出是空的、null，或者直接报错——说明镜像根本没生效

项目级配置其实比全局更稳，尤其适合ReactPHP

ReactPHP的服务经常要搭配CI/CD构建、Docker多环境部署。全局镜像在容器里可能根本不存在，或者权限不足。相比之下，项目级的配置写进composer.json，所有环境的行为就会完全一致，不会出现本地能用、部署就挂的尴尬。

做法也很简单：在项目根目录执行composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g即可）。这条命令会自动在composer.json中写入repositories字段，key固定叫packagist，不会覆盖项目已有的私有源。如果项目里已经配置了其他仓库（比如内网的Nexus），这也只是一个安全的追加操作，不会全量替换。

换源之后，vendor/和composer.lock要不要删？

要删，但仅限于首次换源时。原因很直接：旧的composer.lock里记录的是官方源的包hash值，换了镜像之后，新镜像返回同一份包，但签名校验可能因为同步延迟或CDN缓存不一致而失败。

• 具体操作：rm -rf vendor composer.lock，然后再跑composer install
• 别只删vendor而留下lock文件——那样install会试图按旧lock还原，但下载地址已经变成镜像源，还是可能校验失败
• 日常开发中不需要重复删除，后续的composer install会基于新的lock文件精确还原，速度稳定在秒级

说到底，真正卡住ReactPHP启动的，往往不是事件循环或者socket绑定这些高级概念，而是你连autoload.php都没能成功载入。而这一步的瓶颈就在于Composer的第一行网络请求。镜像不是可选的“优化项”，它是ReactPHP能在本地顺畅运行的前提条件。