HTML歌词与同步滚动不冲突，问题在于滚动逻辑与时间轴耦合方式；歌词容器宜设position: relative，每行设position: absolute以避免偏移；scrollIntoView易“卡半行”因边界盒与视觉高亮不一致；timeupdate频率不足需结合requestAnimationFrame插值校正。
HTML歌词和同步滚动不冲突，但默认行为下会因元素尺寸、定位或事件干扰导致视觉不同步——问题出在滚动逻辑与歌词时间轴的耦合方式，而非HTML本身限制。
歌词元素必须用 position: relative 或 position: absolute 吗？
不是必须，但强烈建议对歌词容器（如 <div id="lyric-container">）设 position: relative，对每行歌词（<p class="lyric-line">）设 position: absolute。否则用 scrollTop 滚动时，行高计算误差、字体渲染差异、行间距塌陷都可能让高亮行偏移1–2像素。
- 绝对定位能绕过文档流重排，避免滚动时因某行换行导致后续所有行位置跳变
- 若用
flex+scrollIntoView，需确保每行有固定高度（min-height而非height），否则歌词含 emoji 或中英混排时高度不一致 - 禁用
line-height: normal，统一设为数值（如line-height: 1.6），否则 Chrome 和 Safari 对同一字体解析出的高度可能差 0.3px
scrollIntoView 在歌词同步中为什么常“卡半行”？
因为 scrollIntoView({ block: 'center' }) 以元素 边界盒（bounding box） 为中心，而歌词高亮通常靠 transform: scale(1.1) 或 font-weight: bold 实现，这些不改变边界盒尺寸，但视觉上放大了内容——结果就是“中心对齐了，但看起来没对准”。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 解决方法：改用
scrollIntoView({ block: 'nearest', inline: 'start' })+ 手动补偿偏移量（container.scrollTop = target.offsetTop - container.offsetHeight / 2 + target.offsetHeight / 2 * 0.7） - 更稳方案：不用
scrollIntoView，直接算scrollTop，公式为：target.offsetTop - container.clientHeight / 2 + target.clientHeight / 2 - 注意：如果歌词行用了
margin-bottom，必须在计算中排除它，否则偏移量会累积误差
音频 timeupdate 事件触发频率不够，导致歌词跳段
浏览器对 timeupdate 的触发并不严格按帧率（如 60fps），尤其在后台标签页、低功耗模式或音频解码压力大时，可能 200–400ms 才触发一次，而歌词精度常需 ±50ms 内响应。
立即学习“前端免费学习笔记（深入）”；
- 不要只依赖
timeupdate判断当前行，应结合requestAnimationFrame做插值校正：在每次raf中读取audio.currentTime，再查时间轴数组 - 歌词时间轴数据建议存为
Array<{ time: number, text: string }>，并预处理成带索引的二分查找结构（lowerBound），避免每帧都find()遍历 - 若用 Web Audio API（如
AudioContext+ScriptProcessorNode已废弃，改用AudioWorklet），可实现 sub-10ms 级别调度，但复杂度陡增，小项目不推荐
真正难调的不是滚动动作本身，而是当歌词含富文本（<span class="ruby">注音</span>）、动态字号缩放、或 CSS 容器查询（@container）时，getBoundingClientRect() 返回的坐标会随布局重算波动——这时候必须加防抖+缓存，且不能依赖单次测量值。
