真正可控、不卡顿的弹幕调速方式只有两种：Canvas绘制时动态缩放时间步长，或DOM弹幕用transform:translateX()配合requestAnimationFrame手动更新位移量；CSS@keyframes动画不支持运行时修改单条弹幕速度。
弹幕滚动速度不能靠改 animation-duration 或 left 的数值“硬调”，真正可控、不卡顿的方式只有两种：Canvas 绘制时动态缩放时间步长，或 DOM 弹幕用 transform: translateX() 配合 requestAnimationFrame 手动更新位移量。CSS @keyframes 动画本身不支持运行时修改单条弹幕速度。
DOM 弹幕怎么实时调速（不卡、不重排）
每个弹幕元素必须用 transform: translateX() 移动，禁用 left/top；所有弹幕共用一个 requestAnimationFrame 主循环，在回调里统一按当前倍速系数更新每条的 x 坐标。
- 不要为每条弹幕单独开
setInterval或setTimeout，帧率会漂移、内存泄漏风险高 - 速度调节本质是改全局
speedFactor变量（如 1.0 → 2.0），所有弹幕下一帧自动加速，无需重绘或重设动画 - 容器必须设
overflow: hidden，否则浏览器无法启用图层合成，GPU 加速失效 - 超出右边界后立即
remove()或复用节点，避免 DOM 节点持续累积
Canvas 弹幕如何实现倍速（无 DOM 开销）
Canvas 不依赖样式计算，速度控制完全由 JS 时间逻辑决定：在 requestAnimationFrame 回调中，用 performance.now() 计算真实帧间隔，乘以倍速系数后更新弹幕横坐标。
- 示例关键逻辑：
const delta = (now - lastTime) * speedFactor; danmu.x -= danmu.speed * delta; - 原始
danmu.speed是基础像素/毫秒值（比如 0.5），speedFactor是用户选的 1.5x、2.0x 等 - 不推荐用
setTimeout模拟帧循环——它无法对齐屏幕刷新，倍速下容易跳帧或粘滞 - 暂停时只需停止调用
requestAnimationFrame，恢复时传入上次lastTime即可无缝继续
为什么直接改 CSS animation-duration 行不通
@keyframes 定义的动画一旦触发，其时长就固化在渲染引擎内部；运行时修改元素的 animation-duration 属性，Chrome 和 Firefox 大概率不响应，Safari 则可能触发重排或丢帧。
- 尝试用
elem.style.animationDuration = '10s'改单条弹幕？多数情况无效，且会强制样式重计算 - 想让新进弹幕按当前倍速入场？必须在创建时就计算好
animation-duration值并写死到内联样式（如style="animation-duration: 12s;"），旧弹幕无法动态调整 - Safari 对
calc()在@keyframes中支持极差，动态算时长必须 JS 注入，不能依赖 CSS 变量
video 播放速度变化时，弹幕怎么同步（关键兼容点）
视频倍速变，弹幕也得跟着变，但不能监听 ratechange 事件——它在 iOS Safari 和部分安卓 WebView 上根本不触发。可靠做法是：把弹幕播放逻辑和视频 currentTime 绑定，而不是依赖帧循环。
- 监听
video.timeupdate，每次触发时根据当前video.playbackRate推算应显示哪些弹幕、位置偏移多少 - Canvas 方案下，直接用
video.currentTime * playbackRate查弹幕时间轴，比帧驱动更稳 - DOM 方案下，暂停弹幕 rAF 循环，改为每 100ms 检查一次
video.currentTime，再批量更新位置 - iOS Safari 设置
playbackRate必须由用户 click/touch 触发，所以倍速按钮点击后，要立刻同步调弹幕逻辑，不能等异步回调
最易被忽略的一点：速度调节不是改某个数字就行，而是整套渲染路径要不要走 layout ——只要还在 scroll 里读 offsetTop 或写 style.left，哪怕只调 0.5x，照样卡。真正的调速，是从第一行代码就绕开样式计算。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
