移动端scroll事件不触发手势识别是因浏览器优化：原生滚动拦截touch事件；需设touch-action: pan-y并passive: false，touchstart预判方向再preventDefault，禁用scroll-behavior平滑滚动，及时清理ref事件监听。
移动端 scroll 事件默认不触发手势识别
浏览器原生滚动（如 overflow: auto 或 touch-action: auto）会主动拦截 touchstart/touchmove，导致手势库（如 Hammer.js、useSwipe）收不到事件。这不是 bug，而是浏览器为保障滚动流畅性做的优化。
常见现象：手指划动容器没反应，或只在边缘触发，中间区域完全无响应。
- 检查目标元素是否设置了
touch-action: none—— 这是启用自定义手势的前提（但会禁用原生滚动） - 若需“滚动 + 手势”共存，改用
touch-action: pan-y（允许竖向滚动，同时保留横向 touch 事件）或pan-x -
passive: false必须显式传给addEventListener('touchmove', ..., { passive: false })，否则 Chrome 会静默忽略preventDefault()
preventDefault() 调用时机不对会导致滚动卡顿
在 touchmove 中直接调用 preventDefault() 会强制关闭原生滚动，但若判断逻辑滞后（比如等滑动距离 > 10px 再阻止），中间那几十毫秒的原生滚动已启动，造成“先跳一下再接管”的撕裂感。
- 推荐在
touchstart阶段就根据初始方向预判：记录startX/startY，在touchmove开头立刻比对Math.abs(dx) > Math.abs(dy) - 只在确认是手势意图时（如横向滑动）才调用
preventDefault()；否则放行，让浏览器继续滚动 - 避免在
touchmove里做重计算（如 DOM 查询、复杂条件），容易掉帧
CSS scroll-behavior: smooth 和手势冲突
启用平滑滚动后，scrollTo() 会变成异步动画，而手势识别通常依赖同步的滚动位置变化来计算速度/加速度。结果就是手势结束后的惯性滚动被平滑动画覆盖，手感变粘滞。
立即学习“前端免费学习笔记（深入）”；
- 手势驱动的滚动建议关闭
scroll-behavior，改用element.scrollTo({ top, behavior: 'auto' }) - 若必须保留平滑效果，可在手势结束（
touchend）后延迟 100ms 再启用，避开关键帧干扰 - 注意 Safari 对
scroll-behavior的兼容性更弱，iOS 15+ 才稳定支持
React/Vue 中 ref 绑定 touch 事件容易丢失上下文
用 useRef 或 ref 拿到 DOM 元素后，直接在组件内写 el.addEventListener，但组件重渲染时未清理旧监听器，或闭包捕获了过期的 state，导致手势回调里的 currentX 始终是初始值。
- 务必在
useEffect（React）或onBeforeUnmount（Vue）中调用removeEventListener - 手势中依赖的变量（如上一次位置、是否激活）建议用
useRef存储，而非useState，避免触发重渲染打断连续交互 - 不要把整个手势逻辑塞进事件回调里，拆出独立函数并用
useCallback缓存，防止每次渲染都生成新函数导致重复绑定
手势和滚动的边界从来不是非此即彼——真正难的是在 touch-action 的取舍、preventDefault 的时机、以及框架生命周期之间找到那个刚好不卡、不飘、不丢事件的临界点。多数问题其实出在“想同时控制太多”，而不是技术本身不支持。
