ReactPHP项目启动前卡在composer install是因默认源packagist.org国内TLS握手失败，需正确配置国内镜像：执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意拼写、type值、末尾斜杠），并删除vendor和composer.lock后重装。
ReactPHP 本身不依赖 Composer 镜像是否“异步”，但你的本地开发流速直接受 composer install 是否卡在元数据加载影响——而这个环节恰恰是 ReactPHP 项目启动前最常被忽略的阻塞点。
为什么 ReactPHP 项目一跑 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，所有环境行为一致：
立即学习“PHP免费学习笔记（深入）”；
- 进项目根目录执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g） - 该命令会自动向
composer.json写入"repositories"字段，key 固定为"packagist"，不会覆盖已有私有源 - 若项目已含其他
"repositories"（如内网 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 本地可运行的前提。
