HTML5弹幕层级由CSS z-index或Canvas绘制顺序决定，权重仅是前端决策标签；服务端下发weight等字段，前端按预设通道（顶部/底部/滚动区）映射行为，实现防遮挡、保关键信息、高效率渲染。
HTML5中无法直接用“权重算法”控制弹幕层级——弹幕的视觉层级（谁在上、谁在下）由CSS z-index 或 Canvas 绘制顺序决定，而非服务端下发的抽象“权重”。所谓“基于权重的层级排列优化”，实际是前端根据业务规则（如用户等级、弹幕类型、互动热度等）动态分配显示优先级和空间资源，核心目标是：避免遮挡关键画面、提升高价值弹幕可见性、缓解视觉过载。
明确“权重”在弹幕系统中的真实落点
服务端不参与渲染排序，“权重”只是前端用于决策的数据标签，需在消息中携带并由客户端解析使用：
- 服务端可附加字段如
"weight": 85（0–100整数）、"priority": "top"、"type": "gift"或"level": "vip3" - 前端收到后，不直接按 weight 数值堆叠 DOM，而是映射为具体行为：高权重弹幕→固定顶部/底部区域、更大字号、更慢滚动速度、更高 z-index、更长停留时间
- 切忌在 Canvas 中对每条弹幕做实时 weight 排序重绘——这会严重拖慢帧率；应按区域预设通道（如 top-1、top-2、scroll-1～5），再按权重分配通道
分层通道 + 权重映射：轻量高效的实现逻辑
把弹幕显示区域划分为若干逻辑通道，每个通道有固定位置、动效规则和容量上限。权重仅决定“进哪个通道”，而非实时计算坐标：
-
顶部固定区（1～2行）：只收
weight ≥ 90的弹幕（如打赏公告、管理员提示），绝对定位 + translateY(0)，禁滚动，自动轮播（满则顶替最旧） -
底部固定区（1行）：收
weight ≥ 75的弹幕（如投票选项、活动入口），居底显示，背景半透明，文字加粗 -
主滚动区（5～8条并发）：剩余弹幕按
weight降序插入队列，高权弹幕获得更靠前的起始 X 坐标、更低的垂直偏移（减少重叠概率）、更缓的vx（如 0.8px/frame vs 普通 1.5px/frame） - 所有通道独立维护生命周期，超出缓存上限（如 top 区最多存 3 条）时按 FIFO 踢出，不因权重高低而阻塞低权弹幕入场
防遮挡与动态调度的关键细节
权重优化不是“让重要弹幕永远不被盖住”，而是降低冲突概率并保障关键信息必达：
立即学习“前端免费学习笔记（深入）”；
- 监听
video.ontimeupdate时，对即将触发的弹幕先做“碰撞预检”：遍历当前主滚动区活跃弹幕，若新弹幕的top区间与某条高权弹幕重合，则微调其top（±5% 随机偏移），而非强行抬高 z-index - 移动端需额外限制：当屏幕高度 < 500px 时，自动关闭顶部/底部固定区，全部归入滚动区，并将权重阈值整体上浮（如 top 区启用门槛从 90 提至 95），保流畅性
- WebSocket 消息中必须带
"timestamp"（视频内时间戳）和"weight"，但前端绝不等待高权弹幕“凑够权重才播”——时间到了就播，权重只影响它“怎么播”
服务端配合要点（非算法，重策略）
服务端无需实现复杂排序算法，只需支持前端所需的结构化分发逻辑：
- 广播前按房间/频道过滤，但不做跨用户权重聚合计算（如“本秒最高权弹幕”）——这会导致延迟和状态耦合
- 可配置权重映射表（JSON 格式）供前端拉取，例如：
{"gift": 95, "reply": 70, "normal": 40}，便于运营后台动态调整 - 对单条弹幕做基础校验：
weight必须为 0–100 整数，非法值统一置为 40；超长文本或含 XSS 字符的，丢弃而非降权
