弹幕密度由每秒注入弹幕数与单条弹幕显示时长共同决定，需通过滑动时间窗口限流、requestIdleCallback调度、CSS动画时长对齐及降级策略协同控制。
弹幕密度由什么控制？不是靠 setInterval 间隔
弹幕密度本质是单位时间内新增弹幕条数，和渲染帧率、弹幕生命周期、队列调度策略强相关。很多人误以为调 setInterval 的毫秒数就能控密度，结果要么卡顿要么稀疏——因为没考虑弹幕实际存活时长和 DOM 节点复用成本。
- 真正起效的是「每秒注入弹幕数」+「单条弹幕显示时长」的组合：密度 ≈ 注入速率 × 显示时长
- 显示时长不能只靠
setTimeout删除节点，必须结合 CSSanimation或transition控制视觉停留，否则 JS 删除时机不准会导致密度漂移 - 浏览器对
requestAnimationFrame的实际调用频率不稳定（尤其后台标签页），直接按帧数发弹幕会失准
用 requestIdleCallback + 时间窗口限流最稳
在主线程空闲时批量注入、并严格按时间窗口计数，能避开渲染阻塞又保证密度可预期。比单纯节流更适应高负载场景。
- 维护一个滑动时间窗口（如最近 1000ms），每次准备插入新弹幕前，先剔除窗口外的记录，再判断当前窗口内已发数量是否超阈值
- 用
requestIdleCallback触发注入逻辑，避免抢占渲染或输入响应任务 - 示例关键逻辑：
const DENSITY_LIMIT = 8; // 每秒最多 8 条
const TIME_WINDOW = 1000;
const timestamps = [];
<p>function canEmit() {
const now = performance.now();
// 清理过期时间戳
while (timestamps.length && timestamps[0] < now - TIME_WINDOW) {
timestamps.shift();
}
return timestamps.length < DENSITY_LIMIT;
}</p><p>function emitDanmaku(text) {
if (!canEmit()) return;
timestamps.push(performance.now());
// 创建并挂载弹幕元素...
}
CSS 动画时长必须和 JS 密度逻辑对齐
如果 CSS 里设了 danmaku { animation: fly 15s linear; }，但 JS 层按 10s 窗口限流，实际密度会比预期高 50%——因为旧弹幕还没消失，新弹幕又进来了。
- 务必让
@keyframes的总时长（含animation-delay）等于 JS 中用于计算密度的时间窗口（如TIME_WINDOW） - 避免用
animation-iteration-count: infinite做循环弹幕，它会让单条弹幕反复出现，彻底破坏密度统计 - 删除 DOM 节点的时机应绑定到
animationend事件，而不是靠 JS 定时器硬删，否则可能删早（动画未播完）或删晚（节点堆积）
移动端 Safari 的 requestIdleCallback 兼容性要兜底
iOS 15.4 之前 Safari 不支持 requestIdleCallback，直接 fallback 到 setTimeout 会导致密度失控——因为 setTimeout 不感知空闲状态，容易在重绘中强行插入。
立即学习“前端免费学习笔记（深入）”；
- 检测并降级：用
typeof requestIdleCallback !== 'function'判断，fallback 时改用requestAnimationFrame+ 时间戳采样 - 降级后必须加额外节流：比如每 16ms（一帧）最多允许 1 条弹幕进入队列，否则快速滑动页面时会瞬间涌出大量弹幕
- 别依赖
visibilitychange事件暂停密度计算——Safari 在后台标签页可能不触发该事件，导致窗口内时间戳滞留，重启后爆发式刷屏
密度调节真正的复杂点不在“怎么加”，而在“怎么不加”：当用户切走标签页、弹幕区域被遮挡、或播放器暂停时，时间窗口里的计数是否冻结、如何安全恢复——这些边界状态稍有疏忽，密度就会指数级溢出。
