Webman 能撑住游戏后端实时压力，因其采用常驻内存+协程+非阻塞 I/O 模型，单进程可维持上万 TCP 连接且读写不阻塞；需启用 pcntl/posix、开启 opcache，避免同步操作阻塞事件循环，WebSocket 管理须用 connection_id 而非 session，数据库须用协程驱动并正确管理连接池与事务，延迟敏感逻辑应隔离至自定义进程。
Webman 为什么能撑住游戏后端的实时压力
它不是靠“加机器”硬扛，而是从运行模型上绕开了传统 PHP 的致命短板。游戏后端最怕两件事：连接数暴涨时进程爆炸、操作指令被大流量响应卡住。Webman 的常驻内存 + 协程 + 非阻塞 I/O 三者叠加，让单进程轻松维持上万 TCP 连接，且每个连接上的读写不互相阻塞。
常见错误现象：PHP Warning: file_get_contents(): failed to open stream: Connection timed out 在 FPM 下高频出现，但在 Webman 中只要用 Webman\Http\Client 或协程版 Redis、MySQLi 驱动，就不会因等待 DB 或 API 而拖垮整个连接池。
- 必须启用
pcntl和posix扩展（否则无法 fork 子进程管理 Worker） - 禁用
opcache.enable_cli=0—— Webman 是 CLI 进程，Opcache 必须开，否则热重载后性能断崖下跌 - 不要在
onMessage回调里直接sleep()或同步file_put_contents()，这会挂起整个事件循环
WebSocket 连接管理：别用 session，用 connection_id
游戏场景下，玩家登录后要长期保活、广播状态、踢人、断线重连。Webman 默认的 Session 基于文件或 Redis，但它是 HTTP 生命周期绑定的，对 WebSocket 完全无效。真正可用的是 $connection->id 和 ConnectionInterface 实例本身。
使用场景：实时对战匹配、房间广播、技能冷却倒计时推送。
- 连接建立时存映射：
$_SESSION_MAP[$connection->id] = ['uid' => 123, 'room_id' => 'r_456'] - 广播时不遍历所有连接，改用
Worker::$connections+ 条件过滤，避免全量扫描 - 断线回调里必须手动清理
$_SESSION_MAP和 Redis 中的在线状态，否则会出现“幽灵玩家” - 别依赖
onClose100% 触发——移动端切后台、NAT 超时都会静默断连，得配心跳检测 + 超时踢出
协程 MySQL 查询：驱动和写法都得换
默认的 PDO 或 mysqli 是同步阻塞的，放进协程里等于废掉协程。Webman 要发挥协程优势，必须用真正支持协程的客户端。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
参数差异：workerman/mysql 提供 Co\Mysql，而 hyperf/database 的协程适配器也能跑，但需额外配置 mysql:// DSN 并关闭 PDO 模式。
- 连接池配置必须设
max_connections，否则高并发下新建连接失败会抛Connection refused -
select类查询可直接yield $mysql->query(...)；但insert后想立刻用lastInsertId()，得确保是在同一个协程上下文里执行 - 事务不能跨协程——
begin和commit必须在同一个go函数内，否则会锁表或丢数据 - 查完立刻
unset($mysql)，协程结束时连接会自动归还池中；不 unset 可能导致连接泄漏
延迟敏感操作：用自定义进程隔离
游戏里有些逻辑天生不能等：帧同步校验、物理碰撞判定、防外挂时间戳校验。它们必须毫秒级完成，且不能被日志写入、Redis 请求、HTTP 回调拖慢。
性能影响：把这些逻辑扔进主 Worker 会污染事件循环，哪怕只多花 3ms，1000 个并发就累积 3 秒延迟抖动。
- 新建自定义进程类，继承
Webman\Process\Process，在handle()里用while(true)+usleep(1000)主动轮询共享内存或 Redis List - 用
pcntl_signal_dispatch()接收主进程信号，实现优雅重启 - 进程间通信别用文件——改用
shmop或sysvsem，避免磁盘 I/O 成瓶颈 - 该进程不处理任何网络请求，只做计算和原子写，输出结果写回 Redis 或通过
Worker::$connections推送
真正难的不是写代码，是判断哪段逻辑该进协程、哪段该进独立进程、哪段必须砍掉——比如“每秒统计在线人数”这种需求，与其实时算，不如让前端自己上报心跳+服务端定时采样修正。
