scroll-behavior: smooth 不能直接实现全屏切屏，因为它仅平滑锚点跳转和 scrollTo，不接管滚动事件、不强制对齐 section 边界、不阻止中间停顿；真正可行的是 scroll-snap-type + smooth 声明式方案，辅以 JS 处理兼容性与手动控制。
scroll-behavior: smooth 能实现页面级平滑滚动，但无法直接用于“全屏切屏”这种多节（section）垂直分页式滚动——它只控制 window.scrollTo() 或锚点跳转的动画，不接管滚动事件、不阻止默认滚动行为、也不感知视口高度变化。
为什么 scroll-behavior: smooth 不能直接做全屏切屏
全屏切屏（如一页一屏的 vertical paging）本质是：滚动到最近的 section 视口顶部，并强制对齐，而非“渐进滚动”。scroll-behavior: smooth 只让浏览器自动补间滚动过程，但不会：
- 限制滚动范围（用户仍可拖拽停在两屏中间）
- 对齐到特定元素边界（比如
section高度 =100vh） - 响应滚轮/触控板惯性滑动后自动吸附
- 处理
scroll-snap-type未生效时的 fallback
真正能落地的全屏切屏方案：scroll-snap-type + smooth 搭配
现代浏览器中，可靠且声明式的方式是结合 scroll-snap-type 和 scroll-behavior: smooth，并确保 DOM 结构与样式约束到位：
- 父容器（如
body或.container）需设scroll-snap-type: y mandatory - 每个
section设scroll-snap-align: start和height: 100vh（或min-height: 100vh） - 为触发锚点跳转时有动画，根元素加
scroll-behavior: smooth（推荐写在html上） - 避免给
section设margin或padding（会破坏 snap 对齐精度）
html {
scroll-behavior: smooth;
}
.container {
height: 100vh;
overflow-y: scroll;
scroll-snap-type: y mandatory;
}
section {
height: 100vh;
scroll-snap-align: start;
}
JavaScript 补充控制：解决 scroll-snap 兼容性与手动触发问题
当需要程序化切屏（如按钮点击、键盘方向键），或兼容 Safari 15.4 以下、旧版 Firefox 时，必须用 JS 主动滚动并模拟吸附。关键点：
立即学习“前端免费学习笔记（深入）”；
- 用
element.scrollIntoView({ behavior: 'smooth', block: 'start' })替代scrollTo，它尊重scroll-snap且自带平滑 - 监听
wheel事件时，需preventDefault()并计算目标section索引，再调用scrollIntoView—— 否则原生滚动会和 snap 冲突 - 移动端 touchmove 需额外处理，
scroll-snap在 iOS Safari 上对 touch 不稳定，建议降级为scrollTop+requestAnimationFrame插值 - 注意：
scroll-behavior: smooth对 JS 调用的scrollTo生效，但对scrollIntoView的影响因浏览器而异（Chrome 支持，Safari 有时忽略）
容易被忽略的细节：滚动容器、视口单位与缩放适配
实际项目中最常踩坑的是：
- 把
scroll-snap-type错写在body上，但body默认不是滚动容器（overflow 是 visible），应作用于明确设了overflow-y: scroll的祖先元素 - 用
100vh但未考虑 iOS Safari 地址栏收起/展开导致视口高度变化，造成 snap 错位；稳妥做法是用100dvh（需检查支持）或 JS 动态设置min-height - 设置了
scroll-behavior: smooth却发现锚点跳转没动画——检查是否启用了prefers-reduced-motion: reduce，此时浏览器会静音所有smooth - 使用
scroll-snap-stop: always可禁止快速滚动跳过中间屏（但仅 Chrome 120+ 支持，暂勿依赖）
全屏切屏不是开个 scroll-behavior 就完事，它是一组样式约束、滚动上下文定义和必要时 JS 干预的组合技。snap 对齐是基础，smooth 是锦上添花，而边界条件（缩放、滚动源、兼容性）才是上线前最耗时间的部分。
