拖拽交互实战：从原生API到复杂场景的完整实现方案

拖拽这事儿，我试过三种方案，最后只用一种

最近在搞一个移动端的组件库，里面有个卡片拖拽排序的功能。说起来简单，但真做起来才发现，移动端的拖拽比桌面端麻烦多了——既要处理 touch 事件，又要防滚动冲突，还得兼顾性能。折腾了几天，我对比了三种主流方案：原生 touch 事件、Pointer Events、以及第三方库（比如 SortableJS）。今天就来聊聊我的实战感受，不讲理论，只说踩过的坑和最后怎么选的。

谁更灵活？谁更省事？

先说结论：如果你要高度定制，比如自定义拖拽反馈、限制区域、或者和其他手势联动，原生 touch 事件是唯一选择。但如果你只是想快速实现一个列表排序，那直接上第三方库，省时省力。

我一开始图快，直接用了 SortableJS，结果发现它在移动端的 touch 支持其实挺粗糙的，尤其在 iOS 上偶尔会卡顿，而且一旦你要加点“非标准”交互（比如拖拽时放大元素、或者拖出容器时变透明），就得 hack 它的内部逻辑，反而更麻烦。

后来我咬牙重写，用原生 touch 事件搞了一套。虽然代码多点，但完全可控，后面加新功能也顺手。至于 Pointer Events？听起来很美好，一套代码通吃鼠标和触屏，但现实是——移动端 Safari 对它的支持还是有点问题，尤其在低端机上，延迟明显，我亲测在 iPhone SE 第二代上体验不如直接用 touchstart/touchmove。

核心代码就这几行（但坑不少）

下面是我现在用的最小可行拖拽逻辑，基于 touch 事件。关键点我都注释了：

let isDragging = false;
let startX, startY;
let translateX = 0, translateY = 0;

const element = document.querySelector('.draggable');

element.addEventListener('touchstart', (e) => {
  // 防止页面滚动
  e.preventDefault();
  
  const touch = e.touches[0];
  startX = touch.clientX - translateX;
  startY = touch.clientY - translateY;
  isDragging = true;
  
  // 加个高亮样式，提升反馈
  element.classList.add('dragging');
}, { passive: false }); // 注意这里 passive 必须设为 false，否则 preventDefault 无效

element.addEventListener('touchmove', (e) => {
  if (!isDragging) return;
  
  const touch = e.touches[0];
  translateX = touch.clientX - startX;
  translateY = touch.clientY - startY;
  
  // 用 transform 更新位置，性能好
  element.style.transform = translate(${translateX}px, ${translateY}px);
});

element.addEventListener('touchend', () => {
  isDragging = false;
  element.classList.remove('dragging');
  // 这里可以加回弹动画或者 snap 到某个位置
});

这段代码看起来简单，但我踩过好几次坑：

• passive: false 必须加：不然 e.preventDefault() 在 Chrome 和 Safari 里会被忽略，导致页面跟着一起滚动，用户体验极差。
• 别用 left/top 改位置：会触发 layout 回流，卡顿。一定要用 transform，GPU 加速，丝滑。
• touchend 之后记得清理状态：否则如果用户快速滑动后松手，可能因为 touchcancel 没处理而导致元素卡在半空。

另外，如果你要做列表排序，光有这个还不够，还得计算目标位置、交换 DOM 节点、处理边界。这部分逻辑其实挺啰嗦的，但好处是你可以完全控制动画节奏和交互细节。

又踩坑了，touchmove 滚动失效

有一次我在一个可滚动的容器里放拖拽卡片，结果一拖就整个页面往上滚。查了半天才发现，是因为没在 touchstart 里调 preventDefault()，或者调了但没设 passive: false。Safari 特别严格，Chrome 有时候还能蒙混过关，但 Safari 直接无视。

解决方法除了上面说的 passive: false，还可以在 CSS 里加一句：

.draggable {
  touch-action: none; /* 禁用浏览器默认手势 */
}

这行代码能提前告诉浏览器：“这个元素的手势我来处理，你别管”。实测有效，而且比 JS 里 preventDefault 更早生效，减少闪烁。

我的选型逻辑

现在我基本固定了套路：

• 简单交互、一次性需求：直接上 SortableJS 或 react-dnd（如果是 React 项目）。虽然不够完美，但两天就能上线，老板开心。
• 需要精细控制、长期维护的组件：自己写 touch 事件逻辑。虽然前期多花半天，但后期改需求不抓狂。
• 跨平台桌面+移动端共用：考虑 Pointer Events，但必须做好降级。我会先检测 'pointerdown' in window，如果不支持就 fallback 到 mouse + touch 两套监听。

至于性能？实测在中高端机上，原生 touch 和第三方库差距不大。但在低端 Android 机上，第三方库因为封装层多，偶尔会掉帧。而自己写的代码，可以精准优化，比如只在 move 时更新 transform，end 时才触发重排。

还有一点：如果你的拖拽元素很多（比如几十个可拖卡片），一定要用 事件委托，别给每个元素绑监听。不然内存和性能都扛不住。

最后一点碎碎念

其实拖拽这东西，没有银弹。我见过有人用 Hammer.js，结果引入一个 10KB 的库就为了一个 drag 功能，纯属过度设计。也有人死磕原生，结果写了 200 行代码，其实 80% 都是边界处理，最后还不如用库省心。

我的建议是：先明确需求复杂度。如果只是“能拖就行”，别造轮子；如果产品说“拖的时候要有粒子特效+震动反馈+路径预测”，那只能自己上了。

以上是我踩坑后的总结，希望对你有帮助。有更优的实现方式欢迎评论区交流，比如你在实际项目中怎么处理拖拽和滚动冲突的？我也想学学。