HTML弹幕性能瓶颈在于DOM节点过多及频繁重排重绘；应改用transform+requestAnimationFrame+节点复用，并避免scroll中读写布局属性。
HTML弹幕对滚动评论性能影响显著，尤其在低端设备或高密度弹幕场景下，容易导致主线程卡顿、渲染掉帧甚至页面假死——这不是 CSS 动画优化能完全解决的问题，核心在于 DOM 节点数量与重排重绘频率。
为什么 position: absolute 弹幕会拖慢滚动？
每个弹幕元素默认是独立 DOM 节点，哪怕只显示 50 条，也意味着 50 次 layout + paint 触发；滚动时若监听 scroll 事件并动态调整弹幕位置（比如做视口裁剪），会强制同步触发 style 计算和布局，浏览器来不及合并渲染帧。
- 避免用
top/left驱动位移：改用transform: translateX()，启用 GPU 加速且不触发重排 - 禁用
will-change: top这类无效提示，它反而增加内存开销；正确写法是will-change: transform - 弹幕容器必须设
overflow: hidden，否则浏览器无法安全启用图层合成
requestAnimationFrame 控制弹幕动画节奏的关键点
直接用 setInterval 或 setTimeout 更新弹幕位置，极易跑偏帧率（比如 60fps 下本该每 16.6ms 更新一次，但 JS 执行延迟会导致累积误差）。requestAnimationFrame 能让更新时机与屏幕刷新严格对齐。
- 不要在 rAF 回调里操作 DOM 属性（如
elem.style.left），统一用elem.style.transform = 'translateX(' + x + 'px)' - 所有弹幕共用一个 rAF 循环，而非每个弹幕单独调用——减少回调注册开销
- 超出容器右边界后立即
remove()节点，或复用到队列尾部（避免频繁 append/remov）
用 CSS @keyframes 替代 JS 动画是否更优？
纯 CSS 弹幕动画在 Chrome/Firefox 上确实更省 CPU，但存在两个硬伤：无法动态控制单条弹幕速度、无法精准响应滚动暂停/加速。更适合固定节奏的背景型弹幕（如视频网站顶部飘过的“哈哈哈”）。
立即学习“前端免费学习笔记（深入）”；
- 必须为每条弹幕生成唯一 class 名（如
danmu-12345），避免多条共用同一 animation 导致错位 - 动画时长需根据弹幕长度和容器宽度动态计算：
animation-duration: calc((100vw + 300px) / var(--speed))，其中--speed是 px/s 单位 - Safari 对
calc()在@keyframes中支持有限，建议降级为 JS 计算后注入内联animation-duration
真正影响滚动流畅度的从来不是“有没有弹幕”，而是“怎么回收节点”和“谁在触发 layout”。哪怕只有 10 条弹幕，若每次都在 scroll 事件里读取 offsetTop 或写 style.top，照样卡顿。别迷信“CSS 就一定快”，关键看触发路径是否绕开了样式计算与布局。
