HTML 的 标签无法实现弹幕效果，因其专为时间轴对齐的静态字幕设计，缺乏动态定位、交互控制和实时渲染能力；实际必须用 CSS + JavaScript 基于 实现。
HTML
<track></track> 是专为视频内嵌字幕（subtitles）、章节（chapters）、描述（descriptions）等**时间轴对齐的静态文本轨道**设计的，它必须嵌套在 <video></video> 内，且依赖 WebVTT 文件或内联 <track></track>。弹幕是实时、多层、自由移动、无固定时间点、可交互（如点赞、暂停）的动态覆盖层——二者语义、渲染机制和控制粒度完全不同。
强行用 <track></track> 模拟弹幕会遇到这些硬伤：
-
<track></track>内容由浏览器原生渲染，无法用 CSS 定位、z-index 控制层级，也不能绑定点击事件 - WebVTT 时间戳精度有限，无法支撑毫秒级入场/出场动画
- 浏览器强制将
<track></track>文本渲染在视频画面上方固定区域，无法横向滚动或随机 Y 轴位置 - 无法动态插入新弹幕（
<track></track>一旦加载完成就只读）
CSS + JavaScript 是当前唯一可行的弹幕实现路径
真实项目中，所有主流弹幕系统（Bilibili、YouTube Live Chat overlay、自研直播后台）都绕过语义化标签，直接用 <div> + <code>position: absolute + transform: translateX() 驱动单条弹幕，再用 JavaScript 管理生命周期和队列。
关键实操点：
立即学习“前端免费学习笔记（深入）”；
- 每条弹幕必须是一个独立
<div class="danmaku">，不能复用 DOM 节点（否则动画错乱）<li>用 <code>requestAnimationFrame替代setInterval驱动位移，避免丢帧；起始位置设为transform: translateX(100vw)，终点为translateX(-100%) - Y 轴位置需随机生成（如
top: Math.random() * (containerHeight - danmakuHeight) + 'px'），并做防重叠检测（简单版可用 Set 记录已占行区间） - 必须监听
animationend或定时器清理已移出视口的节点，否则内存泄漏 - 若需暂停/加速/隐藏，直接操作元素的
animationPlayState或修改animationDuration，别删 DOM - 所有弹幕共用同一段动画规则，无法差异化控制速度、延迟、持续时间
- 无法在弹幕运动中途插入新节点并自动接续动画（CSS 动画不支持“从当前位置继续”）
- 弹幕容器用
will-change: transform或contain: layout paint提升合成层 - 避免在动画循环中调用
getBoundingClientRect()，改用预存的clientWidth和scrollLeft计算 - 超过 50 条/秒的弹幕流必须启用“合并模式”（把连续同方向小文本拼成一条 DOM 渲染）
- 用户开启系统“减少动画”偏好（
@media (prefers-reduced-motion: reduce)）时，应直接禁用弹幕动画，而非降速——否则反而更晕
为什么不用
<marquee></marquee> 在 2026 年所有现代浏览器中仍能运行，但它的行为完全不可控：无法获取当前偏移量、无法响应鼠标悬停暂停、无法与其他弹幕层叠加、不支持任意起点/终点、且 Safari 已彻底禁用 scrolldelay 属性。
纯 CSS @keyframes 滚动（如 transform: translateX(100%) → translateX(-100%)）看似简洁，但存在两个致命缺陷：
所以实际工程中，CSS 只负责基础样式（字体、颜色、透明度、过渡缓动），位移逻辑必须交由 JS 手动计算。
兼容性与性能容易被忽略的细节
移动端弹幕卡顿不是因为 JS 慢，而是因为频繁创建/销毁 DOM + 强制同步布局（如读取 offsetTop）。优化要点很具体：
真正难的从来不是让文字动起来，而是让几百条弹幕在低端安卓机上不掉帧、不卡顿、不抢主线程、还能随时响应用户点击关闭某一条。
