Chrome 151 Beta 新增 WheelEvent.momentum：滚动惯性事件能区分了

用过Mac或者高精度触控板的开发者应该都碰到过这类常见细节：手指已经抬离触控板，页面还会持续收到一串 wheel 事件。以前前端开发者只能靠时间间隔、速度衰减、自定义阈值这些经验规则，去推断当前事件是不是来自惯性滚动。现在Chrome 151 Beta 把 WheelEvent.momentum 放进测试范围，开发者可以直接判断滚动事件是否由滚动惯性触发。它算不上大版本的重磅特性，但对长列表、画布缩放、横向滚动和自定义滚动容器这类场景，实用价值非常高。

这次变化解决的是哪类滚动误判

在 Mac 触控板、部分高精度触控板和惯性滚轮上，用户快速滑动松手后，浏览器会继续派发后续滚动事件。用户主观上只是完成了一次轻划操作，但页面代码收到的是一串连续的 wheel。如果应用把每个事件都当成“用户还在主动操作”，就容易出现几类典型问题：

• 画布缩放停不下来，用户松手后缩放还继续变化。
• 横向滚动面板抢走页面滚动，惯性阶段也被当成主动切换。
• 虚拟列表为了跟随滚动频繁计算，手感变得飘。
• 自定义快捷键组合里，Ctrl + wheel 和普通滚动边界更难判断。

WheelEvent.momentum 的使用边界

从能力定义上看，momentum 是给 WheelEvent 增加一个布尔判断字段。它回答的是“这个事件是不是惯性阶段产生的”，不是“滚动速度是多少”，也不是“用户是否想取消默认滚动”。所以它更像一个来源标记，应该和已有的 deltaX、deltaY、ctrlKey、滚动容器状态一起用。

最小示例：先识别，再决定要不要响应

更稳妥的接法不是看到新属性就全量重写滚动逻辑，而是在关键交互里加一层判断。下面这个例子只演示思路：普通滚动继续走原逻辑，惯性阶段可以选择减弱、忽略，或者只更新轻量状态。

const canvas = document.querySelector('.design-canvas');

canvas.addEventListener('wheel', (event) => {
  const hasMomentum = 'momentum' in event;
  const isMomentum = hasMomentum && event.momentum === true;

  if (isMomentum) {
    // 惯性阶段只做轻量处理，避免缩放继续放大。
    updateScrollHint(event.deltaY);
    return;
  }

  if (event.ctrlKey) {
    event.preventDefault();
    zoomCanvas(event.deltaY);
    return;
  }

  panCanvas(event.deltaX, event.deltaY);
}, { passive: false });

这段代码里最关键的是 'momentum' in event。新属性还处在逐步进入浏览器的阶段，直接读取也许不会报错，但缺少特性检测会让团队误以为所有浏览器都能给出同样语义的判断结果。

兼容处理不要直接改线上滚动逻辑

这类浏览器特性最容易带来一个误会：浏览器支持了，业务就可以马上全量依赖。实际项目里，滚动交互通常已经堆了不少边界判断，尤其是在线编辑器、图表平台、低代码画布、表格组件、图片浏览器。更安全的路线是先把它作为增强信号接入，而不是替代旧逻辑。

• 先在实验开关或灰度页面里记录 momentum 出现比例。
• 保留原来的时间阈值或速度衰减判断，作为不支持浏览器的降级方案。
• 不要在惯性事件里做重计算，尤其是布局测量、批量 DOM 更新和复杂图表重绘。
• 对触控板、鼠标滚轮、外接高精度设备分别做一次手感回归。

对开发团队的实际影响

如果你的页面只是普通文档滚动，短期内不用专门改。浏览器默认滚动本来就会处理惯性，应用层不一定需要关心。

真正应该关注的是那些“接管滚动”的页面：设计工具、看板、横向时间轴、地图、数据大屏、在线文档编辑器。它们经常把 wheel 事件变成缩放、平移、吸附切换或动画驱动。对这类页面来说，知道事件来自主动滑动还是惯性阶段，能砍掉很多靠经验猜测的冗余代码。

常见问题

WheelEvent.momentum 会影响页面默认滚动吗？

不会直接改变默认滚动行为。它更像事件上的一个标记，告诉代码当前事件是否属于惯性阶段。是否阻止默认滚动，仍然由业务逻辑决定。

现在可以在生产环境直接依赖它吗？

不建议直接依赖。可以先做特性检测，把它当作增强信号；不支持时继续走原来的降级判断。

它能替代节流和防抖吗？

不能。momentum 解决的是事件来源判断，节流和防抖解决的是调用频率控制。虚拟列表和画布类页面通常两个都需要。

哪些页面最值得先试？

优先看接管滚动的复杂交互，比如画布缩放、横向滚动列表、图表平移、滚动驱动动画。普通文章页、详情页一般不需要立刻处理。

小结

WheelEvent.momentum 的新闻点不大，但它补上了前端滚动事件里一个长期靠经验猜的缺口。对普通页面，它可以先放着；对滚动交互很重的 Web 应用，值得尽早加上特性检测、采集真实设备表现，再决定是否把惯性阶段单独处理。