CSS高刷屏滚动优化技巧

CSS的`scroll-behavior: smooth`在高刷屏（如120Hz）上看似流畅实则“伪平滑”，因其默认按60fps硬编码调度动画，无法动态匹配屏幕真实刷新率，导致高刷优势被浪费；Chrome 120+已悄然支持自动帧率适配，但Safari仍固守60fps且无媒体查询兜底；更关键的是，它完全无视`prefers-reduced-motion`偏好设置，需开发者手动监听并降级；与`position: sticky`共用时易因布局重排丢失锚点，引发跳变；真正可靠的高刷平滑滚动，往往需绕过CSS，改用`requestAnimationFrame`手写带阻尼曲线的`scrollTo()`控制——因为滚动的终极平滑，不在于加动效，而在于谁掌握每一帧的位移决策权。

scroll-behavior: smooth 在高刷屏上为什么还是卡

它本身不卡，但默认用的是“时间函数”，不是“帧函数”——浏览器按 60fps 节奏调度滚动动画，而 120Hz 屏幕本可跑更密的帧，scroll-behavior: smooth 却没告诉浏览器“请按当前屏幕刷新率重采样”。结果就是：动画帧被硬塞进 60fps 时间轴，高刷优势白费。

• 只在 :root 或 html 上设 scroll-behavior: smooth 才生效，设在 div 上无效（除非该 div 有 overflow: auto 且自身可滚动）
• Chrome 120+ 开始支持 scroll-behavior: smooth 在高刷屏下自动适配帧率，但 Safari 仍锁死 60fps，无媒体查询兜底手段
• 若页面有自定义 scrollIntoView({ behavior: 'smooth' })，它和 CSS 的 scroll-behavior 是两套调度逻辑，别混用——前者 JS 控制，后者 UA 控制，动画可能打架

@media (prefers-reduced-motion: reduce) 会关掉 scroll-behavior 吗

不会。这是个常见误解。@media (prefers-reduced-motion: reduce) 只影响 @keyframes、transition 和 animation，对 scroll-behavior 完全无感。W3C 明确把它归为“滚动行为”，不属于“motion”范畴。

• 想真尊重动效偏好，得手动监听 matchMedia('(prefers-reduced-motion: reduce)')，然后动态移除 scroll-behavior 或改用 auto
• 部分安卓 WebView 会把 scroll-behavior: smooth 当作 motion 处理并静默降级，但这是非标行为，不能依赖
• prefers-reduced-motion 媒体查询本身兼容性好（Chrome 74+/Safari 13.1+/Firefox 63+），但它的作用边界必须记清：不碰滚动行为

怎么让 smooth 滚动真正响应 120Hz 刷新率

目前没有标准 CSS 属性能显式声明“按设备刷新率渲染滚动动画”。唯一可行路径是绕过 scroll-behavior，用 requestAnimationFrame + element.scrollTo() 手写驱动，并读取 window.devicePixelRatio 和 screen?.refreshRate（仅 Chrome/Edge 实验性支持）做帧率预判。

• screen?.refreshRate 返回值不可靠：多数桌面浏览器返回 0 或 undefined，移动端也常缺失；别拿它做分支判断主逻辑
• 更稳的做法是：检测 matchMedia('(motion: reduce)').matches 为 false 时，启用 rAF 滚动；否则 fallback 到 scrollTo({ top, behavior: 'auto' })
• 手写 rAF 滚动必须加阻尼（如 ease-out 曲线），否则直接线性插值在高刷屏上反而显得“冲”——人眼对高帧率下的加速度变化更敏感

scroll-behavior 配合 position: sticky 会出什么问题

会丢滚动锚点。当 sticky 元素在滚动中“吸顶”瞬间，浏览器可能重排布局，导致 scroll-behavior: smooth 正在执行的动画目标位置错乱，表现为滚动突然跳变或中断。

• sticky 元素的 top 值如果依赖视口高度（如 top: calc(100vh - 80px)），在 resize 或横竖屏切换时极易触发锚点失效
• Chrome 115+ 对 sticky + smooth 组合做了优化，但 Safari 一直存在约 100ms 的锚点延迟，表现是“先滑一段，再吸顶，再继续滑”
• 临时解法：给 sticky 容器加 contain: layout paint，减少重排影响；长期看，避免在 sticky 区域内触发平滑滚动是更稳妥的选择

高刷屏的滚动动效，核心矛盾不在“要不要加 smooth”，而在“谁来决定每一帧的位移量”——CSS 交给了 UA，JS 交给了开发者。这个控制权交接处，正是所有卡顿、跳变、降级失效的根源。

好了，本文到此结束，带大家了解了《CSS高刷屏滚动优化技巧》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！