scroll-snap-type只控制滚动停止位置，不提供动画；平滑效果需配合scroll-behavior: smooth实现，且仅对scrollto()、scrollintoview()或锚点链接生效，对原生拖拽滚动无效。
因为 scroll-snap-type 是浏览器原生支持的滚动吸附机制，它不依赖 JavaScript 计算、不劫持滚轮事件、不干预滚动惯性，只要容器和子项满足基本前提，就能稳定触发“滚动一次停一屏”的行为——这是全屏滚动最核心的需求。
scroll-snap-type 不是“让滚动变平滑”，而是“让终点可预测”
很多人误以为加了 scroll-snap-type: y mandatory 就该自动滑动+停准，结果发现拖拽松手后还是瞬时跳转。这不是 bug，是设计使然：scroll-snap-type 只决定“停在哪”，不控制“怎么停”。它把对齐逻辑交给浏览器渲染管线底层处理，所以响应快、无卡顿、不丢帧。
- 真正触发平滑过渡的是
scroll-behavior: smooth（仅对scrollIntoView、scrollTo、锚点跳转生效） - 原生拖拽/滚轮/手指滑动，浏览器只做“吸附终点校正”，过程仍是原生惯性滚动
- 想全程动画？必须用 JS 配合
scrollIntoView({ behavior: 'smooth' })，但 iOS Safari 仍会忽略behavior: 'smooth'
为什么比 JS 滚动监听方案更稳
用 scroll 事件 + scrollTo 实现全屏滚动，本质是在滚动过程中不断干预位置，极易出问题：
- 快速滚动时
scroll事件被节流或丢失，导致吸附失败 - 计算
element.offsetTop会漏掉transform、margin、滚动条宽度等偏移，终点不准 - 在 iOS 上，
scrollTo调用可能被静默降级为瞬时跳转 - 监听器里改 DOM 或调
scrollTo容易触发循环：滚动 → 触发 → 改位置 → 再触发
scroll-snap-type 完全避开这些陷阱：它不监听、不计算、不重写，只声明规则，由浏览器在合成阶段统一执行。
mandatory 和 proximity 的实际区别远不止“是否强制”
选 mandatory 还是 proximity 不只是语气强弱问题，它直接影响用户操作反馈：
-
mandatory：只要滚动距离超过阈值（通常约 1/3 视口），松手后必定吸附到下一个scroll-snap-align点；适合全屏导航、演示页这类“非此即彼”的场景 -
proximity：仅当滚动结束位置离某个吸附点足够近（约 100px 内）才吸附，否则保持原位；适合文档阅读、长列表，允许用户微调浏览位置 - 移动端尤其注意：
proximity在 iOS Safari 上吸附灵敏度极低，常表现为“不吸附”，必须用mandatory才可靠
最容易被忽略的兼容性硬门槛
写了 scroll-snap-type: y mandatory 却没效果？90% 是卡在这三处：
- 容器没设
overflow-y: scroll或overflow-y: auto（hidden或visible会禁用吸附） - 容器高度不是明确值，比如用
min-height: 100vh或靠内容撑开（必须是height: 100vh） - 子项没逐个写
scroll-snap-align: start（哪怕父容器写了mandatory，子项不声明就等于没通电） - Safari 13.1 之前必须补
scroll-snap-stop: always到子项上，否则可能跳过某一页
这些不是“建议”，是浏览器判定“是否启用 scroll-snap”的硬性开关。少一个，整个机制就静默失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
