Workerman弹幕系统关键在于准确广播而非渲染，需按房间ID隔离连接、进程间共享状态、及时清理断连，并依赖前端标准化字段与Canvas优化。
Workerman 实现弹幕实时发射，关键不在“怎么画”，而在“怎么确保每条弹幕不丢、不乱序、不发错人”。它只管把 JSON 消息准确推给指定连接，Canvas 渲染、移动动画、碰撞检测全是前端的事。
onMessage 里别直接 send()，要按房间广播
弹幕是典型多房间场景（比如不同直播间），不能让 A 直播间的“666”出现在 B 房间。常见错误是收到消息就 $connection->send($data)，结果全站广播。
- 每个连接首次握手时，必须从 URL 参数或首条消息中提取
room_id，并挂到连接对象上：$connection->room_id = $roomId; - 用 PHP 数组维护映射：
$rooms[$roomId] = [$conn1, $conn2, ...];，注意这个数组只在当前 worker 进程内有效 -
onMessage中解析出type: "danmaku"后，遍历$rooms[$connection->room_id]，对每个$conn调用$conn->send($data)，但要跳过自己：if ($conn !== $connection) { ... }
前端发弹幕前必须标准化文本和时间戳
后端不做任何内容过滤或格式转换，但必须依赖前端传来的结构化字段，否则会出现“同一条弹幕在不同设备上速度/位置不一致”。
- 必传字段：
text（UTF-8 字符串）、color（如"#ff4757"）、size（如24）、mode（1滚动、4底部、5顶部）、timestamp（毫秒级，服务端原样透传，不重写） - 避免传原始输入框值——要 trim()、截断超长文本（如 > 30 字）、过滤控制字符（
\x00-\x08\x0B\x0C\x0E-\x1F） - 别在服务端做敏感词过滤：延迟高、规则难同步、且会破坏弹幕到达顺序；应由前端+独立审核服务异步处理
Worker 进程间无共享内存，多进程房间状态必须外置
如果你启用了 $worker->count = 4，默认的 PHP 数组 $rooms 在 4 个进程里各自一份，A 进程里的用户根本看不到 B 进程里房间的在线人数，广播必然漏人。
- 简单方案：改用
Swoole\Table（需已安装 Swoole 扩展），它是进程间共享的内存表，支持原子操作 - 通用方案：接入 Redis，用
pub/sub或zset管理房间成员，onMessage收到弹幕后，先PUBLISH danmaku:room_123 $data，再由各 worker 订阅该 channel 广播 - 切勿用文件存房间列表——并发写入会覆盖、无锁、性能崩盘
连接断开不清理，ghost 弹幕就会出现
用户关页面、切后台、网络抖动都会触发 onClose，但 Workerman 默认不会帮你从 $rooms 或 Redis 列表里删掉这个连接。下次有人发弹幕，系统仍会尝试向那个已失效的 $connection 发送数据，轻则 warning，重则 segfault。
- 必须在
onClose回调里显式清理：unset($rooms[$connection->room_id][$key])或 Redis 执行ZREM room:123 $fd - 不要靠
$connection->getRemoteIp()去重——NAT 下多个用户 IP 相同；也不要等心跳超时——用户已走，你还留着连接占内存 - 给每个连接挂
$connection->room_id和$connection->uid是最轻量、最可控的方式
真正难的不是推送，而是当同时有 2000 条弹幕涌进来时，前端 Canvas 能否每帧稳定绘制、不卡顿、不重叠。Workerman 只负责把包送到，剩下的得靠 requestAnimationFrame + 弹幕池 + 碰撞检测算法来兜底——这部分一旦没压住，再快的服务端也没用。
