scroll-behavior: smooth 无效最常见原因是仅在 html/body 设置，而实际滚动的是内部 overflow 容器，须对该容器单独设置；旧版 Safari（≤15.4）不支持；scrollIntoView() “跳一下就停”是因目标已部分可见；性能下降源于持续插值计算，需按需启用。
scroll-behavior: smooth 为什么加了没反应
最常见的情况是：只在 html 或 body 上写了 scroll-behavior: smooth，但页面滚动目标不是文档根，而是某个带 overflow: auto 或 overflow-y: scroll 的容器。
滚动行为生效的前提是「目标元素自身支持原生滚动」且「CSS 作用于该元素」。全局配置只影响 html（即整个视口），对内部容器无效。
- 若用
scrollTop或scrollIntoView()滚动的是某个div，必须给那个div单独加scroll-behavior: smooth -
html元素上设置时，需确保没有其他样式（比如height: 100%+overflow: hidden）意外禁用了文档滚动 - 部分旧版 Safari（≤15.4）不支持
scroll-behavior，可降级为 JavaScript 实现，但别盲目 polyfill —— 大多数现代项目已无需兼容到那么老
scrollIntoView({ behavior: 'smooth' }) 在 Chrome 里跳一下就停
这不是 bug，是默认行为：当目标元素已在视口内（哪怕只露出 1px），scrollIntoView() 就会提前退出，导致“跳一下就停”。它只在需要滚动时才平滑，否则直接忽略。
- 加
{ block: 'nearest', inline: 'nearest' }可减少强制滚动，但不会改变“已可见即不滚”的逻辑 - 真要强制每次都滚动，得先手动判断是否可见：
!element.getBoundingClientRect().top < window.innerHeight，再决定是否调用 - 注意：
scrollIntoView()的behavior: 'smooth'和 CSS 的scroll-behavior是两套机制，互不替代；前者控制 JS 触发的滚动，后者控制锚点跳转或scrollTop赋值
使用 scroll-behavior 后页面首屏变慢
不是 CSS 本身慢，而是触发了浏览器对滚动区域的持续监听和插值计算。尤其在低端设备或长列表中，叠加 will-change: scroll-position 或频繁重排元素时，帧率容易掉。
立即学习“前端免费学习笔记（深入）”；
- 避免在
body或高频滚动容器上无差别启用；优先用在用户明确预期有平滑跳转的场景（如目录锚点、Tab 切换内容区） - 不要和
transform动画共用同一元素 —— 滚动行为会干扰合成层判定，可能引发回流 - 如果用 IntersectionObserver 做懒加载，又同时开了
scroll-behavior: smooth，注意 Observer 的threshold设太小（如[0]）会让回调过于密集，加剧性能抖动
锚点跳转失效或滚动错位
典型现象：点击 #section2，页面滚动但停在错误位置，甚至卡在顶部。根源往往是布局未稳定时就触发了滚动，或目标元素被动态插入后未正确测量。
- 确保锚点元素存在且有明确尺寸；用
visibility: hidden或display: none隐藏的目标，scrollIntoView()无法定位 - SPA 中路由切换后立即跳锚点，需等 DOM 渲染完成 —— 不要用
setTimeout猜时机，改用requestAnimationFrame或框架提供的nextTick类机制 - CSS 中若对
html设置了scroll-padding-top（例如适配固定 header），但值写成env(safe-area-inset-top)且未降级，iOS Safari 可能解析失败，导致偏移归零
scroll-behavior 当作全局特效来加，而没区分清楚「谁在滚」「谁该响应」「谁在监听」。 
