弹幕系统核心卡点是连接稳定性、广播效率和前端渲染。需实现WebSocket指数退避重连、服务端异步广播分组推送、前端GPU加速渲染及基于video.currentTime的时间轴同步校准。
弹幕系统不是“连上 WebSocket 就能跑”，核心卡点在连接稳定性、广播效率和前端渲染三处。只要这三点没对齐，哪怕代码全对，上线后也会出现断连频繁、弹幕堆叠、时间轴漂移、高并发下服务端 OOM 等问题。
WebSocket 连接必须带退避重连，不能只写 new WebSocket(url)
浏览器原生 WebSocket 对断连零容忍：切后台、锁屏、短暂弱网都会触发 onclose，但默认不重试。只监听 onerror 也不行——很多真实断连根本不会触发它。
- 重连必须手动实现，且要指数退避：
1s → 2s → 4s → 8s，上限建议设为30s，避免雪崩式重连请求打垮服务端 - 连接 URL 中务必携带业务标识，例如
wss://api.example.com/ws?videoId=123&clientId=abc456，否则服务端无法做房间隔离和限流 - 连接建立后，立刻发一条心跳探测（如
{"type":"ping","ts":Date.now()}），收到{"type":"pong"}再开始接收弹幕，防止“连上了却收不到消息”的假成功
服务端广播不能用 session.getBasicRemote().sendText() 遍历
Spring Boot + @ServerEndpoint 默认是同步阻塞模型，getBasicRemote() 是单线程串行发送，100 个连接就可能把线程池拖垮；Node.js 的 ws 库同理，直接 ws.send() 在高并发下会堆积未 flush 的 buffer，最终触发 ERR_STREAM_WRITE_AFTER_END 或内存溢出。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- Java 必须改用
session.getAsyncRemote().sendText()，它交由容器线程池异步执行，不阻塞主线程 - 广播前先按
videoId分组，只推给当前房间的Session，别用全局ConcurrentHashMap<string session></string>存所有连接——容易内存泄漏，且无法按业务维度清理 - 如果用 Node.js +
socket.io，优先用io.to(room).emit()，绝对避免io.emit()全量广播
前端渲染弹幕必须用 transform: translateX() + requestAnimationFrame
用 left/top + setInterval 移动 DOM，每帧都触发 layout → paint → composite，5 条弹幕同时滚动就会卡顿；低端 Android 设备上，10 条基本卡死。
- 每条弹幕 DOM 必须设固定高度（如
height: 24px），禁止用min-height或内容撑开，否则滚动中字体加载、emoji 渲染会导致重排 - 位移必须走
transform: translateX()，配合 CSSwill-change: transform和 GPU 加速 - 动画节奏交给
requestAnimationFrame控制，不要依赖setTimeout，确保与屏幕刷新率同步
弹幕时间轴同步不能靠服务端匹配，得由前端根据 video.currentTime 自主决策
服务端做时间戳过滤（比如“只推第 123 秒的弹幕”）看似精准，实则不可行：网络延迟波动、客户端播放器缓冲、音画不同步都会导致错帧。B站、抖音等平台全部采用前端驱动模式。
- 服务端消息里必须带
timestamp字段（单位毫秒，相对于视频起始时间），例如{"text":"前方高能","timestamp":123450} - 前端监听
video.timeupdate，用currentTime * 1000 - timestamp计算偏差，偏差在 ±200ms 内才创建并显示该弹幕 - 需定期校准本地时间与服务端时间差（比如连接时返回
serverTime），补偿 RTT 延迟，否则长时间观看后会越偏越远
真正难的不是“怎么发弹幕”，而是当 5000 人同时进入直播间、每人每秒发 1 条、网络抖动频发、手机性能参差不齐时，还能让每条弹幕在正确的时间、以正确的速度、不重叠不卡顿地划过屏幕——这些细节藏在重连策略、异步广播、GPU 渲染和时间校准里，而不是在 onmessage 回调里打印一句 console。
