DOM+CSS动画渲染高密度弹幕会卡死，因每帧触发合成层判定与布局计算，超30条即掉帧；内存持续增长致崩溃，且left属性强制重排、无硬件加速时CPU压力陡增。
直接用 requestAnimationFrame + Canvas 渲染 100 条/秒的弹幕，不加节流会卡死；用 DOM + CSS 动画撑不过 30 条/秒。高并发弹幕不是“能动就行”，而是必须做时间轴对齐、密度控制、离屏回收和连接状态兜底。
为什么不能直接用 DOM + CSS 动画渲染高密度弹幕
浏览器对大量 position: absolute 元素做 transform: translateX() 动画时，每帧都要触发合成层判定、布局计算（哪怕只是重绘），一旦弹幕实例超过 30 个，scroll 类动画就会掉帧。更关键的是：DOM 节点不销毁，内存持续上涨，5 分钟后 Chrome 标签页可能崩溃。
- 每个弹幕 DOM 元素平均占用约 1.2KB 内存（含样式、事件、布局信息）
- 未设
will-change: transform或未启用硬件加速时，CPU 渲染压力陡增 - 滚动动画依赖
left属性时，强制触发 layout，性能雪崩 - 示例中常见错误写法：
el.style.left = `${x}px`—— 这是重排元凶
CanvasBarrage 类必须重写的三个关键逻辑
基于 Canvas 的弹幕类不是“把文字 drawText 就完事”，它得主动管理生命周期、时间锚点和帧节奏。核心要覆盖以下三处：
-
初始化时机：不要在构造函数里批量创建所有
Barrage实例，而应在renderBarrage()中按video.currentTime动态激活（即只初始化即将入场的那几条） -
离屏判定：不能只靠
x ，要加上y偏移容错（比如顶部弹幕 y=-50 也算离屏），否则会残留白块 -
帧同步开关：暂停/拖拽时必须停掉
requestAnimationFrame，但不能清空barrages数组 —— 否则拖回 10 秒前，本该出现的弹幕就永远丢了
典型漏写逻辑：if (this.isPaused) return; 放在 render() 开头，但没在 video.ontimeupdate 里重置播放状态标志位，导致拖动后无法恢复渲染。
WebSocket 断连时弹幕消息怎么不丢
服务端广播弹幕是“发了就不管”，前端必须自己兜底。单纯监听 onclose 然后 reconnect 不够——断连期间的弹幕已经飞走了。
- 服务端需在每条弹幕消息中附带
timestamp（毫秒级，相对于视频起播时间），而非Date.now() - 前端建立内存队列
this.pendingDanmakus = []，在onmessage里先 push，再按video.currentTime拉取匹配项 - 重连成功后，立即向服务端发请求：
socket.send(JSON.stringify({ type: 'sync', fromTime: lastKnownTime }))，服务端查 Redis 缓存或回溯消息队列补发 - 避免用
localStorage存未发弹幕 —— 同一用户多标签页时会互相覆盖
弹幕时间轴同步失效的两个隐蔽原因
明明写了 if (time >= barrage.time)，但“第 127 秒出现的弹幕”总在 129 秒才闪一下？大概率栽在这两处：
-
video.currentTime是只读属性，但它是异步更新的 —— 拖动后可能延迟 100~300ms 才真正生效，而render()帧率是 60fps，中间有 3~5 帧误差 - Canvas 渲染本身有帧延迟，
context.fillText()不是原子操作，长文本+高字号下绘制耗时可能超 8ms，导致视觉偏移 - 解决方案：对
barrage.time做 ±200ms 容差窗口，且在video.ontimeupdate触发时主动调用一次renderBarrage()强制对齐
最易被忽略的点：不同浏览器对 video.duration 的解析精度不一致，Safari 可能截断到小数点后 1 位，Chrome 是 3 位 —— 如果你用 duration 做归一化时间戳，跨端就会错位。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
