Ratchet 在 PHP 8.0+ 环境下已基本不可用，因其依赖的 reactphp/event-loop v0.4.x 等旧组件与现代 PHP 和 OpenSSL 不兼容，作者停止维护，安装后常报 TypeError 或 Class not found 错误，启动即卡死或 segfault；强行降级至 PHP 7.4 并锁死依赖可短期运行但存在 TLS 超时等隐患，推荐改用 Swoole 或 textalk/websocket 等现代替代方案。
直接说结论：Ratchet 在 PHP 8.0+ 环境下已基本不可用，Composer 安装后大概率无法启动服务，核心原因是其依赖的 reactphp/react 旧版本与现代 PHP 和 OpenSSL 不兼容，且作者已停止维护。
为什么 composer require cboden/ratchet 装完就报错？
Ratchet 依赖 reactphp/event-loop v0.4.x 和 evenement/evenement，这些包在 PHP 8.0+ 中触发致命错误，典型表现是：
Fatal error: Uncaught TypeError: React\EventLoop\StreamSelectLoop::addTimer(): Argument #2 ($callback) must be of type callable, null given-
Class 'React\Socket\Server' not found（因自动加载失败或版本错配） - 启动脚本时卡住、无响应、或直接 segfault
根本原因不是你写错了代码，而是 Ratchet 的依赖树早已冻结在 PHP 7.2 兼容层，而 Composer 默认拉取的最新版 cboden/ratchet（v0.4.4）仍指向这些废弃组件。
强行降级到 PHP 7.4 并锁死依赖能跑起来吗？
可以短期跑通，但不推荐用于生产 —— 不是“能不能”，而是“值不值得”。你需要：
立即学习“PHP免费学习笔记（深入）”；
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 用
php -v确认当前 CLI 使用的是 PHP 7.4（不是 Apache 或 FPM 的版本） - 在
composer.json中显式锁定关键依赖："require": { "cboden/ratchet": "0.4.3", "reactphp/event-loop": "0.4.3", "reactphp/socket": "0.8.14", "reactphp/http": "0.8.12" } - 运行
composer update --with-all-dependencies避免 Composer 自动升级子依赖
即使这样，reactphp/socket v0.8.x 在 TLS/SSL 场景下仍有 handshake timeout 风险，尤其在 Nginx 反向代理后 —— 它不会报错，但客户端连不上，排查极其耗时。
替代方案：用 textalk/websocket 或原生 Swoole 更靠谱
如果你只是需要从 PHP 主动发消息给前端（比如订单状态推送），而不是做聊天室级双向长连接，优先考虑轻量方案：
-
textalk/websocket：纯客户端库，通过 Composer 安装后可直接 connect 到任意 WebSocket 服务（如wss://echo.websocket.org），适合 PHP 后端向外部 WS 服务发指令，无服务端负担 -
swoole/websocket-server：PHP 原生扩展，性能高、文档全、PHP 8.1+ 原生支持；安装只需pecl install swoole，启动代码不到 10 行，且自带心跳、连接管理、广播方法 - 若必须走 Composer 生态且要服务端，改用
amphp/websocket-server（基于 Amp，异步模型更现代），但需重写事件循环逻辑，学习成本高于 Swoole
别为了“用了 Ratchet”而硬扛——它最后更新是 2020 年，GitHub Issues 里堆积着上百个未关闭的 PHP 8 兼容问题。
真正卡住项目的，往往不是“怎么写 WebSocket”，而是选错底层。Ratchet 的坑不在代码里，在 composer.lock 生成那一刻就已经埋好了。
