平滑度不可调，scroll-behavior: smooth 和 behavior: 'smooth' 均由浏览器固定实现，时长300–500ms、缓动曲线不可配置；需自定义时必须用 requestAnimationFrame 手动实现。
平滑度不是可调参数，HTML 本身不提供“滚动速度”或“缓动曲线”的控制入口；所谓“控制平滑度”，实际是选对 API、避开降级陷阱、并在必要时用 JS 替代 CSS 方案。
scroll-behavior: smooth 的平滑效果不可自定义
写 html { scroll-behavior: smooth; } 后，浏览器决定动画时长和缓动函数（通常是 ease-out 类似曲线），你无法通过 HTML 或 CSS 修改它。这不是缺陷，而是规范设计——为保证系统级一致体验，W3C 明确禁止暴露该控制权。
- 所有现代浏览器（Chrome 61+、Firefox 68+、Safari 15.4+）都用各自引擎实现，时长约 300–500ms，不可配置
-
scroll-behavior只接受smooth或auto，没有fast、slow或cubic-bezier()等值 - 试图用
transition作用于html或body滚动属性会无效——滚动位置不是 CSS 可过渡的属性
window.scrollTo() 和 scrollIntoView() 的 behavior: 'smooth' 同样不可调
JS 中传 { behavior: 'smooth' } 是启用浏览器原生平滑滚动，效果与 scroll-behavior: smooth 一致，同样无参数可调。
-
window.scrollTo({ top: 100, behavior: 'smooth' })和el.scrollIntoView({ behavior: 'smooth' })都走同一套渲染管线 - 传错格式（如
window.scrollTo(0, 0)或el.scrollIntoView(true)）会退化为瞬跳，不是“不够平滑”，而是根本没启用平滑 - 若需真正自定义时长或曲线，必须放弃原生
behavior: 'smooth'，改用requestAnimationFrame手动插值滚动 —— 但这是重写滚动逻辑，不是“调平滑度”
哪些操作会让平滑效果变差甚至失效
不是代码写得不够“平滑”，而是环境触发了浏览器的静默降级。
立即学习“前端免费学习笔记（深入）”；
- 用户开启系统「减少运动」偏好：
@media (prefers-reduced-motion: reduce)下，所有behavior: 'smooth'自动转为'auto'，这是符合无障碍规范的预期行为，不是 bug - 目标元素被
display: none、visibility: hidden或尚未挂载（如 Vuev-if条件未满足），调用scrollIntoView会静默失败，看起来像“没滚动” - 滚动容器不是
window：比如侧边栏用了overflow: auto，却对它调用window.scrollTo()，必然无效；必须对其 DOM 元素调用element.scrollTo() - iOS Safari 15.4 之前版本完全不支持
scroll-behavior，且局部容器（如div）的behavior: 'smooth'在某些混合布局下会静默回退
真要控制“感觉上的平滑度”，只能换思路
如果你发现滚动太慢、太急、或停顿感强，问题通常不在“平滑度设置”，而在滚动目标、时机或容器状态。
- 用
scroll-margin-top替代 JS 偏移计算：固定头部遮挡时，给目标元素加scroll-margin-top: 80px，比在 JS 里反复减去 headerHeight 更稳定 - 避免在
touchmove中调用scrollTo：这会打断原生触摸惯性，导致“卡住”而非“回弹”，移动端尤其明显 - 动态内容加载后立即滚动？等
requestIdleCallback或offsetHeight确认尺寸就绪，否则offsetTop取的是 0 - scroll-snap 布局下别用
scrollTo定位到元素：它会破坏吸附逻辑；改用window.scrollBy({ top: window.innerHeight })进行相对滚动
真正难的不是让滚动“更平滑”，而是判断什么时候不该用平滑——比如表单校验后聚焦错误字段，用 scrollIntoView({ block: 'center' }) 比强行滚到顶部更有效；又比如无限列表加载中，连续触发 scrollTo 会导致动画队列堆积，停在中间不动。这些细节，比调“平滑度”重要得多。
