Composer本身不提供异步事件驱动架构，它只是依赖管理工具；所谓“用Composer构建异步架构”，本质是用它精准引入并协调 ReactPHP、Guzzle Promises、AMPHP 等真正实现异步能力的库，同时避开元包陷阱、版本错配和自动加载滥用。
直接说结论：Composer本身不提供异步事件驱动架构，它只是依赖管理工具；所谓“用Composer构建异步架构”，本质是用它精准引入并协调 ReactPHP、Guzzle Promises、AMPHP 等真正实现异步能力的库，同时避开元包陷阱、版本错配和自动加载滥用。
为什么composer require react/react会卡死你的HTTP服务器
react/react 是个元包，只装 react/event-loop 和极简依赖，不带 react/http、react/socket。你写完 new React\Http\Server(...) 却报 Class 'React\Http\Server' not found，不是 Composer 没装好，而是根本没装对组件。
- 要跑 HTTP 服务 → 必须
composer require react/http:^1.1 react/socket:^1.12（注意版本强对齐） - 想发异步请求 → 补
composer require react/http-client:^0.5，别指望元包自动拉 - 装错版本（比如
react/http:^2.0配react/socket:^1.12）→ 接口不兼容，listen()直接抛Fatal error - Windows 下没启用
ext-sockets→StreamSelectLoop静默降级，CPU 占用飙升但并发上不去
post-autoload-dump事件不是用来触发异步逻辑的
这个 Composer 脚本事件在 composer install/update 后自动生成 autoload 文件时触发，常被误用来启动长期运行的服务（比如 $loop->run()）。结果是：每次装包，脚本就卡住不动，CI/CD 流水线超时失败。
-
post-autoload-dump只适合做一次性动作：清理缓存、生成配置、检查类映射完整性 - 真要启动异步服务，必须放在独立 CLI 脚本里（如
server.php），手动调用$loop->run() - 重复执行该脚本？会抛
LogicException: Event loop is already running——$loop是单例，不能run()两次
Guzzle Promises 的 wait() 在 CLI 里可用，在 Web 请求中慎用
wait() 会同步阻塞当前协程或线程，直到 Promise 完成。它在命令行工具里很实用（比如部署脚本等结果），但在 AMHP 或 ReactPHP 的 HTTP 处理器里调用，等于把异步服务变回同步，吞吐量断崖下跌。
- Web 场景优先用
then()+catch()链式处理，让事件循环持续流转 - 需要“等全部完成”？用
Promise\all()，不是一个个wait() -
wait()内部会轮询或 sleep，高并发下极易拖垮UvLoop或ExtEventLoop - PHP 8.5.5 中
wait()的底层调度更激进，若未配合gc_collect_cycles()，内存泄漏风险上升
最易被忽略的一点：所有这些异步库的性能表现，高度依赖实际运行时选中的 EventLoop 实现。Factory::create() 静默降级不报错，但 var_dump(get_class($loop)) 才是你唯一能确认它是不是真用了 UvLoop 的方式——别信文档，要验实例。
