webman 不适合直接构建 slack 类实时协作工具，因其缺乏原生 websocket 管理、会话路由、离线消息队列和消息去重机制，易导致连接不稳定、消息丢失及高并发延迟。
Webman 本身不适合直接构建 Slack 类实时协作工具，核心瓶颈在长连接与消息广播能力上。它没有原生 WebSocket 管理、会话路由、离线消息队列或消息去重机制，硬套用会导致连接不稳定、消息丢失、多人并发时延迟飙升——这不是配置问题，是架构定位差异。
为什么 Webman 的 WebSocket 支持不够用
Webman 内置的 webman/plugin-websocket 仅提供基础连接/断开/收发回调，不处理：
- 用户身份绑定：无法自动将
$connection关联到具体用户 ID，每次收消息都要手动查 session 或 token - 频道/群组广播：没有内置的房间（room）概念，
$connection->send()只能单点推，群聊需遍历所有在线连接并逐个判断权限 - 连接保活与异常清理：超时检测弱，客户端假死连接长期滞留，内存泄漏风险高
- 无消息确认与重传：TCP 层不保证应用层送达，Webman 不提供 ACK 机制，移动端切后台后极易丢消息
必须补上的三个中间件级能力
若坚持用 Webman 主框架，以下模块不可省略，且需自行实现或强依赖第三方：
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
-
redis作为会话中心：存储user_id → connection_id映射，解决多进程下连接不可见问题 -
swoole/table或redis hash实现轻量级房间表：记录channel_id → [connection_id, connection_id, ...] -
redis stream或rocketmq做消息中继：所有发送请求先入队，由独立消费者进程广播，避免主协程阻塞
更现实的替代路径：Webman + GatewayWorker 组合
直接放弃 Webman 独自扛 WebSocket，改用 GatewayWorker（基于 Swoole）做通信网关，Webman 仅负责 HTTP 接口（登录、用户管理、文件上传、消息历史查询等）：
- GatewayWorker 处理所有长连接、心跳、广播、断线重连、IP 限频
- Webman 通过
GatewayClient向 GatewayWorker 发送广播指令，例如：Gateway::sendToGroup($channel_id, $message) - 用户登录后，Webman 调用
bindUid($connection_id, $user_id)，后续所有sendToUid()自动路由 - 消息存储仍由 Webman 控制（写入 MySQL + redis 缓存最新 N 条），但投递完全交给 GatewayWorker
容易被忽略的复杂点
真正卡住进度的往往不是代码，而是这几个非功能需求：
- 消息已读未读状态同步：需要维护
user_id + channel_id + last_read_message_id三元组，且要应对多端（Web/iOS/Android）时间差和离线窗口 - 搜索历史消息：MySQL 全文索引性能差，
elasticsearch或meilisearch成必需项，不是“可选优化” - 文件上传直传对象存储（如
minio或aliyun oss）：Webman 接收上传再转发会吃光内存，必须前端直传 + 后端签发 token - 私有化部署时的 TLS 透传：Nginx 必须正确配置
Upgrade和Connection头，否则 WebSocket 握手 400
