scroll-snap-type 必须配合 scroll-snap-align 才生效；容器需设 display: flex、overflow-x: auto 和 scroll-snap-type: x mandatory，子项需设 flex: 0 0 100% 和 scroll-snap-align: start，并禁用 touch-action: pan-y。
scroll-snap-type 必须配合 scroll-snap-align 才生效
单独设置 scroll-snap-type: x mandatory 不会触发任何翻页行为，这是最常见的误解。容器必须有滚动能力（比如 overflow-x: auto），且每个可停靠的子元素必须显式声明停靠点位置。
典型错误是只加容器样式，忘了给子项加 scroll-snap-align: start（横向时用 start 或 center，end 在横向场景基本无效）。
- 容器需设
display: flex+overflow-x: auto+scroll-snap-type: x mandatory - 每个子元素需设
flex: 0 0 100%（保证单页宽度占满）+scroll-snap-align: start - 务必禁用
touch-action: pan-y（否则 iOS Safari 会拦截横向滑动）
移动端 Safari 的 scroll-snap 行为不稳定
iOS 14–15 对 scroll-snap-type 支持有明显 bug：快速滑动后可能停在两个子项中间，或首次滑动不触发吸附。这不是代码写错，而是渲染管线未对齐导致的。
缓解方案不是改 CSS，而是加一层 JS 补偿：
- 监听
scroll事件，用getBoundingClientRect()检查当前可见子项 - 若偏移量超过阈值（如 50px），用
element.scrollIntoView({ behavior: 'smooth', block: 'nearest', inline: 'start' })强制对齐 - 避免在
scroll中频繁调用，建议用requestAnimationFrame节流
scroll-snap-type: x proximity 和 mandatory 的区别很实际
proximity 是“靠近就吸附”，适合内容长度不一、允许用户微调查看的场景；mandatory 是“必须停在 snap point”，才是类 APP 翻页所需的硬停靠。
但要注意：mandatory 在内容未填满容器时会失效——浏览器要求 snap 区域必须可滚动到达。如果所有子项总宽度 scroll-snap-type 直接被忽略。
- 确保子项总宽度 ≥ 容器宽度（例如用
min-width: 100vw防止缩放后塌陷） - 不要用
width: 100%+padding，会导致计算偏差；改用flex-basis: 100%更可靠 -
proximity在桌面端鼠标滚轮下响应迟钝，基本只适合触控设备
性能陷阱：不要在 scroll-snap 容器里放复杂动画或 iframe
Chrome 和 Safari 在启用 scroll-snap-type 时会对容器开启合成层（compositing layer），但如果子项含 transform 动画、video 或 iframe，容易触发频繁图层重组，造成滑动卡顿甚至白屏。
真实项目中，这类问题往往在真机测试阶段才暴露，开发时看不出异常。
- 把轮播图里的
img替换为background-image（减少解码开销） - 避免在子项内使用
will-change: transform，除非必要 - 用
chrome://tracing录制滚动过程，重点看 “Layer” 和 “Paint” 阶段耗时
scroll-snap 的边界情况比想象中多：缩放页面、动态插入子项、键盘方向键导航都会打破预期。别指望纯 CSS 实现零 Bug 的翻页，留出 JS 干预余地更实际。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
