音频时间轴驱动DOM高亮需监听timeupdate事件，用currentTime比对时间戳并控制类名与滚动；但直接比对会因事件节流、读值延迟、高频重排导致卡顿跳行，须优化触发时机、滚动策略及样式更新方式。
音频时间轴驱动 DOM 高亮，不是靠 CSS 自动响应，也不是靠 setInterval 硬轮询。 核心是监听 timeupdate 事件，用 audio.currentTime 主动比对字幕/章节时间戳，并控制类名与滚动位置——但直接照搬会卡顿、跳行、不同步，原因全在细节里。
为什么 ontimeupdate 直接比对总“慢半拍”？
浏览器对 timeupdate 的触发有节流（通常 200–500ms 一次），且主线程卡顿时会丢帧；currentTime 读值本身也有微小延迟。若写成 if (currentTime >= start && currentTime ，很容易漏掉区间、重复高亮或跨行失败。
- 改用带宽容窗口的判断：
currentTime + 50 >= start && currentTime - 50 （单位：毫秒） - 缓存上一次匹配的索引，避免每次遍历整个字幕数组
- 别在回调里用
document.querySelectorAll或getElementsByClassName查 DOM，提前存好li元素引用 - 移动端 Safari 触发更稀疏，建议在
requestAnimationFrame中二次校准（仅当检测到时间差 >100ms 时才更新）
怎么让高亮不闪、滚动不卡？
高频 class 切换 + scrollTop 反复赋值 = 强制重排 + 布局抖动，尤其在歌词行数多时明显。CSS 动画也救不了，因为触发时机不可控。
Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转
下载
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
- 高亮用
outline或box-shadow，避开background-color（尤其渐变）引发的重绘 - 滚动只在「当前行索引变化」时触发，记录上一行 index，对比不同再调
scrollIntoView({ block: 'center' }) - 优先启用
scroll-behavior: smooth，但注意 IE 不支持；iOS Safari 下需配合transform: translateY()移动容器更稳 - 避免每帧都调
scrollIntoView——它内部会强制 layout，开销大
track 元素能替代 JS 同步逻辑吗？
不能。内置 track（如 kind="subtitles"）只负责渲染浏览器原生字幕控件，不暴露时间点、不提供 DOM 引用、无法绑定自定义样式或交互。你要做章节高亮、点击跳转、进度联动，还是得自己管。
立即学习“前端免费学习笔记（深入）”；
-
track适合纯展示型字幕，且依赖 VTT 文件格式与正确 MIME 类型（text/vtt） - 若需动态加载字幕（比如从 API 拿 JSON）、支持富文本、响应式布局或与 Canvas 动画联动，JS 手动同步是唯一路径
- VTT 时间戳精度为毫秒级，但解析后仍要映射到 DOM 节点，这一步绕不开 JS 控制
真正卡住人的从来不是“怎么写”，而是音频解码延迟、事件节流、DOM 更新策略这三块没对齐——界面一迟钝，第一反应是代码错了，其实只是时间调度没压准。
