微信小程序-WebSocket（Workerman-PHP）即时通讯 点对点、多人聊天室

这套资料解决什么问题

微信小程序的即时通讯不是调用一个 SDK 就能收工的事。小程序的网络层只给了wx.request这类短连接接口，要做真正的双向推送，必须自己搭一条 WebSocket 长连接通道，并且在后端维护连接状态、消息路由和心跳保活。这套资料的主题就落在这个夹缝里：前端用小程序原生 WebSocket API，后端用 Workerman 起 PHP 常驻进程，实现点对点私聊与多人聊天室两种会话模型。它适合已经写过 PHP、能看懂小程序页面结构，但没亲手搭过长连接服务的开发者。

技术栈与结构

后端选 Workerman 而不是 Swoole，原因是部署门槛低：纯 PHP 扩展依赖少，普通 LNMP 机器上就能跑起来，进程模型是 master-worker 加事件循环，理解成本比协程低。资料里能看到的工程结构大致分三层：Workerman 的 Worker 入口负责监听端口与连接生命周期，业务层处理登录鉴权、消息解析与转发，数据层处理用户与消息的落库。前端部分则是小程序的连接管理模块，通常需要把 WebSocket 实例、重连计时器、心跳定时器封装成一个可复用的对象，避免页面 onShow/onHide 时反复建连。

这种分层不是形式主义。长连接服务最容易出问题的地方就是连接与业务耦合在一起，一旦需要区分私聊和群聊，代码就会变成一堆 if。把「谁在线」和「消息发给谁」拆开，后面加已读回执、离线消息才有地方塞。

值得对照实践的模块

• 连接绑定用户：连接建立后并不等于身份确认，需要一条登录消息把 connection id 与 uid 做映射，退出或断线时清理。这是所有后续路由的前提。
• 消息协议设计：私聊和群聊如果共用一套 JSON 结构，靠 type 字段区分，前端解析逻辑可以只写一份。资料里的协议字段是很好的复用起点。
• 心跳与断线重连：小程序切后台、网络抖动都会断连，心跳间隔和服务端超时阈值要配合设置，重连需要退避策略，不能裸写 setInterval。
• 群聊广播：聊天室的成员列表维护在服务端内存里，广播时遍历在线连接，注意过滤发送者本人以及判断连接是否仍有效。
• 进程守护：Workerman 用命令行启动，实际部署要配合 systemd 或 supervisor，否则终端一关服务就没了。

怎么用这份资料

建议不要顺着视频一路看完。先按章节把 Workerman 的启动脚本跑通，用浏览器控制台或 wscat 连上去发一条消息，确认服务端能收到并回推；再进入小程序端，把单聊跑通；最后做聊天室。每完成一个阶段，把该阶段的连接状态、消息格式、异常分支记成一份简短笔记——长连接调试靠的就是这些可复现的中间状态，而不是最终跑通的截图。

资料包体量不大，配套的章节笔记更适合当复盘提纲。真正需要你自己补的是部署环节和小程序审核相关的合规细节，这两块视频通常讲得浅，但对能否上线影响很大。把整套 Demo 在自己服务器上重跑一遍，再改一处协议字段验证是否理解到位，比反复观看有效得多。