会，而且拖慢得非常明显——可滚动区域会劫持touch事件，iOS Safari中touchmove常不冒泡，导致手势识别失效；应通过touch-action精准控制并结合位移阈值判定来兼顾滚动与手势。
会，而且拖慢得非常明显——只要页面里存在可滚动区域（比如 overflow: auto 或 overflow-y: scroll），原生的 touchstart/touchmove 手势事件就会被浏览器的滚动行为劫持或延迟触发，尤其在 iOS Safari 上，touchmove 甚至可能完全不冒泡到目标元素。
为什么滑动区域会干扰手势识别
浏览器对 touch 事件有默认的“滚动优先”策略：一旦判定用户意图是滚动（哪怕只是轻微偏移），就会立即接管事件流，阻止默认行为被取消、事件被吞掉、后续 touchend 无法触发——这直接导致自定义手势（如长按、双指缩放、滑动手势识别）失效或响应迟钝。
- iOS Safari 默认开启
touch-action: pan-y（仅允许竖向滚动），对横向滑动手势直接屏蔽touchmove - Android Chrome 在快速滑动时会批量合并
touchmove事件，丢失中间坐标点，影响速度/方向判断 - 父容器设置了
overflow: scroll，子元素即使调用event.preventDefault()，也可能因事件捕获阶段过晚而无效
如何让滑动和手势识别共存
核心思路不是“禁用滚动”，而是“精准控制 touch-action 和事件拦截时机”。关键在于区分「用户想滚动」还是「用户想执行手势」，并在第一帧就做决策。
- 给需要手势识别的容器显式设置
touch-action: none（彻底关闭浏览器默认手势），再手动实现滚动逻辑（如用scrollTop+requestAnimationFrame） - 若只需支持局部手势（如轮播图），用
touch-action: pan-y（禁横向滚动）+preventDefault()在touchmove中只拦截横向位移，保留竖向滚动能力 - 避免在
touchstart就调用preventDefault()，改用「阈值判定」：记录起始点，在touchmove中计算位移差，仅当Math.abs(dx) > 10且Math.abs(dy) 时才拦截，兼顾误触容错 - 监听
touchcancel事件——iOS 在滚动开始瞬间会触发它，这是手势中断的明确信号，需重置状态机
常见误操作与性能坑
很多方案看似能用，但上线后在低端机或微信 WebView 里崩得悄无声息。
立即学习“前端免费学习笔记（深入）”；
- 在
touchmove里频繁读取scrollTop或getBoundingClientRect()，触发强制同步布局（layout thrashing），手势卡顿明显 - 用
setTimeout延迟判断手势类型（如“等 300ms 看是否是点击还是长按”），导致touchend已触发，状态却还没更新 - 给整个
body设置touch-action: none，结果页面彻底不能滚动，用户骂声一片 - 依赖
passive: false的addEventListener，但在 Chrome 56+ 中未声明{ passive: false }会导致preventDefault()失效且无报错
真正难的不是写出手势逻辑，而是在滚动流畅性、手势准确率、兼容性三者之间做实时权衡——比如 iOS 上一个 touch-action: manipulation 可能让你省掉 80% 的代码，但 Android 4.4 完全不支持；又比如微信内置浏览器对 touch-action 的解析比标准更激进，稍不注意就全盘失效。
