别让 PHP 只做“请求响应”：WebSocket 服务端实战指南

传统 PHP 跑后端，习惯了“来一单回一单”的 HTTP 流程。一旦想搞实时聊天、消息推送或在线看板，老路子就卡壳了。HTTP 长连接得靠轮询，延迟高还费资源。换个思路，直接上 WebSocket，把 PHP 变成持续在线的“服务员”，客户来了不赶人，走时也不留后门。

很多人一听 WebSocket 就想到其他语言生态，其实 PHP 一样能玩得转。关键不在于语言本身，而在于换掉传统的入口执行模型。不用每次请求都重新加载框架和数据库连接，而是让进程常驻内存，靠事件驱动来回消息。

搭一个能用的 WebSocket 服务，核心就三步。选对底座，别拿原生 socket 硬抗复杂协议。推荐 Workerman 或 Swoole，它们把握手、断线重连、心跳检测都封装好了，你只管写业务逻辑。初始化监听端口，绑定 IP 和端口后，框架会自动处理 TCP 链路。注册回调函数，重点盯住 onMessage 和 onClose。收到数据先做格式校验，存进全局连接池；客户端断开时及时清理句柄，防止内存悄悄涨上去。

跑起来容易，稳住难。PHP 的垃圾回收机制默认是延迟触发的，连接数一多容易爆内存。得在配置里调小 gc_max_requests，或者在空闲期手动触发清理。另外，别在 onMessage 里塞耗时操作。查数据库要加缓存，异步任务走队列，任何阻塞主循环的代码都会让整个 WebSocket 服务“假死”。生产环境务必配好看门狗守护进程，配合 Supervisor 或 systemd 管理，崩溃了自动拉起，日志统一输出到文件，方便排查问题。

实际业务里，单播和广播是最常碰到的场景。用户登录后，把连接 ID 和他的 uid 做个映射表。推消息时查表路由，群发用框架内置的批量发送接口，底层已经做了合并写入优化，比手写循环安全得多。遇到弱网丢包？前端设个定时器，服务端每三十秒发一次 ping 帧。客户端超时不回复，直接关连接释放资源。这套心跳兜底方案，能挡掉七八成“幽灵在线”的尴尬。

WebSocket 不是魔法，它只是把 PHP 从一次性脚本变成了长期运行的服务。摸透了常驻内存的特性，避开阻塞调用，配上合理的监控策略，你的 PHP 一样能撑起稳定的实时通信。别被概念绕晕，先从一个小功能跑通全链路，再慢慢叠加权限鉴权、分片传输那些进阶玩法。路是一步步踩出来的，代码也是。