HTML5中wheel事件是原生DOM事件，无需额外API；需用addEventListener监听，调用preventDefault阻止默认行为，deltaX/deltaY方向与CSS一致，推荐requestAnimationFrame节流处理。

HTML5 中没有叫 “wheel API” 的独立接口，wheel 事件是原生 DOM 事件，直接用 addEventListener 监听即可，不需要额外引入或初始化。

监听 wheel 事件的基本写法

现代浏览器（Chrome 31+、Firefox 17+、Edge、Safari 13.1+）都支持标准的 wheel 事件，它比已废弃的 mousewheel 和 DOMMouseScroll 更统一、更可靠。

关键点：

• wheel 是冒泡事件，可绑定在任意可滚动或有内容的元素上（如 、）
• 不要用 onwheel 属性式写法（兼容性差且难管理），一律用 addEventListener
• 必须调用 event.preventDefault() 才能阻止默认滚动行为（比如页面上下滑动）

document.addEventListener('wheel', (e) => {
  console.log('deltaX:', e.deltaX, 'deltaY:', e.deltaY, 'deltaZ:', e.deltaZ);
  console.log('deltaMode:', e.deltaMode); // 0=像素, 1=行, 2=页
  if (e.ctrlKey) {
    e.preventDefault(); // 仅在 Ctrl 按下时禁用缩放/滚动
  }
});

deltaX / deltaY 的单位和方向含义

滚轮数据不是“向上/向下”的布尔值，而是带方向和粒度的数值，单位由 deltaMode 决定：

• deltaMode === 0：单位是 像素（最常见，尤其触控板或高精度鼠标）
• deltaMode === 1：单位是 行（传统机械滚轮，每格约 3 行）
• deltaMode === 2：单位是 页（极少触发，如按空格键式翻页）

方向约定统一：
– deltaY > 0 表示向下滚动（内容向上移）
– deltaX > 0 表示向右滚动（内容向左移）
注意：这与 CSS transform: translateY() 的正向一致，但和用户直觉“往上推滚轮 = 往上走”相反。

防抖与节流为何几乎总是必需的

滚轮事件触发极快（尤其 macOS 触控板），连续滚动可能一秒内发出 30+ 次事件。不做控制会导致：

• UI 卡顿（如频繁重绘 canvas 或修改 transform）
• 误判方向（短时间内 deltaY 正负跳变）
• 与 scroll 事件冲突（比如同时监听两者却没协调）

推荐用 requestAnimationFrame 节流，而非定时器防抖：

let pending = false;
document.addEventListener('wheel', (e) => {
  if (pending) return;
  pending = true;
  requestAnimationFrame(() => {
    handleWheel(e);
    pending = false;
  });
});

function handleWheel(e) {
  if (e.deltaY > 0) console.log('向下滚动');
  else console.log('向上滚动');
}

跨平台行为差异与兼容性陷阱

看似简单的滚轮，在实际中容易踩坑：

• macOS 触控板默认开启 自然滚动：物理“向上推”对应 deltaY （即逻辑“向上”），但用户设置可反转，代码不能硬编码方向语义
• Firefox 在 iframe 中监听 wheel 时，若 iframe 无焦点，事件可能不触发（需确保 tabindex="0" 或主动聚焦）
• 移动端 Safari 不触发 wheel（iOS 无传统滚轮），应改用 touchmove + 速度估算，或依赖 scroll 事件
• 某些游戏手柄或绘图板会模拟 wheel，但 deltaMode 可能异常（如恒为 0），建议始终检查 Math.abs(e.deltaY) > 1 再响应

真正难的不是绑定事件，而是判断“用户此刻想干什么”——是微调、翻页、缩放，还是只是不小心蹭到了触控板。业务逻辑越复杂，越要从 deltaY 值的累积、速率、按键状态（shiftKey、ctrlKey）综合判断，而不是只看单次事件。