商品详情页顶部的图片轮播是一个典型场景：容器设置了 scroll-snap-type: x mandatory，每张卡片设置 scroll-snap-align: start。用户用触控板快速一划，期望停在下一张图，实际却常常越过两三张才停下。手动对齐已经生效，问题出在滚动惯性阶段——对齐只约束了滚动结束时的位置，没有约束滚动过程中能否跨过中间的 snap 点。
scroll-snap-stop 正是为这个缺口设计的属性。它挂在子元素（snap 区域）上，而不是滚动容器上，用来声明“滚动经过这个元素时，是否允许直接越过”。理解它的关键在于把一次滚动拆成手指/触控板输入阶段和随后的惯性衰减阶段，并看清 snap 点在这两个阶段分别扮演什么角色。
惯性滚动为什么会跳过 snap 点
触控板和触摸屏的滚动输入通常带速度。用户抬手后，浏览器不会立刻停在当前位移，而是按输入速度继续推进一段距离，这段运动在工程上常称为惯性滚动或 fling。滚动的最终落点由速度、摩擦衰减和平台实现共同决定，用户无法精确控制。
scroll-snap-type 的 mandatory 或 proximity 值约束的是滚动操作完成后的静止位置：容器必须（或在接近时）停在某个合法 snap 点上。它不限制滚动过程中经过多少个 snap 点。因此当惯性距离足够长，滚动会连续穿过多个 snap 区域，最后才在某个点上对齐。用户看到的是一次滑动跳过多张卡片。
MDN 的示例说明也指出，这种差异在带触控板的设备上更容易观察：一次挥动中，normal 会穿过所有页面，而 always 会停在第二页。规范把 normal 定义为“可以越过可能的 snap 位置”，把 always 定义为“不得越过某个可能的 snap 位置，并且必须吸附到该元素的第一个 snap 位置”。
scroll-snap-stop 与 scroll-snap-type 的分工
这两个属性常被混为一谈，但它们作用于滚动的不同环节。
| 属性 | 作用对象 | 约束的时机 | 决定什么 |
|---|---|---|---|
scroll-snap-type | 滚动容器 | 滚动操作结束后 | 容器是否必须吸附、沿哪个轴吸附、吸附强度是 mandatory 还是 proximity |
scroll-snap-align | 子元素 | 吸附落点计算 | 子元素的哪个边缘（start/center/end）与 snapport 对齐 |
scroll-snap-stop | 子元素 | 滚动进行中 | 惯性滚动能否越过该元素的 snap 位置 |
scroll-snap-stop 的初始值是 normal，即默认允许越过。它的取值只有两个关键字，计算值按指定值处理，动画类型是离散的，不会插值。这个属性适用于所有元素，但不继承。
一个容易忽略的点是：always 的作用对象是设置了该属性的那个子元素。如果只给偶数项设置 always，那么滚动在偶数项的 snap 位置会被拦截，奇数项仍可被越过。MDN 的示例正是用 always-stop-odd 和 always-stop-even 演示了这种逐项控制。这带来一个实用能力——可以只让某些“关键页”强制停留，其余页允许快速掠过。
一次滑动在浏览器内部经历了什么
把轮播场景展开，可以看到从输入到静止的完整链路。
flowchart TD
A[用户滑动触控板或触摸屏] --> B[浏览器产生滚动位移与速度]
B --> C[进入惯性滚动阶段]
C --> D{下一个 snap 点是否设置 always}
D -->|否 normal| E[越过该 snap 点继续滚动]
E --> F{惯性是否耗尽}
F -->|否| D
F -->|是| G[按 scroll-snap-type 吸附到最近合法点]
D -->|是 always| H[在该元素首个 snap 位置拦截]
H --> I[滚动停止并吸附到该点]
关键转折点在判断节点：always 在滚动过程中就介入，把“能否继续前进”这一决策提前到惯性阶段；normal 则把决策推迟到惯性耗尽之后，由 scroll-snap-type 统一收尾。
这里需要区分标准保证与实现细节。规范定义了 always 的语义是“不得越过”，但惯性如何衰减、拦截发生在哪一帧、触控板与触摸屏的手势识别差异，属于浏览器实现细节，不同引擎和平台可能表现不同。MDN 把该特性标记为 Baseline Widely available，并说明其自 2022 年 7 月起在主流浏览器中可用，但具体手感仍需在目标设备上实测。
轮播与分页列表中的实际效果
在图片轮播里，把每张卡片设为 scroll-snap-stop: always，快速一划只会前进一张。用户需要再次滑动才能看到下一张。对于“每张图都需要被看到”的场景，比如商品主图、引导页、步骤说明，这种强制停留符合用户意图：用户不会因为一次手滑而错过中间内容。
代价同样明显。当卡片数量多、用户只想快速浏览时，always 会把一次滑动拆成多次滑动，操作成本上升。分页列表场景更能说明这个权衡：如果每页是一屏内容，always 让翻页变成严格的一页一次，接近原生分页控件的体验；但如果每项只是列表中的一行，强制停留会让滚动变得迟滞，用户会觉得“划不动”。
Tailwind CSS 把这类用法封装成 snap-always 工具类，并建议与 snap-mandatory 配合使用，官方示例正是图片网格。这从工程约定层面印证了适用场景：内容以整屏或整卡为单位、且需要逐项确认时，才值得开启强制停留。
性能影响与常见失败模式
scroll-snap-stop 本身不引入额外的布局或绘制工作。它改变的是滚动的停止时机，而不是渲染管线。真正需要关注的是它带来的间接成本。
一个常见失败模式是强制停留与懒加载冲突。轮播每张卡片是独立图片，若只在卡片进入视口时才加载，always 让用户每次只前进一张，图片加载被分散到多次交互中。用户停在某张图时，如果该图尚未加载完成，会看到空白或占位。缓解方式是预加载相邻卡片，而不是依赖滚动触发。
另一个失败模式是与 scroll-behavior: smooth 叠加。程序化滚动（如点击指示点跳转）会走平滑动画，而 always 针对的是用户输入的惯性滚动。两者叠加时，程序化跳转通常不受 always 限制，但用户手动滚动仍会被拦截，行为不一致会让用户困惑。需要区分“用户滑动”和“脚本跳转”两条路径。
还有嵌套滚动容器的情况。内层容器设置了 snap 和 always，外层页面也在滚动。触摸手势先被哪一层消费取决于 touch-action、overscroll-behavior 和平台手势识别。若内层拦截了本应传给外层的滚动，用户会感觉页面“卡住”。这类问题无法只靠 scroll-snap-stop 解决，需要配合 overscroll-behavior 明确边界。
可观测信号方面，滚动交互问题很难靠单一指标定位。工程上通常关注：滚动是否出现长任务、scroll 事件处理是否阻塞主线程、图片是否在停留时仍未就绪。诊断时先确认 scroll-snap-type 和 scroll-snap-stop 的实际计算值，再在目标设备上复现一次挥动手势，观察停在第几项。
与替代方案的比较和适用边界
强制停留不是唯一做法，几种方案各有取舍。
| 方案 | 加载/运行时成本 | 交互延迟 | 实现复杂度 | 适用场景 |
|---|---|---|---|---|
scroll-snap-stop: always | 无额外渲染成本 | 每次滑动前进一项，延迟感增加 | 低，纯 CSS | 逐项确认的轮播、引导页、分页 |
仅用 scroll-snap-type: mandatory | 无额外渲染成本 | 滑动可越过多项 | 低 | 快速浏览的图片流 |
JS 监听 scroll 并手动定位 | 主线程回调成本，可能触发强制同步布局 | 取决于实现，易抖动 | 高 | 需要自定义动画或复杂规则 |
| 分页按钮/指示点 | 无滚动成本 | 精确但需额外点击 | 中 | 少量固定页 |
always 的收益是让滚动结果可预测，代价是牺牲快速浏览的自由度。它不改变可访问性语义，也不影响键盘滚动和屏幕阅读器，但会改变触控和触控板用户的节奏。在只支持鼠标滚轮的桌面环境里，滚轮通常按固定步进滚动，always 的差异不如触控板明显。
判断是否使用，可以问三个问题：内容是否必须逐项被看到？用户是否经常需要快速跳过？目标设备是否以触控板或触摸屏为主？三个问题都指向“逐项确认”时，always 合适；只要有一个指向“快速浏览”，就应保持 normal，或只对关键项单独设置 always。
需要提醒的是，规范将 scroll-snap-stop 列为 at-risk 特性，这意味着工作组认为它可能难以被及时、互操作地实现。MDN 的 Baseline 标记说明它已在主流浏览器可用，但在依赖它之前，仍应在目标浏览器和平台上验证实际行为，并为不支持的情况保留可用的降级——例如提供分页按钮，让用户在不依赖强制停留时也能逐项浏览。