scroll-behavior: smooth 在高刷屏上卡顿因默认按60fps调度，未适配屏幕真实刷新率；Chrome 120+已支持自动适配，Safari仍锁死60fps；它不响应prefers-reduced-motion，需手动监听处理；与sticky配合易丢锚点，手写rAF滚动更可控。
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 交给了开发者。这个控制权交接处，正是所有卡顿、跳变、降级失效的根源。
