滚动评论与HTML弹幕非互斥关系：前者属UI表现层，后者为渲染方式；关键在数据流驱动机制及是否允许用户提交含HTML评论。
滚动评论和HTML弹幕本质不是二选一的关系——滚动评论通常是UI表现层，而HTML弹幕是内容渲染方式；真正要决定的，是「用什么机制驱动弹幕数据流」和「是否允许用户提交含HTML的评论」。
滚动评论用scrollLeft还是transform: translateX？
直接改scrollLeft兼容性好但卡顿明显，尤其在移动端；transform: translateX触发GPU加速，动画更顺，但需配合will-change: transform防闪烁，且必须确保容器overflow: hidden且子元素不换行。
- 若弹幕密度低（scrollLeft +
requestAnimationFrame控制帧率更稳妥 - 高密度场景（如直播）必须用
transform，并把每条弹幕DOM节点复用（不要每次innerHTML +=） - 别忘了加
white-space: nowrap到弹幕容器，否则中文会意外折行打断滚动
innerHTML渲染弹幕时怎么防XSS？
用户提交的评论若含<script>或onerror=等，直接innerHTML就执行了。不能靠前端正则过滤——绕过方式太多。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 服务端必须做HTML实体转义：
<→，<code>"→"，且只对用户输入字段做 - 前端可加第二道保险：用
DOMPurify.sanitize()处理后端返回的富文本字段（仅限需保留<b>、<img>等白名单标签时） - 绝对不要给弹幕容器设
contenteditable="true"，这是XSS温床
弹幕数据从WebSocket推还是轮询拉？
实时性要求高的场景（如直播互动），轮询延迟大、连接数爆炸；但WebSocket断连重连逻辑复杂，容易漏消息。
立即学习“前端免费学习笔记（深入）”；
- 用WebSocket时，服务端必须带
seq_id序号，客户端按序号去重+补漏（比如断连后发{cmd: "sync", last_seq: 12345}） - 纯滚动评论（如博客底部留言滚动展示）用
fetch轮询更轻量，3~5秒一次，配合If-None-Match响应头减少带宽 - 别在WebSocket里传完整HTML字符串——应传结构化数据（如
{text: "666", color: "#ff4757", size: "large"}），前端拼DOM，便于统一管控样式和安全策略
最常被忽略的是弹幕时间戳精度：服务端生成的timestamp若用Date.now()，不同机器时钟偏差会导致弹幕乱序；生产环境必须用NTP同步后的服务端时间，或用单调递增的sequence number代替时间排序。
