应使用IntersectionObserver监听段落进入视口，设threshold为[0.33]、rootMargin为"0px 0px -66% 0px"精准捕获“即将成为主角”的段落，复用单个observer实例批量注册，配合CSS预设高亮类，避免getBoundingClientRect手动计算导致的偏移、重排和浮点误差问题。
滚动时怎么让当前段落自动高亮？
核心是监听 window.onscroll 或用 IntersectionObserver 判断段落是否进入视口，再动态加 class。前者简单但性能差，后者更现代、更轻量，推荐优先用。
关键点在于：不能只看「是否在视口内」，得定义「当前段落」——通常指顶部刚过视口 1/3 或居中位置落在视口内的那个 <p></p>。否则快速滚动时高亮会跳变或滞后。
-
IntersectionObserver的threshold设为[0.33]，配合rootMargin: "0px 0px -66% 0px"（上移视口下边界），能较稳定捕获“即将成为主角”的段落 - 避免对每个
<p></p>都新建 observer，应复用一个实例，用observer.observe(p)批量注册 - 高亮 class 要提前在 CSS 里写好，比如
.p-active { background-color: #f0fff0; }，别在 JS 里拼样式字符串
为什么用 getBoundingClientRect() 容易出错？
手动计算每个段落的 top 和 scrollTop 看谁最接近视口中心，看似直观，实则埋雷多：
- 页面有 fixed 头部、sticky 导航栏时，
getBoundingClientRect().top返回的是相对视口的值，但scrollTop是相对文档的，二者不能直接比 - 字体加载（
font-display: swap）、图片懒加载、CSS 动画重排都可能让段落高度在滚动中突变，导致计算结果瞬间失效 - 移动端 zoom 或 pinch 缩放会让
getBoundingClientRect返回小数坐标，浮点误差叠加后判断失准
真要用它，务必加防抖 + 缓存段落 offsetTop（相对于文档），并监听 resize 和 fontload 事件重新缓存。
立即学习“前端免费学习笔记（深入）”；
id 锚点和高亮不同步怎么办？
用户点击目录里的 <a href="#sec2"></a> 跳转后，对应段落没高亮，或高亮了别的段落——这说明滚动结束时机没抓准。
- 原生锚点跳转是异步的，
scrollIntoView后 DOM 还没重绘完成，立刻查位置会拿到旧值 - 别用
setTimeout硬等，改用requestAnimationFrame+ 检查document.scrollingElement.scrollTop是否稳定 - 更稳妥的做法：跳转前记录目标
id，在scroll事件里检测是否已到位，到位后立即触发一次高亮更新 - 如果用了平滑滚动（
scroll-behavior: smooth），必须监听scrollend事件（注意 Safari 目前不支持，需降级）
长文章里高亮卡顿或延迟明显？
不是 JS 慢，大概率是 DOM 查询或重排太重。尤其当段落超 200 个、又带 inline 样式或伪元素时：
- 别每次滚动都
document.querySelectorAll('p')，把所有段落节点存在数组里，初始化时一次性获取 - 高亮切换时，只操作
className，不要用style.backgroundColor反复设内联样式 - 避免在滚动回调里调用
getComputedStyle或触发 layout，例如读取offsetHeight会强制同步重排 - 极端情况可考虑虚拟滚动：只渲染视口附近 ±2 屏的段落，其余用占位
<div style="height: XXpx"> <p>真正难的不是“怎么高亮”，而是“怎么让高亮不干扰滚动本身的流畅性”。很多实现卡顿，是因为把视觉反馈逻辑塞进了主线程关键路径里。</p> </div>
