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是冒泡事件，可绑定在任意可滚动或有内容的元素上（如<div>、<code>） - 不要用
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）综合判断，而不是只看单次事件。
