scroll-snap-type 不生效的主因是容器未启用滚动或方向不匹配；需确保 overflow 设置正确、内容溢出，且 scroll-snap-type 方向与实际滚动方向一致。
scroll-snap-type 不生效？检查容器溢出和滚动方向
最常见的情况是写了 scroll-snap-type: y mandatory 却完全没反应——八成是因为容器没开启滚动。CSS 滚动捕捉只在有滚动行为的容器上起作用，必须同时满足：容器有 overflow: auto 或 overflow-y: scroll，且内容高度超出容器（产生可滚动区域）。
另一个高频坑是方向不匹配：scroll-snap-type 的第一个参数（x / y / block / inline）必须和实际滚动方向一致。比如用触控板垂直滚动，但设了 scroll-snap-type: x mandatory，就等于关掉了捕捉。
- 确保父容器设置了
overflow-y: scroll且子元素总高度 > 容器高度 - 移动端 Safari 要求容器有
-webkit-overflow-scrolling: touch才能启用平滑滚动+捕捉（iOS 15.4+ 已逐步弃用，但旧版本仍需） -
scroll-snap-type: mandatory强制停靠，proximity是“靠近时停”，后者更自然但不保证每次滚动都停
scroll-snap-align 怎么配才对齐到可视区中心？
scroll-snap-align 控制的是「单个子元素」如何与容器对齐，不是全局居中逻辑。想让每个区块滚动后居中显示，得在每个可停靠的子项上设 scroll-snap-align: center，而不是只写在容器上。
注意它只有三个合法值：start、end、center，没有 middle 或 auto。而且它只对块级元素（或 display: block 行为）有效；inline 元素、flex 子项若未设宽高或未触发块格式化上下文，可能被忽略。
立即学习“前端免费学习笔记（深入）”；
- 每个需要停靠的子元素都要单独加
scroll-snap-align: center - 如果子元素是
flex项目，确认其align-self没覆盖默认对齐，且父 flex 容器未设align-items: stretch导致高度塌陷 - 配合
scroll-padding可微调停靠位置（例如避开固定 header），如scroll-padding-top: 60px
为什么 iOS 上滚动卡顿或跳过 snap 点？
iOS WebKit 对 scroll-snap 的实现比桌面 Chrome 更敏感，尤其在快速连续滚动或内容动态加载时。根本原因是：滚动捕捉依赖渲染帧完成后的布局计算，而 iOS 默认会延迟部分 layout 计算以保帧率，导致 snap 时机错乱。
这不是 bug，而是权衡。解决方案不是强行禁用，而是减少干扰因素：
- 避免在滚动中频繁修改子元素尺寸、增删 DOM 或触发布局抖动（如读取
offsetHeight） - 给容器加
will-change: scroll-position（仅限 iOS Safari，Chrome 不需要） - 慎用
scroll-snap-stop: always：它强制每次滚动只停一个点，但会让惯性滚动生硬中断，用户感知就是“卡住” - 测试时关闭 “Reduce Motion” 系统设置，否则 iOS 会降级处理 scroll-snap 行为
兼容性兜底：没有 scroll-snap 怎么模拟类似体验？
IE 和老版 Android Browser 完全不支持 scroll-snap，连 @supports 都检测不了（因为语法解析失败）。不能靠 CSS 特性查询优雅降级，得用 JS 判断支持性：
if ('scrollSnapType' in document.documentElement.style) {
// 原生支持，走 CSS 方案
} else {
// 用 scrollIntoView 或自定义 scroll event + setTimeout 对齐
}
但要注意：JS 模拟无法复现原生的物理滚动惯性，且 touchmove 事件在 iOS 上有 300ms 延迟风险。更稳妥的做法是，只在支持的环境启用 snap，其余降级为普通滚动+清晰分页视觉提示（比如加 active 指示器）。
真正难的不是写对属性，而是理解 scroll-snap 是「声明式约束」，不是「动画控制」。它不接管滚动过程，只告诉浏览器“你该在哪停”。一旦布局或滚动条件不稳，约束就失效——这点比 JS 实现还难调试。
