用 scrollIntoView 实现平滑切换（兼容性好、无依赖）

别急着找轮子，原生API就足够强大。这里的核心不是动画效果，而是“精准锚定”和“排除干扰”。

• section.scrollIntoView({ beha vior: 'smooth', block: 'start' }) 是基础操作。但务必确保在调用它之前，页面没有处于其他滚动过程中，否则行为会难以预测。
• 监听 wheel（鼠标滚轮）或 touchmove（触摸移动）事件时，一定要记得 e.preventDefault()。这是为了防止系统默认的滚动行为跳出来“捣乱”，和你自定义的切换逻辑产生冲突。
• 移动端适配要更周全：除了 wheel，必须同时监听 touchstart 和 touchend 来计算滑动距离和方向，因为iOS设备上单纯靠 wheel 事件可能不触发。
• 管理好切换状态：设置一个 isScrolling 标志位。在切换动画进行时，禁用新的切换触发。等到 scrollend 事件触发（或用 setTimeout 设置一个合理的延迟）后，再重置这个标志位。

来看一个简单的代码片段：

sections.forEach((sec, i) => {
  sec.addEventListener('click', () => {
    if (isScrolling) return;
    isScrolling = true;
    sec.scrollIntoView({ beha vior: 'smooth' });
  });
});

IntersectionObserver 检测当前页并更新导航状态

页面能切换还不够，用户需要知道“我现在在哪一页”。用 IntersectionObserver 来监听各个section与视口的交叉状态，比传统监听 scroll 事件性能更好，精度也更高。

立即学习“前端免费学习笔记（深入）”；

• 阈值设置要巧妙：可以设为 [0.2, 0.5, 0.8] 这样的数组，避免在临界点附近频繁抖动。通常，当 entry.intersectionRatio > 0.5 时，就可以认为该页面被“激活”了。
• 样式操作要优雅：不要在Observer的回调函数里直接写DOM样式。更好的做法是添加或移除特定的class，把具体的高亮样式交给CSS来控制，这样更易于维护。
• 注意初始化状态：页面首次加载时，可能所有section都还没进入视口（比如从页面底部打开）。这时需要手动触发一次 observer.takeRecords()，或者在初始化时用 getBoundingClientRect() 检查一下。

这里有个常见错误：如果 rootMargin 设置为 '0px'，首屏section在刚加载时，intersectionRatio 可能为0，导致状态未被识别。将其调整为 '-1px' 或 '0px 0px -1px 0px' 通常就能修复。

移动端滑动卡顿？重点查这三处

遇到移动端滑动不跟手、卡顿的问题，先别急着怀疑Ja vaScript性能。90%的情况下，问题出在下面这三个地方：

• CSS渲染层问题：如果为了硬件加速写了 transform: translateZ(0) 或 will-change: transform，但没有配合 backface-visibility: hidden，在iOS上可能导致渲染层撕裂，从而引发卡顿。
• 内部元素事件劫持：如果section内部有 input、video 或 iframe 等元素，它们可能会“劫持”touch事件。可以考虑给这些容器添加 pointer-events: none（但注意，需要交互的内容区域要排除在外）。
• 边界滚动行为冲突：在 body 或 html 标签上设置了 overscroll-beha vior: contain 来抑制回弹效果，但忘记在各section容器上也同步设置。这会导致滑动到页面边界时，整个浏览器窗口发生晃动。

真正棘手的，往往是浏览器兼容性差异。比如Safari对 dvh 单位的支持可能不一致，或者微信内置浏览器会部分忽略 scroll-beha vior 的平滑效果。面对这种情况，更稳妥的降级方案是：使用 window.scrollTo({ top: target.offsetTop }) 进行跳转，同时用 CSS @media (prefers-reduced-motion) 媒体查询来尊重用户是否偏好减少动画的设置。