在 Flutter 生态里实现拖动排序，大体上有三条路可以走。我结合当时的业务需求，把它们放到一起做个硬核对比：

1.1 方案 A：官方 ReorderableListView or ReorderableSliverList

这是官方封装好的快捷组件，开箱即用。

评估维度	实际使用表现
接入成本	极低，只要实现 onReorder 回调处理数据变更就行。
拖动手势	内置长按拖拽，手势是死板固定的，很难做深度自定义。
让位动画	系统内置自动撑开，不需要开发者操心。
跨源拖拽能力	完全不支持。只能在同一个列表内部自娱自乐。
预览样式自定义	限制极大，拖拽时悬浮的那张卡片很难脱离原 Item 的样式。
滚动联动	自带边缘自动滚动，基础场景完全够用。

适用场景：极简的纯内部排序列表。我们项目里一些简单的配置页也是直接用它。

1.2 方案 B：第三方开源库

比如 reorderables、drag_and_drop_lists 等。

• 优点：介于官方组件与原生 API 之间，帮你省去了不少算坐标的基础代码。
• 缺点：属于“半吊子”魔改。一旦遇到动画细节、边界碰撞等魔鬼细节，只能去改人家的源码，后期的维护成本和魔改心智负担极高。

1.3 方案 C：底层原生 Draggable + DragTarget 手写

这是 Flutter 拖拽最底层的核心能力。虽然要自己搭框架，但也意味着没有任何限制，也是我最终选用的终极方案。

评估维度	实际使用表现
接入成本	偏高。动画、位置计算、边缘自动滚动全都要自己手写。
拖动手势	完全自由。单击、长按、甚至绑定特定图标拖拽都能实现。
让位动画	全权自主控制，时长、贝塞尔曲线、占位样式随意定制。
跨源拖拽能力	完美支持。不同页面、不同容器之间可以自由传递数据。
预览样式自定义	无任何限制，拖拽悬浮出来的卡片想做成什么样都行。
滚动联动	逻辑自控。完美适配弹窗内拖拽、局部局部列表滚动。

适用场景：复杂的拖拽业务（如低代码画布、大屏配置）。虽然前期费手，但灵活性、扩展性和用户体验直接拉满。

1.4 一句话选型标准

• 单纯列表内排个序 ➡️ 别折腾，直接用官方 ReorderableListView。

• 要改点样式，需求不复杂 ➡️ 选个成熟的第三方库。

• 内部排序 + 外部拖拽新增 + 精细占位动画 ➡️ **别犹豫，必选原生 Draggable + DragTarget**。

---

2 为什么我坚持自己手写原生方案？

先看一下我们项目的实际业务场景：仪表盘组件自定义设置页。

这里面并存着两套拖拽流：

• 列表内已有的组件，长按可以上下拖动换位。
• 屏幕底部有一个“组件库”弹窗，用户可以从里面抓一个新组件，直接塞进主列表的任意位置。
• 拖动过程中，手指滑到哪，列表对应的缝隙就要带动画地撑开，明确告诉用户松手后会插在哪里。

这种双重拖拽流联动 + 动态预测的场景，官方组件是绝对搞不定的。

2.1 我的组件结构设计

为了让一套 UI 完美承载两套业务逻辑，我采用了“外层接收、内层拖拽”的双层嵌套设计：

• 外层：自定义的 DwListRowDragTarget（负责接收别人）。
• 内层：LongPressDraggable（负责发起自身的拖拽）。

同时，用两类不同的数据结构来做逻辑分流：

• 内部排序数据：DashboardWidgetReorderDragData（带上原索引、组件 ID）。
• 外部新增数据：DashboardCarouselWidgetKind（组件类型枚举）。

2.2 这套自主方案优点有哪些？

2.2.1 泛型统一接收，靠类型路由分流

我直接把接收容器定义为 DragTarget<Object>，不再严格限制泛型。不管是内部组件还是外部组件投递过来，我直接用 is 关键字做类型判断。这样一来，插入位置的计算逻辑和占位动画就能完美复用，代码精简了一大半。

2.2.2 预览样式完全解耦

产品要求拖拽起来的悬浮卡片必须有专属的高亮样式，不能和列表里的原生条目长得一模一样。借助 Draggable 的 feedback 属性，我顺手就撸了一个精美的专属预览 UI。同时配置 childWhenDragging，在拖起时把原地原条目隐藏或变透明，视觉上非常干净。

2.2.3 用 AnimatedSize 实现丝滑让位

抛弃了系统自带的那种生硬闪现，我全局用 AnimatedSize 来驱动空位占位和条目收缩。动画时长设个 220ms，配合 Curves.easeInOutCubic 曲线。当手指划过某行，一个精致的“数据落点提示条”就像抽屉一样优雅地滑开，视觉引导极其自然。

2.2.4 绝招：拖拽中线位置补偿

这是开发过程中最容易踩的暗坑。原生拖拽回调给你的 details.offset 是悬浮预览卡片的左上角坐标，并不是你手指按压的位置！如果直接拿这个坐标去算位置，你会发现手指都滑到下一行了，列表才迟迟做出反应。

我的解法是：手动加上卡片高度的一半。把判定基准点强行从“顶边”修正到“中线”，占位提示条瞬间就像粘在手指上一样实时跟随，彻底告别延迟和跳动。

2.2.5 动画层与数据层彻底解耦

千万别在拖拽移动的 onMove 过程中去高频修改你的 List<Data> 真实数据源，否则界面会闪烁、错乱到你怀疑人生。
正确思路是：状态驱动 UI，松手再改数据。
在页面级别定义临时变量（比如 _insertIndex），拖拽时仅改变这个临时变量来控制动画和占位条的显示；只有当用户真正松手触发 onAccept 时，才去修改数据源并 setState。

---

3 核心业务编码实现

3.1 底部添加面板：拖拽发起端

组件库面板里的每个条目，用 LongPressDraggable 包裹。

LongPressDraggable<DashboardCarouselWidgetKind>(
  // 绑定外部拖拽的唯一标识数据
  data: itemKind,
  // 自由定制拖拽时的悬浮预览 UI
  feedback: buildDragPreviewCard(itemKind),
  // 拖拽开始：给个震动反馈，体验拉满
  onDragStarted: () {
    HapticFeedback.heavyImpact();
    pageController.onExternalDragStart(itemKind);
  },
  // 实时监听拖拽坐标
  onDragUpdate: (dragDetails) {
    // 检查手指是否移出了底部弹窗区域，移出则触发弹窗收起动画
    checkDragLeaveSheet(dragDetails.globalPosition);
    pageController.onExternalDragMove(dragDetails);
  },
  onDragEnd: (_) => pageController.onExternalDragEnd(),
  child: buildSheetItemCard(),
)

3.2 列表单行：拖拽接收端（核心控制中枢）

每一行 Item 的外层都套上这个 DragTarget，处理复杂的碰撞判定。

DragTarget<Object>(
  // 过滤不合法的拖拽
  onWillAcceptWithDetails: (details) {
    final dragData = details.data;
    // 外部组件：如果主列表已经有了，就不允许重复添加
    if (dragData is DashboardCarouselWidgetKind) {
      return !widget.existWidgetList.contains(dragData);
    }
    // 内部排序数据：直接放行
    if (dragData is DashboardWidgetReorderDragData) return true;
    return false;
  },
  // 手指在当前行上方划过时的核心算法
  onMove: (details) {
    final renderBox = context.findRenderObject() as RenderBox;
    // 将全局坐标转化为当前组件内的局部坐标
    final localOffset = renderBox.globalToLocal(details.offset);
    
    // 【核心点】中线高度补偿：消除左上角坐标引起的判定滞后
    double fixOffset = localOffset.dy + widget.dragViewHeight / 2;
    
    // 判定手指偏向当前行的上半部分还是下半部分
    int targetIndex = fixOffset < renderBox.size.height / 2 
        ? widget.itemIndex 
        : widget.itemIndex + 1;
        
    // 驱动临时状态，让占位条亮起来
    widget.onChangeDragInsertIndex(targetIndex);
  },
  // 尘埃落定，用户松手
  onAcceptWithDetails: (details) {