webman 不能直接构建低延迟直播系统，但可作为高并发低延迟弹幕网关：需用 websocket 长连接、异步处理广播/持久化/敏感词过滤；worker 数量须按实测 rss 计算安全上限；广播须按 room_id 分组并异步发送；敏感词过滤应常驻内存加载或结合 redis 粗筛；时间轴校准必须由前端自主完成。
Webman 本身不能直接构建低延迟直播系统，但作为弹幕网关，它完全能支撑高并发、低延迟的弹幕收发——前提是绕过传统 HTTP 轮询，用 WebSocket 长连接，并把广播、持久化、敏感词过滤等重负载拆出去异步执行。
WebSocket 连接数暴涨时 Worker 进程频繁 OOM
Webman 默认每个 Worker 进程独占内存，连接数上去后 RSS 内存会线性增长。设 $worker->count 不是越多越好，而是要按实测 RSS 反推安全上限。
- 用
ps aux --sort=-%mem | grep webman抓 3–5 个稳定运行的 Worker，算出平均RSS（单位 MB） - 硬上限公式：
(总内存 GB × 1024) ÷ 单 Worker RSS(MB) × 0.8，结果向下取整 - IO 密集型业务（如弹幕+Redis+MySQL）建议从
cpu_count() * 3起步，而非盲目设*5 - 必须同步调
net.core.somaxconn（≥65535）、net.core.netdev_max_backlog（≥30000），否则连接堆积直接丢包
弹幕广播卡顿、延迟飙升到 2s+
别在 WebSocket onMessage 回调里遍历所有连接调 sendText()——这是同步阻塞操作，1000 个连接就可能拖垮单个 Worker。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 广播前必须按
room_id分组，只推给当前房间的连接，避免全局遍历 - 用
session.getAsyncRemote().sendText()（Java）或 Webman 的$connection->send()异步发送，但注意：PHP 层没有真正的 async send，需靠webman/push插件 + Redis Pub/Sub 中转 - 真实高并发场景下，应把广播逻辑交给独立 Go/Python 服务消费
Redis Stream（如barrage:room_123），Webman 只负责写入 - 前端必须实现指数退避重连（1s → 2s → 4s → …），否则断连后雪崩式重连请求会压垮 Worker
敏感词过滤拖慢弹幕写入速度
同步调用远程敏感词服务（如 HTTP 接口）会让每条弹幕多出 50–200ms 延迟；本地加载词库又容易因 PHP-FPM 模式反复 reload。
- Webman 常驻内存，可将 Aho-Corasick 词库一次性加载进
static属性或Swoole\Table，避免每次 decode 后重复初始化 - 不要在
onMessage里做耗时 IO，过滤失败直接$connection->send(json_encode(['error'=>'内容含敏感词']))并 return - 若词库超 10 万条，建议用 C 扩展（如
php-ext-aho-corasick）或改用 Redis 的SCARD+SISMEMBER粗筛 + 后端精筛组合策略 - 过滤通过后，立刻
$this->redis->xadd("barrage:{$msg['room_id']}", '*', [...])，交由外部消费者处理广播与落库
弹幕时间轴漂移、前后端不同步
服务端按“接收时间”推送弹幕，前端却按 video.currentTime 渲染，网络抖动 + 服务端排队会导致弹幕错位 3–5 秒。
- 前端必须自主校准：收到弹幕后，记录
serverTs和本地Date.now()，算出网络 RTT 偏差，动态修正显示时机 - 服务端不传绝对时间戳，只传相对偏移量（如
"offset": 12345，单位 ms），前端结合video.currentTime计算真实出现时刻 - 禁止用
setTimeout控制弹幕入场，必须用requestAnimationFrame+transform: translateX()，否则低端机卡顿明显 - 每条弹幕 DOM 必须设固定
height（如24px），禁用min-height或内容撑开，防止字体加载引发重排
真正卡住性能的从来不是代码行数，而是连接管理粒度、广播路径是否绕过 PHP 主循环、以及时间轴校准是否甩给前端自主决策——这三处没对齐，再多优化也白搭。
