移动端 scroll-behavior: smooth 不完全支持：iOS Safari 15.4+ 才支持，旧版忽略；Android Chrome ≥61 支持但 WebView（如微信X5）常降级，必须用 JS 回退方案。
scroll-behavior: smooth 在移动端到底支不支持？
不完全支持——iOS Safari 直到 15.4 才开始支持 scroll-behavior: smooth，而更早版本（包括大量存量 iOS 设备）会直接忽略该声明，回退为默认的瞬时滚动。Android Chrome 支持较早（≥61），但 WebView（尤其旧版 Cordova / 微信内置浏览器）常禁用或降级处理。
这意味着：只靠 CSS 声明 scroll-behavior: smooth 在移动端无法保证效果，必须配合 JS 回退方案。
怎么让 scrollTo 行为真正平滑（兼容所有主流移动环境）
优先用 Element.scrollTo() 的 behavior: 'smooth' 选项，它比全局 scroll-behavior 更可控，且现代移动端浏览器基本都支持（iOS Safari ≥15.4，Chrome ≥61，Firefox ≥78）。但要注意：部分安卓 WebView 或微信 X5 内核仍不识别该选项，会静默降级为瞬时滚动。
- 务必检测支持性：
'scrollBehavior' in document.documentElement.style只判断 CSS 属性，不够；应改用typeof Element.prototype.scrollTo === 'function'+ 尝试调用并监听是否触发scroll事件延迟 - 避免对
window.scrollTo()直接传对象参数——某些旧 WebView 会报TypeError: Illegal invocation，改用document.scrollingElement?.scrollTo() - 滚动目标元素若未渲染完成（比如在 Vue
v-if切换后立即调用），offsetTop可能为 0，需加requestAnimationFrame延迟执行
示例：
立即学习“前端免费学习笔记（深入）”；
if ('scrollTo' in Element.prototype) {
targetEl.scrollIntoView({ behavior: 'smooth', block: 'start' });
} else {
// 降级：用 requestAnimationFrame + scrollTop 逐帧逼近
}
为什么用 scrollIntoView 而不是手动计算 scrollTop？
scrollIntoView 自动处理容器滚动、sticky 头部、iframe 嵌套等边界情况，手动算 scrollTop 极易出错——比如父容器设置了 overflow: hidden 但未设高度，或存在 transform 触发的层叠上下文，都会导致 offset 计算偏移。
-
scrollIntoView({ block: 'nearest' })比'start'更省性能，适合长列表中“就近滚动”场景 - 微信内嵌浏览器对
inline选项支持差，统一用block级别即可 - 若目标元素在
position: fixed容器内，scrollIntoView可能失效，此时需显式指定root参数为该容器
平滑滚动卡顿或跳变的常见原因
不是代码写错了，而是被其他样式或脚本干扰了。最典型的是：滚动过程中触发了强制同步布局（forced synchronous layout）。
- 监听
scroll事件时读取offsetTop、getBoundingClientRect()等会触发重排，尤其在 iOS WebKit 下极易卡顿 - CSS 中给滚动容器加了
will-change: transform可能反而引发合成层抖动，建议仅在必要时对滚动目标元素设置 - 使用 IntersectionObserver 替代 scroll 事件做懒加载，避免滚动中频繁计算
- Vue/React 中，
key变更导致滚动元素被销毁重建，scrollIntoView就找不到目标了——要确保 DOM 节点复用
真正难的从来不是加个 smooth，而是让整个滚动链路不被其他逻辑拖慢或打断。
