wheel事件中passive与捕获/冒泡正交，passive决定是否阻塞滚动，捕获/冒泡决定事件处理顺序；应仅在具体容器上用{passive:true}监听，禁用preventDefault()以保障流畅度。
在 wheel 滚轮事件中，passive 与事件捕获/冒泡是正交机制，不直接联动，但配合得当能显著提升滚动流畅度。关键在于：passive 解决的是“浏览器是否等待 JS 执行完再滚动”，而捕获/冒泡解决的是“事件在 DOM 树中从哪一层开始处理”。两者需各司其职、不互相干扰。
wheel 事件默认走冒泡阶段，passive 作用独立于传播方向
wheel 是可冒泡事件，默认在冒泡阶段触发。无论你用 addEventListener('wheel', handler, false)（冒泡）还是 true（捕获），只要配置了 { passive: true }，浏览器就承诺“这个 handler 绝不会调用 preventDefault()”，从而跳过同步等待，立即执行原生滚动。
- 捕获阶段监听 wheel 并设 passive：可以提前响应，但实际极少需要——wheel 通常只需在目标容器上处理
- 冒泡阶段监听并设 passive：最常见，比如给 body 或滚动区父容器加监听，同时保证不阻塞
- passive 的生效与 capture 选项无关，只取决于是否声明了
passive: true且 handler 中真没调preventDefault()
为什么 wheel 一般不用 .capture + passive？
捕获阶段监听 wheel 容易引发意料外行为：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 若在 document 或 body 捕获层阻止了 wheel 默认行为（哪怕只是想做节流），就会全局禁掉滚动，用户根本无法上下翻页
- wheel 的语义目标通常是某个具体容器（如表格、时间轴 div），应绑定在该元素上，而非靠捕获“截胡”
- 被动模式下，捕获层 handler 若误触发 preventDefault()，控制台会报错且 passive 失效，得不偿失
真正提升 wheel 流畅度的 passive 实践
对 wheel 事件启用 passive，核心是明确两点：目标容器、用途限定。
立即学习“Java免费学习笔记（深入）”；
- 只在需要横向滚动或自定义滚动逻辑的 具体 div 容器 上监听 wheel，例如：
<div class="timeline" @wheel.passive="handleWheel"> - handler 内仅读取
e.deltaY或e.deltaX，计算后更新scrollLeft或scrollTop，绝不调用e.preventDefault() - 若需阻止默认纵向滚动（比如实现纯横向滚动），应在非 passive 模式下显式调用
preventDefault()，此时必须配{ passive: false }，否则报错 - 避免在 document/body 级别监听 wheel 并设 passive——既没必要，又可能掩盖子容器自己的 passive 配置
和 scroll/touchmove 不同：wheel 的 passive 兼容性更稳
wheel 事件本身在所有现代浏览器中都支持 passive 配置，不像 touchmove 在旧 Android WebView 中有兼容问题。但要注意：
- PC 鼠标 wheel 的
deltaX值多数为 0，依赖deltaY映射横向滚动时，需加防抖或阈值判断，避免微动误触发 - macOS 触控板的 wheel 事件会同时带较大
deltaX和deltaY，适合原生横向滚动，passive 可直接启用 - 不要给 wheel 加
.prevent修饰符（Vue）或e.preventDefault()（原生）再配 passive，二者逻辑冲突
