scroll-snap-type 必须设在滚动容器上而非子项，需配合 overflow: auto/scroll 触发滚动上下文，且容器要有明确尺寸和 scroll-snap-align 显式设置于每个子项，mandatory 适合轮播，center 对齐最稳妥。
scroll-snap-type 必须设在滚动容器上，不是子项
很多人把 scroll-snap-type 写在轮播项（如 .slide）上，结果完全没效果。它只能作用于**滚动容器本身**，比如 .carousel 或 body。而且必须配合 overflow: auto 或 scroll 才能触发滚动上下文——单纯设 scroll-snap-type: x mandatory 但容器不滚动，等于没写。
常见错误现象：scroll-snap-align 设了但滑动停不住、惯性滚动直接飞过目标点、触摸滑动卡顿或跳变。
-
scroll-snap-type的第二个参数用mandatory还是proximity？mandatory强制对齐，适合轮播；proximity只在靠近时吸附，更适合长列表分段浏览 - 容器必须有明确的尺寸（如
width: 100vw）和overflow-x: auto，且禁用overscroll-behavior: contain（否则 iOS 上可能阻断 snap 行为） - 别忘了加
-webkit-overflow-scrolling: touch（iOS Safari 旧版本兼容必需）
每个轮播项必须设 scroll-snap-align，且不能依赖 flex 或 grid 自动对齐
scroll-snap-align 是每个可停靠项的“锚点”，必须显式设置。哪怕你用 display: flex + flex-direction: row 排列，也不代表浏览器知道该对齐哪一侧——默认是 none，即不参与吸附。
典型使用场景：横向轮播，每张图占满视口宽度，希望每次滑动精准停在图中心。
- 设
scroll-snap-align: center最稳妥，适配不同宽高比内容；若只希望左对齐（如文字卡片），可用start - 如果项内有 padding/margin，
scroll-snap-align对齐的是**内容盒边缘**，不是外边距外沿，所以 padding 不影响对齐位置 - 避免给轮播项设
width: fit-content或inline-block，这会导致宽度计算异常，snap 失效
移动端 touch 滚动行为受 overscroll 和 inertia 影响极大
iOS 和 Android 对 scroll-snap 的实现差异明显：iOS Safari 默认开启滚动惯性，但 snap 吸附容易被惯性冲过头；Android Chrome 则更倾向严格停靠，但低版本可能忽略 mandatory。
真实问题：手指快速滑动后松手，页面滑过目标项、停在空白处，或反复小幅抖动才停下。
- 加
scroll-snap-stop: always到每个轮播项（Chrome 99+ / Safari 16.4+ 支持），强制每次滚动只允许停在一个 snap 点，禁止跨项滑动 - 禁用
overscroll-behavior-x: contain—— 它会抑制 snap 的回弹修正逻辑，在 iOS 上尤其关键 - 避免同时监听
scroll事件做手动控制，CSS snap 和 JS 滚动监听混用极易冲突，导致视觉错位或卡死
性能陷阱：不要用 transform 或 transition 干预 scroll-snap 流程
有人想给轮播加淡入淡出或缩放效果，在 scroll 事件里用 transform 动态改项样式。这会破坏浏览器原生 scroll-snap 的合成层优化，导致掉帧、滑动粘滞，甚至 snap 失效。
真正轻量的做法是利用 :nth-child 或 view-transition（实验性）做视觉反馈，而不是劫持滚动本身。
- 轮播项的动画效果应基于
scroll-snap-align触发的布局变化，而非滚动偏移量——例如用opacity配合will-change: opacity，而非监听scrollLeft - 如果必须响应滚动位置，优先用
IntersectionObserver监听项是否处于 active snap 状态，比scroll事件更稳定、开销更低 - 避免给滚动容器设
will-change: scroll-position，现代浏览器已自动优化，手动加反而可能引发渲染异常
scrollTo（哪怕只是 scrollTo({left: 0, behavior: 'instant'})）来刷新 snap 缓存。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
