scroll-behavior: smooth 必须作用于 html 元素，因其是根滚动容器；body 非滚动层，设此属性无效；需确保 html 选择器生效、无覆盖、兼容性达标，并避免在 touchmove 中调用 scrollTo。
html { scroll-behavior: smooth } 为什么加在 body 上无效
因为 scroll-behavior 必须作用于**根滚动容器**，也就是 html 元素本身。浏览器的主视口滚动由 html 控制，body 只是普通流内元素——即使它看起来“在滚动”，实际滚动层仍是 html。写到 body 上等于对一个不负责滚动的元素设属性，自然没效果。
常见错误现象：a[href="#section"] 点击后仍生硬跳转，DevTools 里检查 html 元素样式发现该属性未生效；或写了但用了 !important 覆盖了其他规则，导致被忽略。
- 必须用
html { scroll-behavior: smooth; }，不能用body或:root - 若页面有框架（如某些 CMS 或微前端），需确认
html是当前文档的根节点，而非嵌套 iframe 内的 - Safari 15.4+、Chrome 61+、Edge 79+ 支持；iOS Safari 15.4 之前版本不支持，需 fallback
window.scrollTo({ behavior: 'smooth' }) 在移动端触发回弹失败的典型原因
所谓“回弹”，其实是用户快速拖拽后松手，系统自动执行的惯性减速滚动。而 window.scrollTo({ behavior: 'smooth' }) 是**强制动画**，与原生触摸滚动机制互斥。一旦用户正在 touchmove，再调用它会立即中断当前手势，导致“卡住”或“跳变”，根本不会出现预期的弹性收尾效果。
使用场景：适用于点击按钮触发的确定性滚动（如回到顶部、表单校验后聚焦），**不适用于模拟用户滑动行为或接管 touch 事件流**。
立即学习“前端免费学习笔记（深入）”；
- 不要在
touchmove中反复调用scrollTo—— 容易触发渲染抖动甚至主线程阻塞 - 目标元素若为
display: none、visibility: hidden或尚未挂载（如 Vue 的v-if未满足），调用静默失败，无报错 - Android WebView 中，若页面存在
overflow: hidden或强制position: fixed的遮罩层，可能截断滚动事件，使scrollTo无响应
-webkit-overflow-scrolling: touch 导致 iOS 滚动“回弹失效”的真实表现
这个 CSS 属性本意是启用 iOS 的原生异步滚动线程，但它在 iOS 12 及更早版本中存在已知缺陷：开启后，系统会禁用部分弹性系数，导致松手后滚动距离明显缩短、减速过快，甚至直接停住，失去自然“回弹感”。这不是 bug，而是 WebKit 当年为兼容旧渲染管线做的妥协。
性能影响比想象中严重：实测显示，在复杂布局下开启该属性，iOS 12–14 设备内存占用平均上升 8–12MB，且 scroll 事件触发频率下降 40% 以上，间接影响基于滚动位置的逻辑（如吸顶、懒加载）。
- 仅当容器明确需要“局部滚动”且目标平台为 iOS 15+ 时才建议开启
- 若必须兼容 iOS 12–14，应移除该属性，改用
scroll-view（UniApp）或 Better-Scroll 等 JS 方案接管 - 注意：该属性对 Android 完全无效，加了也白加
实现“视觉回弹”但不依赖原生滚动的轻量 fallback 方案
当 scroll-behavior 和原生 scrollTo 都不可靠（比如老 iOS 或混合 WebView 场景），可用 requestAnimationFrame + 缓动函数手动模拟。关键不是完全复刻物理引擎，而是让终点附近减速明显、松手后有余韵感。
核心思路：监听 touchend，根据最后一次 touchmove 的速度估算惯性距离，然后用 easeOutCubic 或 easeOutQuint 控制减速节奏，避免线性滚动带来的机械感。
示例片段（简化版）：
let lastY = 0;
let velocity = 0;
let ticking = false;
<p>element.addEventListener('touchmove', e => {
const y = e.touches[0].clientY;
velocity = y - lastY;
lastY = y;
});</p><p>element.addEventListener('touchend', () => {
if (Math.abs(velocity) > 2) {
const targetScroll = element.scrollTop + velocity * 3; // 粗略放大
animateScroll(element, targetScroll, 400);
}
});</p><p>function animateScroll(el, to, duration) {
const start = el.scrollTop;
const change = to - start;
const startTime = performance.now();</p><p>function ease(t) {
t /= duration;
return 1 - Math.pow(1 - t, 5); // easeOutQuint
}</p><p>function step(now) {
const elapsed = now - startTime;
el.scrollTop = start + change * ease(elapsed);
if (elapsed < duration) requestAnimationFrame(step);
}
requestAnimationFrame(step);
}
这个方案绕开了浏览器滚动策略差异，但代价是：无法触发原生 scroll 事件，所有依赖它的监听器（如 IntersectionObserver）需同步改用 requestAnimationFrame 轮询判断位置。
最容易被忽略的一点：手动滚动时，scrollTop 在 iOS Safari 中可能被四舍五入到整数像素，导致最后几帧出现“抖动”；应在 step 中做 Math.round() 截断，而非放任浮点累积误差。
