scroll-behavior: smooth 必须写在 html 元素上才生效，写在 body 上无效；仅对锚点链接和未传参的 scrollintoview() 生效，js 滚动需显式传 behavior: 'smooth'；ios safari 支持差，建议优先用 js 方案并检测兼容性。
scroll-behavior: smooth 必须写在 html 上才生效
写了却没反应？90% 是因为加在了 body 上。浏览器真正的页面级滚动容器是 html 元素，body { scroll-behavior: smooth; } 在 Safari、Firefox 和多数 Chrome 版本里完全无效。
正确做法只有一行：
html {
scroll-behavior: smooth;
}
写完后，打开开发者工具 → 选中 html 元素 → 在 Computed 样式里确认 scroll-behavior 的值确实是 smooth，别只信源码。
- 某些 CSS 重置（比如
* { margin: 0; }）或 Normalize.css 会意外把html的overflow设为visible，导致该属性静默失效；可显式补一句html { overflow: auto; }防止覆盖 - 如果用了自定义滚动容器（如
<div class="content"> 并设了 <code>overflow-y: auto），那得单独给它加scroll-behavior: smooth，和html无关哪些操作能触发平滑滚动，哪些不能
scroll-behavior: smooth只对两类行为起作用：用户点击<a href="#section"></a>这类锚点链接，以及 JS 调用element.scrollIntoView()且未传behavior参数时的默认行为。以下操作完全不受影响，仍会“啪”一下跳过去：
element.scrollTop = 100-
window.scrollTo(0, 200)（老式写法，不带 options 对象） - Vue Router 或 React Router 的
router.push('/page#target')—— 这不是原生 hash 导航，需手动调用滚动 API
想用 JS 实现平滑，必须显式传参：
element.scrollIntoView({ behavior: 'smooth', block: 'start' }); // 或 window.scrollTo({ top: 300, behavior: 'smooth' });目标元素被固定导航栏遮住怎么办
锚点跳转后内容被
position: sticky或fixed导航栏盖住，不是滚动错了，是浏览器默认把目标元素顶部对齐视口顶部，没考虑头部高度。别在 JS 里手动减
offsetTop，那会破坏惯性、回弹和scroll事件时机。- 正确解法：给目标元素加
scroll-margin-top，值等于导航栏高度，例如：h2[id] { scroll-margin-top: 72px; } - 不要用
scroll-padding-top—— 它作用于整个滚动容器，和锚点定位无关 - 如果导航栏高度响应式变化（比如折叠/展开），优先改用
scrollIntoView({ block: 'start', behavior: 'smooth' })配合目标元素的padding-top补偿，而不是动态改 CSS
iOS Safari 和系统动画偏好怎么处理
scroll-behavior: smooth在 iOS Safari 上极不可靠：15.4 之前完全不支持；15.4–16.0 支持但常卡顿、跳帧；iOS 16+ 仅对 JS 调用scrollIntoView({ behavior: 'smooth' })有效，CSS 全局声明依然被忽略。更隐蔽的问题是系统级设置：
@media (prefers-reduced-motion: reduce)下，所有浏览器都会静默禁用该属性，不报错也不提示。- 检测兼容性别用
@supports (scroll-behavior: smooth)—— 它只检查 CSS 属性是否存在，不反映实际行为是否可用 - 更可靠的方式是：
typeof Element.prototype.scrollIntoView === 'function'，再配合实际调用后监听scroll事件是否延迟触发 - 关键交互中建议统一用
el.scrollIntoView({ behavior: 'smooth' })，并 fallback 到el.scrollIntoView()（瞬时）而非依赖 CSS 声明
真正麻烦的不是写法，而是不同平台对「平滑」的理解差异——iOS 上的「smooth」可能比桌面端慢一倍，也可能根本不动；而 Android WebView 封装环境（如 Cordova）甚至会拦截 hash 变更，让整个方案彻底失效。
