弹幕非HTML5原生功能，需用canvas或绝对定位div+requestAnimationFrame实现；须覆盖视频层、对齐ontimeupdate、处理WebSocket协议、限制缓存数并优化移动端性能。
弹幕不是 HTML5 原生功能，得靠 JavaScript 实现
HTML5 本身不提供 <danmaku> 标签或内置弹幕 API。所谓“HTML5 弹幕”，实际是用 canvas 或绝对定位的 div + 定时动画（requestAnimationFrame）模拟出的滚动文字效果。浏览器只负责渲染，逻辑全在 JS 里。
常见错误是直接往 video 标签里加子元素试图“嵌入”弹幕——这不会生效，video 是替换元素，内容不可直接插入。
- 必须用一个覆盖在视频上方的透明层（
position: absolute的div或全屏canvas）承载弹幕 - 弹幕数据通常来自 WebSocket 或轮询接口，格式多为
{text: "666", time: 12.5, color: "#ff4444"} - 时间戳
time指该条弹幕应在视频播放到第几秒时出现，需监听video.ontimeupdate对齐
用 canvas 实现高性能弹幕的关键点
相比 DOM 方案，canvas 渲染千条弹幕仍流畅，适合高并发场景（如直播）。但需手动处理字体、换行、碰撞检测和生命周期。
- 初始化时用
getContext("2d")获取绘图上下文，设置font和fillStyle - 每帧清空画布用
clearRect(0, 0, width, height)，别用canvas.width = canvas.width（会重置所有上下文状态） - 弹幕对象需自带
x、y、vx（水平速度）、life（存活帧数），在requestAnimationFrame中更新位置并剔除超界弹幕 - 中文换行需手动切分：用
ctx.measureText()测量单字宽，累计到容器宽后换行
WebSocket 接入弹幕时的典型坑
很多教程只写发送，忽略客户端对服务端协议的实际适配。真实环境里，弹幕消息往往不是裸文本，而是带协议头的二进制或 JSON 包。
立即学习“前端免费学习笔记（深入）”；
- 服务端可能用自定义二进制协议（如 Bilibili 的
protobuf封包），直接ws.onmessage收到的是ArrayBuffer，需用new DataView()解析，不能直接JSON.parse - 心跳必须由客户端主动发
ping（如每隔 30s 发{"cmd": "HEARTBEAT"}），否则连接会被服务端断开 - 连接建立后，通常要先发认证包（如
{"roomid": 123, "uid": 456}），服务端返回{"code": 0}才开始推送弹幕 - 注意
ws.onerror不会捕获连接失败，要用ws.onclose+ws.readyState !== 1判断是否异常断连
兼容性与性能底线提醒
移动端 iOS Safari 对 canvas 高频绘制敏感，安卓部分低端机 requestAnimationFrame 掉帧严重。别默认所有设备都能撑住 50+ 条/秒的弹幕流。
- 务必限制最大缓存弹幕数（如
maxDanmaku = 200），老弹幕未播完就丢弃，避免内存爆炸 - 禁用
transform: translateX()做 DOM 弹幕动画——iOS Safari 下大量元素会触发强制重排，卡顿明显；改用left+will-change: left - 字体 fallback 要写全：
font-family: "PingFang SC", "Microsoft YaHei", sans-serif，否则 iOS 上中文显示为方块 - 不要在
ontimeupdate里直接创建新弹幕 DOM 元素——高频触发会导致内存泄漏，应预创建池（danmakuPool = Array.from({length: 50}, () => document.createElement("div"))）
弹幕看似只是“飘过几行字”，但时间同步精度、渲染帧率、网络协议解析、内存回收这四点任一失控，都会导致体验崩坏。最容易被跳过的其实是服务端协议对接和移动端 canvas 性能压测。
