原生 touch 事件足以胜任多数滑动场景，如轮播图、横向滚动等；优先使用 touchstart/touchmove/touchend，配合 touch-action 控制拦截权，避免盲目引入手势库。
滑动事件用 touchstart/touchmove/touchend 就够了，别急着上手势库
原生触摸事件在绝大多数滑动场景下完全能胜任，比如轮播图切换、列表横向滚动、抽屉菜单展开。浏览器对这组事件的支持非常稳定，iOS 和 Android 主流版本均无兼容性问题。关键不是“能不能做”，而是“要不要绕远路”——很多项目一上来就集成 Hammer.js 或 interact.js，结果只是监听个左滑右滑，反而引入了额外的包体积和事件冲突风险。
实操建议：
- 用
touchstart记录起始clientX，touchmove实时计算位移差，touchend判断是否达到触发阈值（比如 30px） - 务必在
touchmove中调用event.preventDefault()，否则 iOS 会触发页面回弹或缩放 - 避免在
touchmove里做重绘操作，把位移逻辑交给requestAnimationFrame节流 - 如果只做简单滑动，不需要识别“长按”“双指缩放”等复合手势，原生事件更轻、更可控
PointerEvent 比 TouchEvent 更通用，但要注意 Safari 的兼容边界
PointerEvent 是 W3C 推荐的统一输入抽象层，它能把鼠标、触屏、手写笔的操作归到同一套事件流里。对需要同时支持桌面拖拽和手机滑动的组件（比如画布工具、时间轴拖动条），它比分别写两套逻辑干净得多。
但 Safari 直到 iOS 13.4 才完整支持 pointermove 的持续触发（之前存在中断或延迟），所以如果你的用户群包含大量 iOS 12/13 旧设备，得加降级：
立即学习“前端免费学习笔记（深入）”；
- 先检测
'onpointerdown' in window，不支持则 fallback 到touch+mouse双事件监听 - 注意
pointerdown在 Safari 中可能比touchstart晚触发几毫秒，涉及快速连击的场景要预留缓冲 -
getCoalescedEvents()可以拿到高频率采样的指针轨迹，在绘画类应用里很有用，但 Chrome 和 Firefox 支持度尚可，Safari 当前不支持
手势库不是银弹：用 Hammer.js 前先确认你真需要它识别的那些动作
Hammer.js 确实封装了 pan、swipe、pinch、rotate 等复杂识别逻辑，但它也带来几个硬伤：
- 默认会阻止原生滚动行为（
preventDefault: true），导致容器内文字无法选中、textarea失去焦点，必须手动配置recognizeWith或改写requireFailure - 它把所有触摸点统一处理，遇到多指操作（比如三指下滑返回）容易误判，尤其在 iOS 系统级手势活跃时
- 最新版
Hammer.js已停止维护，社区转向更轻量的@egjs/hammerjs或纯函数式方案如use-gesture（React 场景） - 如果只是做“滑动切换”，用
swipe识别器反而不如自己算deltaX精准——它内置了速度和方向过滤，有时左滑慢一点就不触发
滑动与手势关联的核心其实是“事件拦截权”的归属问题
真正卡住多数人的不是技术选型，而是谁该响应、谁该让路。比如一个轮播图嵌在可滚动的 div 里，手指横向滑动时，是轮播图切换，还是父容器横向滚动？这取决于 touch-action CSS 属性的设置：
-
touch-action: pan-x允许浏览器接管水平滚动，轮播图需监听touchmove并自己计算位移，不能阻止默认行为 -
touch-action: none把所有触摸控制权交给你，此时必须自行实现滚动惯性、边界回弹，否则体验僵硬 -
touch-action: pan-y是最常用折中——禁掉垂直方向的原生滚动，保留水平方向给轮播，但要注意某些安卓 WebView 对pan-y解析异常，需配合event.preventDefault()
这个属性一旦设错，手势库和原生事件都会失效或打架，调试时优先检查它。
滑动逻辑越靠近 DOM 层，越容易被系统手势、浏览器优化、第三方 SDK（比如微信内置浏览器的下拉刷新）干扰；想稳，就得明确每一层的拦截边界，而不是堆工具。
