配了五年地图交互，今天才发现对角线滚动根本不是手势的问题——是浏览器自己锁了轴，Chrome 153 把这件事彻底解了

你做地图、缩略图、360度全景、或者任何需要「对角线拖拽」的交互时，有没有发现用户明明想斜着滚，浏览器却硬要把手势「掰直」？

这个坑踩了五年，今天 CSS 自己会解了。

浏览器在偷偷做的事

当你用触控板或鼠标在地图上斜着划——比如往右下拖——浏览器会做一件事：它看你手势的主轴是垂直还是水平，然后把另一个轴的位移「吃掉」。

比如你手指实际位移了 Y 轴 500px、X 轴 8px。浏览器一看：「哦，主要是想往下滚。」于是 X 轴那 8px 直接被无视，整段手势变成纯垂直滚动。这个机制英文叫 scroll axis-locking，也有人叫它 railing。

大多数时候这是对的。用户想往下翻页，浏览器帮你过滤掉手抖的横向分量，体验更干净。

但做地图、照片缩放、数据表格的时候，这就变成 bug 了。你想对角线拖一张卫星图，浏览器硬是把你的斜线拉成直线。

以前没解法。要么让用户每次都从特定角度开始划（体验很怪），要么自己写 touch/mouse 事件监听去覆盖原生行为（代码一堆，边界情况巨多）。

Chrome 153 把这件事原生化了

CSS Overflow 5 规范里新增了一个属性：scroll-axis-lock。

一行 CSS：

.scroller {
  scroll-axis-lock: none;
}

none 的意思很直接：把浏览器的 axis-locking 关掉，手势怎样，滚动就怎样。

对应的是默认值 auto，保留浏览器原来的行为。

Chrome 153（2026年8月）正式支持了这个属性。只支持了 Chromium。Firefox 和 Safari 还没上。

但这恰恰是它最舒服的地方：渐进增强根本不需要 feature detection。你直接写上去，不支持的浏览器会当它不存在，该干嘛干嘛。不会坏。

如果真要检测：

@supports (scroll-axis-lock: none) {
  .map-container {
    scroll-axis-lock: none;
  }
}

或者 JS：

if (CSS.supports("scroll-axis-lock", "none")) {
  // 支持
}

适合哪些场景

地图类应用 — Google Maps、高德地图这类二维平移界面，对角线滚动是高频操作。

图片/文档缩放 — 用户想斜着把图拖到想看的位置，而不是只能先横再竖。

360度全景/全景图 — 想平滑跟随手势方向，原来的 axis-locking 会让用户觉得「拖不动」。

数据表格/看板 — 超宽表格想斜着扫视，同理。

swipe-to-dismiss — 有些下拉关闭手势如果带轻微横向分量，原来的锁定会干扰。

Bramus 做了个 demo 可以直接对比两种行为：设了 scroll-axis-lock: auto 时，圆形手势会被浏览器「拉方」；设成 none 后，轨迹完全忠实于手指路径。

实际效果什么样

以 Chrome 153 macOS 实测为例：

scroll-axis-lock: auto（默认）—— 圆形手势画出来是方的，浏览器会把你手势里占比小的那一轴吃掉。

scroll-axis-lock: none — 轨迹和手指路径完全一致。

不过要注意：作者在 demo 里也提到，在部分早期实现里，对角线滚动「更抖了」，不像垂直滚动那么顺滑。这不是 property 本身的问题，是浏览器合成器层面还在调优。正式版已经改善很多。

Safari 和 Firefox on macOS 的 axis-locking 行为本来就比 Chrome 更严格。Safari 的圆形手势基本会被拉成方形。Chrome 虽然宽松一点，但也不是完全不管。设成 none 之后，你在 Chrome 上能拿到最完整的控制权。

iOS 上 Safari 原本就不做 axis-locking，所以这个 property 对 iOS Safari 没有意义——反正人家本来就不锁。

下一步

如果你的项目里有地图类交互、数据表格、缩略图组件，现在就可以加一行：

/* 渐进增强，直接写，支持的浏览器生效 */
.map-view,
.zoomable-image,
.data-grid-scroller {
  scroll-axis-lock: none;
}

不需要任何 JS，不需要监听事件，不需要 polyfill。不支持的浏览器会忽略它，用户行为和原来一样。

这个坑从浏览器有这个机制那天就存在了。五年，终于有原生解法了。