HTML弹幕与滚动评论必须物理隔离DOM：弹幕层用position:fixed全屏覆盖并pointer-events:none，评论区用固定高度+overflow-y:auto；二者数据同源但渲染独立，禁用innerHTML拼接、强制节点复用，并以seq_id替代时间戳确保顺序。
HTML弹幕和滚动评论不能共用同一套 DOM 渲染逻辑，强行混合会导致视觉错乱、内存泄漏、滚动卡顿——这不是样式微调能解决的问题，而是架构层面的隔离缺失。
弹幕层和评论区必须物理分离 DOM
把弹幕节点塞进评论列表容器里，等于主动触发重排+重绘风暴。哪怕只显示 20 条弹幕，也会让 overflow-y: auto 的评论区容器频繁计算布局。
- 弹幕层用
position: fixed; top: 0; left: 0; width: 100%; height: 100%; z-index: 9999;全屏覆盖，且设pointer-events: none;防止遮挡下方操作 - 评论区走传统流式布局，固定高度（如
max-height: 300px;），overflow-y: auto;，z-index: 1; - 两者数据源统一，但渲染路径完全独立：收到 WebSocket 消息后，分别调用
appendBarrage()和appendCommentList()
滚动评论区别碰 scrollLeft，优先用 transform: translateX()
直接改 scrollLeft 在 iOS Safari 和部分安卓 WebView 上会掉帧，尤其当评论区在 position: sticky 或嵌套在 flex 容器中时，浏览器无法合并滚动合成层。
- 容器加
overflow: hidden;和white-space: nowrap;，子元素用display: inline-block;或flex排列 - 滚动靠
element.style.transform = 'translateX(' + x + 'px)';，配合will-change: transform; - 用
requestAnimationFrame控制位移节奏，避免setInterval累积误差 - 禁用任何在 scroll 事件里读取
offsetTop、getBoundingClientRect()的逻辑——这是卡顿元凶
innerHTML += 渲染弹幕是内存泄漏高危操作
每次拼接字符串生成新 DOM，旧节点没被显式 remove()，又没被 JS 引用，就变成孤立节点，V8 垃圾回收不及时，低端机几秒就卡死。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 每条弹幕创建后记下唯一 ID（如
danmu-${Date.now()}-${Math.random().toString(36).substr(2, 6)}） - 动画结束时监听
animationend或在rAF循环中判断x ，然后 <code>node.remove() - 高密度场景（>30 条/秒）必须复用节点：维护一个弹幕池数组，
remove()后推入池尾，下次从池头取 - 绝对不要用
container.innerHTML += '<div>...</div>'，改用container.appendChild(danmuNode)
时间戳对齐偏差比你想象得更致命
WebSocket 消息到达、JS 执行、CSS 动画启动之间存在毫秒级延迟。若 5 条弹幕在 100ms 内连发，服务端用 Date.now() 打时间戳，前端直接按时间排序并启动动画，大概率出现“后发先至”或堆叠卡顿。
- 服务端必须注入单调递增的
seq_id字段，前端按此排序，而非依赖客户端时间 - 若需视频同步弹幕，
time字段应为相对视频起始的秒数（如12.34），由video.ontimeupdate触发匹配，而非一收到就播 - 动画起始偏移用
performance.now() - server_ts补偿网络传输延迟，否则快速连发时视觉节奏全乱
真正难的不是让文字动起来，而是让动起来的文字不干扰页面其他行为——DOM 隔离、节点生命周期、时间精度，这三处稍有松懈，滚动评论就会在用户滑动时突然卡住半秒，而这个半秒没人会归因到弹幕上。
