必须显式传{passive:true}的事件是touchstart、touchmove和scroll，因它们默认可取消且高频触发，不设会导致滚动卡顿；错用preventdefault会报错，需特性检测兼容性并合理fallback。
加 passive: true 能显著缓解移动端滚动卡顿，但只对 touchstart、touchmove、scroll 有效；错用或混用会直接报错或失效。
哪些事件必须显式传 { passive: true }
浏览器仅对默认可取消（cancelable === true）且高频触发的事件做“等待判定”，其中最典型的是：
-
touchstart：哪怕空函数也会触发等待机制，不设passive: true就可能掉帧 -
touchmove：每秒触发数十次，未声明 passive 时 JS 执行和滚动默认行为串行，极易卡顿 -
scroll：尤其在overflow: auto的容器内，不加 passive 会导致滚动延迟明显
注意：wheel 事件不支持 passive，PC 端滚轮无此优化路径；click、input 等低频事件加了也无效。
怎么写才不会报错 “Unable to preventDefault inside passive event listener”
这个错误只有一种原因：监听器里调用了 e.preventDefault()，但注册时却写了 { passive: true }。浏览器发现矛盾，直接忽略 preventDefault() 并抛警告。
- 如果逻辑未来可能加下拉刷新或手势缩放，现在就别设
passive: true - 若仅部分区域需拦截（如弹窗顶部下拉区），只在那里用
{ passive: false }，其余区域保持true - 动态判断是否可阻止：
if (e.cancelable) e.preventDefault()，但前提是注册时没写passive: true
别试图在 @touchmove.passive 模板语法里再写 .prevent——Vue 会直接拒绝编译或运行时报错。
如何安全地做特性检测和 fallback
不能靠 UA 判断是否支持 passive，因为 iOS Safari 11.1+ 和 Chrome 51+ 都已支持，但旧版 WebView 行为不一。唯一可靠方式是特性检测：
const supportsPassive = 'passive' in addEventListener;
封装注册函数时，按需 fallback：
function addScrollListener(el, handler) {
if (supportsPassive) {
el.addEventListener('scroll', handler, { passive: true });
} else {
el.addEventListener('scroll', handler);
}
}
注意：removeEventListener 时无需传 passive 选项，对象参数只在添加时起作用。
容易被忽略的兼容性与副作用
passive: true 在主流浏览器中已稳定支持（Chrome 51+、Firefox 53+、Safari 11.1+、Edge 79+），但有两个隐性坑：
- 某些 Android WebView（尤其 4.x 系列）虽识别
passive字段，却不真正启用优化，仍会等待 JS 执行 - 若监听器里有同步读取布局信息（如
el.offsetTop），即使加了passive，也可能触发重排阻塞主线程，此时需配合requestAnimationFrame或getBoundingClientRect()
真正影响性能的从来不只是事件注册方式，而是回调里干了什么——passive 只是打开并行执行的门，门后还得走轻量路径。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
