scroll-snap-stop: always 仅 Safari ≥15.4 在触控板/触摸屏滑动时真正生效；Chrome/Edge ≤120、Firefox 全系静默忽略；旧版浏览器直接丢弃该属性，需结合 @supports 和 JS 校准实现兼容。
scroll-snap-stop: always 在部分浏览器（尤其是旧版 Chromium 和 Safari 15.4 之前）根本不会生效，不是你写错了，而是浏览器压根没实现这个属性。
查浏览器是否真支持 scroll-snap-stop
别信 CanIUse 上“支持”的模糊描述——它只表示该属性被解析、不报错，不代表行为一致。实际支持分三层：
-
scroll-snap-stop: always被识别且触发强制停顿：仅 Safari ≥ 15.4 + macOS/iOS 触控板/触摸屏滑动时有效 -
scroll-snap-stop: always被识别但静默忽略（降级为normal）：Chrome ≤ 120、Edge ≤ 120、Firefox 全系（截至 2026 年 5 月仍无计划支持） - 属性名直接被 CSS 解析器丢弃：极老版本 Safari / Chrome（normal 都不生效
验证方法很简单，在控制台运行：
getComputedStyle(document.querySelector('.item')).scrollSnapStop
如果返回 "" 或 "normal"（即使你写了 always），说明当前浏览器不支持该值。
立即学习“前端免费学习笔记（深入）”；
为什么 Safari 要求触控板或触摸屏才能触发
scroll-snap-stop 的设计初衷就是约束“惯性滚动”行为，而惯性滚动只存在于触控输入场景（鼠标滚轮、键盘方向键、element.scrollTo() 都不触发）。所以：
- 在 Safari 上用鼠标滚轮滚动，
scroll-snap-stop: always完全无效，会退回到scroll-snap-type: mandatory的基础吸附逻辑 - 哪怕你在 MacBook 上用触控板，也必须是“快速滑动”（带惯性），慢速拖拽不算
- 桌面 Safari 开发者工具里模拟的“Mobile view”不等于真实触控环境，真机测试不可替代
Chromium 系列如何兜底实现“强制停顿”效果
既然原生不支持，就得用 JS 补足。关键不是监听 scroll（太频繁），而是等滚动真正结束：
- 监听
scrollend事件（Chrome 112+、Edge 112+ 原生支持；Safari 16.4+ 支持；Firefox 仍不支持） - 计算当前
scrollLeft距离最近.item左边界的位置差，误差 > ±10px 就主动校准：element.scrollTo({ left: targetLeft, behavior: 'smooth' }) - 注意：不要对每个
.item都设scroll-snap-align: start，否则scrollend触发时机不稳定；统一用scroll-snap-align: center更可靠
这段逻辑必须和 @supports (scroll-snap-stop: always) 结合使用，避免在已支持的 Safari 上重复执行 JS 校准，造成双重重叠动画。
Autoprefixer 对 scroll-snap-stop 完全无能为力
前缀补全解决不了语义缺失问题：
-
scroll-snap-stop没有 WebKit 前缀变体（-webkit-scroll-snap-stop是无效的） - Autoprefixer 只处理已知兼容性模式的属性，而该属性在 Blink/Gecko 中属于“未实现”，不是“需加前缀”
- 强行加前缀反而可能让 CSS 解析失败，导致整个规则块被忽略
真正要做的，是在构建流程中通过 @supports 条件注入增强样式，并用 JS 检测 scrollend 可用性来决定是否挂载校准逻辑——这比依赖任何工具链更可控。
最易被忽略的一点：即使所有条件都满足，scroll-snap-stop: always 也只影响“快速滑动后的自动停顿”，不影响用户手动拖拽或调用 scrollTo。如果你的交互依赖精确滚动定位，必须自己管理 scroll 位置状态，不能指望 CSS 属性替你兜底。
