简介：面向WPF初学者的拖放交互学习包，聚焦在两个ListBox之间实现Drag & Drop，并附带上下按钮调整项顺序、拖拽时边框视觉反馈等细节。压缩包共37个文件，以cs源码和xaml视图为主，辅以项目工程文件、配置文件、exe可执行程序及少量调试资源，整体仅94KB，适合直接打开工程对照学习事件注册、ObservableCollection动态更新与INotifyPropertyChanged绑定机制。已有823人学习下载，适合正在练习WPF数据绑定与自定义控件的开发者。通过工程源码与示例可快速掌握跨列表拖放的完整流程，包括PreviewMouseLeftButtonDown启动拖拽、DragOver与Drop事件处理、集合数据交换及拖动状态下的样式切换，能直接迁移到排序列表、任务管理等实际场景中。
1. WPF ListBox 拖拽：光靠 DragDrop 事件远远不够，核心在于数据搬移与视觉反馈
WPF 里做 ListBox 之间的 drag&drop，很多人第一反应是给控件挂上 Drop 事件，结果拖过去发现没反应，或者数据过去了但源列表没删，再或者拖动时鼠标指针永远显示“禁止”图标。这份资源解决的就是这套完整链路：从鼠标按下时定位 ListBoxItem，到 DoDragDrop 启动拖拽，再到 DragOver 判断目标位置、Drop 落地后完成集合数据搬移，以及拖拽过程中的滚动、插入位置提示等细节。适合已经能写基础 WPF 界面、但对拖拽机制停留在“听说过”阶段的开发者，也适合想把拖拽做规范、可复用的熟手对照边界情况。
2. 先看 WPF 拖拽的底层工作流：GiveFeedback、QueryContinueDrag 与 DragOver 的分工
2.1 从 ListBoxItem 到 DoDragDrop：拖拽从哪里开始
WPF 的拖拽不是从 ListBox 控件本身开始的，而是从鼠标按下的那个视觉元素开始的。常见做法是在 PreviewMouseLeftButtonDown 事件里做一次 VisualTreeHelper.HitTest，向上找父级 ListBoxItem，找不到就直接 return，找到了才启动拖拽。为什么用 Preview 而不是普通 MouseLeftButtonDown？因为 ListBox 本身会处理 MouseLeftButtonDown 来做选中逻辑，普通事件可能被吞掉，Preview 隧道事件能先一步拿到消息。
private void OnPreviewMouseLeftButtonDown(object sender, MouseButtonEventArgs e) { // 拿到鼠标按下的原始命中对象 var hit = e.OriginalSource as DependencyObject; // 向上遍历 VisualTree，找到 ListBoxItem 才说明按在可拖拽行上 var item = FindAncestor<ListBoxItem>(hit); if (item == null) return; // 记录拖拽起点，后面判断是否真的发生了位移 _dragStartPoint = e.GetPosition(null); // 把 ListBoxItem 的 DataContext 作为拖拽数据 _draggedItem = item.DataContext; }这段代码里 FindAncestor 是一个自己写的泛型工具方法，内部用 VisualTreeHelper.GetParent 循环向上找，直到找到类型匹配的祖先元素或者到 VisualTree 根部为止。这里有一个关键的边界：ListBox 默认的 ItemContainer 不一定是 ListBoxItem，如果你改了 ItemContainerStyle 或者用了数据模板虚拟化，命中测试拿到的可能是模板内部的 Border 或 TextBlock，所以必须做祖先查找而不是直接拿 e.Source。_dragStartPoint 用来记录鼠标按下时的屏幕坐标，后面在 MouseMove 里判断拖动距离是否超过系统阈值，避免误触。
启动拖拽的动作不在 MouseDown 里做，而是在 MouseMove 里判断。因为拖拽是一个位移动作，只有鼠标移动了才该启动。判据一般用 SystemParameters.MinimumHorizontalDragDistance 和 MinimumVerticalDragDistance，两个方向都超过才算拖拽开始。这样能有效规避单击选中列表项时误触发拖拽的问题。
private void OnPreviewMouseMove(object sender, MouseEventArgs e) { if (_draggedItem == null) return; // 计算鼠标从按下位置到当前位置的位移 var currentPos = e.GetPosition(null); var diff = _dragStartPoint - currentPos; if (Math.Abs(diff.X) < SystemParameters.MinimumHorizontalDragDistance && Math.Abs(diff.Y) < SystemParameters.MinimumVerticalDragDistance) return; // 构造 DataObject，携带数据与拖拽源标识 var dataObject = new DataObject(typeof(YourDataType), _draggedItem); dataObject.SetData("DragSourceListBox", sourceListBox); // 启动拖拽，DragDropEffects 决定后续鼠标指针的外观 DragDrop.DoDragDrop(sourceListBox, dataObject, DragDropEffects.Move); // 拖拽结束，清理状态 _draggedItem = null; }DataObject 构造时第一个参数是数据格式，第二个参数是实际数据。这里用 typeof(YourDataType) 作为格式名，可以保证只有同类型的 ListBox 之间才能互相拖拽，避免把别的窗口里的数据也拖进来。DragSourceListBox 这个自定义格式里存的是源 ListBox 的引用，Drop 端拿到它就能知道数据从哪来，从而决定是否需要从源集合移除。
DragDrop.DoDragDrop 是一个阻塞方法，它会自己跑一个消息循环，直到拖拽结束才返回。返回值的 DragDropEffects 表示最终执行的效果，Move 代表移动成功，None 代表放弃。DoDragDrop 传入的 effects 参数也不是随便填的：传入 Move 表示允许移动，传入 Copy 则表示允许复制。实际拖拽过程中，用户按 Ctrl 可以切换效果，但如果不允许 Copy，按了也没用。做一个支持拖拽的列表，建议把 Copy 和 Move 都填上，让用户在拖的时候自己选。
2.2 GiveFeedback 与 QueryContinueDrag：拖拽过程中是谁在执行
DoDragDrop 启动后，WPF 进入一个内部的拖拽消息循环。这个循环会持续触发 GiveFeedback 和 QueryContinueDrag 事件，直到用户松开鼠标或者按 Esc 取消。GiveFeedback 的作用是让你有机会改变鼠标指针的外观；QueryContinueDrag 则允许你根据键盘或鼠标状态提前终止拖拽。
很多人的误区是只在 DragOver 里改 e.Effects，想让鼠标指针变成“复制”或“移动”样式，但 DragOver 只在鼠标进入目标控件时触发，而 GiveFeedback 是全局的。也就是说，如果只在 DragOver 里设置 Effects，鼠标在目标区域外时指针永远是默认箭头，只有飞进目标区域才变化，视觉上会很奇怪。规范的写法是在源 ListBox 的 GiveFeedback 里统一设置效果。
private void OnGiveFeedback(object sender, GiveFeedbackEventArgs e) { // 根据 DragDropEffects 手动指定鼠标指针类型 if (e.Effects.HasFlag(DragDropEffects.Move)) Mouse.SetCursor(Cursors.SizeAll); else if (e.Effects.HasFlag(DragDropEffects.Copy)) Mouse.SetCursor(Cursors.Cross); else Mouse.SetCursor(Cursors.Arrow); // 告诉系统我们已经处理了鼠标指针反馈，避免二次覆盖 e.UseDefaultCursors = false; e.Handled = true; }SetCursor 是全局的，拖拽结束后必须恢复默认。常见做法是在 QueryContinueDrag 里监听 Mouse.LeftButtonState，等左键松开时把光标重置。否则会出现拖拽结束但鼠标指针还停留在 SizeAll 状态的玄学问题。QueryContinueDrag 还有一个重要用途是支持 Esc 取消拖拽，默认情况下 WPF 会处理 Esc，但如果你在 Page 或 Window 级别捕获了按键，可能会破坏默认行为，这时需要在 QueryContinueDrag 里手动判断。
private void OnQueryContinueDrag(object sender, QueryContinueDragEventArgs e) { // 检测 Esc 键是否按下，按下则取消拖拽且不执行 Drop if (e.EscapePressed) { e.Action = DragAction.Cancel; return; } // 左键松开时结束拖拽，执行 Drop if (Mouse.LeftButton == MouseButtonState.Released) { e.Action = DragAction.Drop; } }这里的 DragAction 枚举有三个值：Continue、Drop、Cancel。Drop 表示正常结束并触发目标控件的 Drop 事件，Cancel 表示直接放弃且不会触发 Drop。这两个事件的配合逻辑是：QueryContinueDrag 决定拖拽循环何时退出，GiveFeedback 决定退出前鼠标长什么样。理解这条链路后，再去排查“鼠标拖过去了但目标控件没反应”这类问题，思路会清晰很多——先看 DoDragDrop 有没有被启动，再看 Drop 有没有被触发，而不是一上来就怀疑 DataObject 传参有误。
3. 数据搬移：DataObject 格式约定与源目标列表的增删顺序
3.1 用自定义数据格式隔离拖拽来源
DataObject 是拖拽数据的载体，但它的运作机制和很多人想象的不一样。SetData 的时候如果你传的是 System.String，那任何文本框、RichTextBox 甚至浏览器都可能接收你的拖拽数据，这是一件很危险的事情——你可能把 ListBox 里的业务对象拖进一个 TextBox，变成一串 ToString。所以拖拽自定义对象时，第一原则就是用一个自定义类型作为格式键，而不是用字符串或已知基类。
// 定义你自己的业务实体类型 public class OrderItem { public int Id { get; set; } public string OrderNo { get; set; } public decimal Amount { get; set; } } // 拖拽源端：使用 typeof(OrderItem) 作为格式 var dataObject = new DataObject(typeof(OrderItem), selectedOrder); // 目标端：严格限定只有同类型数据才允许落下 if (dataObject.GetDataPresent(typeof(OrderItem))) { var order = dataObject.GetData(typeof(OrderItem)) as OrderItem; // 继续处理搬移 }GetDataPresent 检查格式是否存在，GetData 取出数据。这里有一个容易被忽略的细节：DataObject 的构造函数如果传的是 Type 对象，底层会调用 ToString 得到格式名。所以格式名实际上就是类型全名。如果你在源端写 typeof(OrderItem)，目标端却用 "OrderItem" 字符串去 GetDataPresent，能拿到吗？答案是能，因为字符串对比的是类型全名。但反过来，如果源端 SetData("myformat", data)，目标端用 typeof(OrderItem) 去取，就取不到，因为格式名不匹配。规范做法是两端统一用同一个 Type 作为格式键，既省心又安全。
拖拽源标识的传递也是一个常见需求。两个 ListBox 都订阅了同一个 Drop 事件处理逻辑时，你得知道数据是从哪个列表来的。做法是在 DataObject 里额外 SetData 一个自定义格式存源 ListBox 引用，或者更简单——在业务对象上加一个来源标记属性。我一般倾向于后者，因为 UI 控件引用不应该出现在业务数据里，会让 ViewModel 层被 View 层污染。
3.2 Drop 事件里的集合操作顺序：先删源还是先加目标
Drop 事件里做数据搬移，代码逻辑看起来很简单：从 DataObject 取出数据，加到目标集合，再从源集合移除。但这个先后顺序有讲究，而且不同场景下结论不一样。如果源集合和目标集合是同一个 ObservableCollection，那先删源再插目标等于把数据从原位置拿下来再放进去，会触发两次集合变化通知，UI 会经历先减少一行再增加一行，视觉上有闪烁。反过来先插目标再删源，集合总数会先多后少，也可能造成 ListBox 滚动位置跳变。
最稳妥的做法是和业务场景绑定：如果拖拽是跨列表的，任意顺序都行，因为两个集合各自独立，UI 刷新互不影响。如果是同列表重排序，建议直接操作源集合，用 Move 方法一次性完成，避免多次通知。
private void OnDrop(object sender, DragEventArgs e) { // 只处理自定义类型的数据，其他一律忽略 if (!e.Data.GetDataPresent(typeof(OrderItem))) return; var order = e.Data.GetData(typeof(OrderItem)) as OrderItem; if (order == null) return; // 判断是否拖到了初始来源上方（同列表重排场景） var sourceListBox = e.Data.GetData("DragSource") as ListBox; var targetListBox = sender as ListBox; var sourceVm = sourceListBox.DataContext as OrderListViewModel; var targetVm = targetListBox.DataContext as OrderListViewModel; if (sourceVm == targetVm) { // 同一个列表内部重排：先拿到当前索引，再移动到新位置 var oldIndex = sourceVm.Orders.IndexOf(order); var newIndex = GetDropIndex(e.GetPosition(targetListBox), targetListBox); if (oldIndex != newIndex && newIndex >= 0) { sourceVm.Orders.RemoveAt(oldIndex); // 移除后索引会变化，重新修正 if (newIndex > oldIndex) newIndex--; sourceVm.Orders.Insert(newIndex, order); } } else { // 跨列表拖拽：先加目标集合，再删源集合，保证任何时刻数据不丢失 targetVm.Orders.Add(order); sourceVm.Orders.Remove(order); } e.Handled = true; }跨列表先加后删的顺序有一个额外好处：如果删除源集合时抛出异常（比如数据源只读），目标集合已经加进去了，至少数据还在，不会出现两边都丢的状态。GetDropIndex 是一个辅助方法，根据鼠标在 ListBox 里的 Y 坐标和每个 Item 的实际高度，计算出插入位置的索引。这个计算需要遍历目标 ListBox 的可视化子元素，拿到每个 ListBoxItem 的 ActualHeight 和 RenderTransform，累加比较。如果你的 ListBox 开启了虚拟化，大部分 Item 并没有生成可视元素，这个方法就会返回 -1，需要退化成根据 Item 数量和总高度做估算。
3.3 ObservableCollection 的必要性：为什么拖完界面不动
有一种高频翻车现场：拖拽完成后，用 MessageBox 确认源集合确实少了数据，目标集合确实多了数据，但界面就是不变。这几乎可以断定集合类型用错了——如果源集合是 List 或者数组，绑定它的 ListBox 不会收到任何变更通知。ListBox 只在 ItemSource 重新赋一个新实例时才刷新，而你在拖拽逻辑里是直接对集合做 Add/Remove，界面当然无动于衷。
public class OrderListViewModel { // 必须是 ObservableCollection，而不是 List 或 IEnumerable public ObservableCollection<OrderItem> Orders { get; set; } public OrderListViewModel() { // 初始化时从数据库/接口加载 Orders = new ObservableCollection<OrderItem>(LoadOrders()); } }ObservableCollection 的内部机制是：Add、Remove、Insert、Move 等方法执行时触发 CollectionChanged 事件，绑定了这个集合的 ItemsControl 订阅了这个事件，收到通知后增量更新 UI。List 没有这个事件，所以界面永远停留在初始状态。还有一个细节是 UI 线程问题：拖拽事件都在 UI 线程执行，所以这里不会碰到跨线程访问集合的异常。但如果你把数据搬移逻辑放到 async 方法里，或者用了 Task.Run 去处理，就要小心 ObservableCollection 的线程亲和性——非 UI 线程修改集合会直接抛 NotSupportedException，需要用 Dispatcher.Invoke 或者用线程安全的集合加手动通知。
await Task.Run(() => { var orders = LoadOrdersFromRemote(); // 不能在子线程里直接操作 UI 绑定的 ObservableCollection Dispatcher.Invoke(() => { Orders.Clear(); foreach (var o in orders) Orders.Add(o); }); });4. DragOver 的细节：目标命中测试、插入位置指示与边界滚动
4.1 命中测试的正确姿势：不要用 e.OriginalSource
DragOver 里需要判断鼠标当前悬停在哪个 ListBox 上，以及具体悬停在哪一行，这关系到 Drop 后的插入位置。很多人直接用 e.OriginalSource 或者 e.Source 做类型判断，这在拖拽场景里经常失效。原因在于 DragOver 事件是从鼠标下的元素一路冒泡上来的，e.OriginalSource 是命中的最深层元素，可能是 ListBoxItem 内部的某个 TextBlock，而 e.Source 是你挂事件的那个控件，两者都可能不是列表项容器。
正确的做法是自己重新做一次命中测试，然后用 VisualTreeHelper 向上找 ListBoxItem。
private void OnDragOver(object sender, DragEventArgs e) { var targetListBox = sender as ListBox; if (targetListBox == null) return; // 检查数据类型是否符合 if (!e.Data.GetDataPresent(typeof(OrderItem))) { e.Effects = DragDropEffects.None; e.Handled = true; return; } // 获取鼠标相对于目标 ListBox 的坐标 var pos = e.GetPosition(targetListBox); // 用命中测试找到鼠标下的 UIElement var hit = VisualTreeHelper.HitTest(targetListBox, pos) as DependencyObject; if (hit == null) { e.Effects = DragDropEffects.None; e.Handled = true; return; } // 向上查找 ListBoxItem var item = FindAncestor<ListBoxItem>(hit); if (item != null) { // 悬停在有效项上，允许拖放 e.Effects = (e.KeyStates & DragDropKeyStates.ControlKey) == DragDropKeyStates.ControlKey ? DragDropEffects.Copy : DragDropEffects.Move; } else { e.Effects = DragDropEffects.None; } e.Handled = true; }这里对 Ctrl 键的检测是用 e.KeyStates 位运算，不能直接读 Keyboard.Modifiers，因为拖拽循环内部有自己的键盘状态捕获，外部的静态属性不一定是最新的。DragDropKeyStates 枚举里有 ControlKey、ShiftKey、AltKey、LeftMouseButton 等值，用 HasFlag 判断即可。
4.2 插入位置指示器：给用户一个“能落在哪”的视觉暗示
拖拽过程中如果没有任何位置提示，用户只能靠鼠标指针的图标猜测能不能放、放在哪。做得好的拖拽交互会在目标列表的行与行之间画一条分隔线，告诉用户“松手后数据会插到这里”。实现方案很多，最简单的是在 DragOver 里动态改目标 ListBoxItem 的样式属性，但那样侵入性强，退出拖拽后还要还原，容易留下残留。
更干净的做法是给 ListBox 加一个 Adorner，在 AdornerLayer 上画一条线。Adorner 的好处是它独立于可视化树，不影响 ListBoxItem 的布局，也不用动数据模板。
public class InsertionAdorner : Adorner { private readonly bool _isTopHalf; private readonly Visual _visual; public InsertionAdorner(UIElement adornedElement, bool isTopHalf, Visual visual) : base(adornedElement) { _isTopHalf = isTopHalf; _visual = visual; IsHitTestVisible = false; } protected override void OnRender(DrawingContext drawingContext) { var item = (ListBoxItem)AdornedElement; var rect = new Rect(item.RenderSize); // 画一条 2px 的蓝色指示线，在项的上半部分或下半部分 var y = _isTopHalf ? 0 : rect.Bottom - 2; drawingContext.DrawLine( new Pen(Brushes.DodgerBlue, 2), new Point(0, y), new Point(rect.Right, y)); } }用 Adorner 方式还有一个好处：拖拽结束时只要调 AdornerLayer.GetAdornerLayer 然后 Remove 掉 Adorner 实例，界面就会干净恢复，不用逐个 Item 重置样式。代价是每个 ListBox 需要单独管理一个 Adorner 实例的创建和销毁，代码稍微多一点，但可维护性远高于样式方案。
4.3 边界自动滚动：拖到列表边缘时 ListBox 要跟着滚
列表很长时，用户想把数据拖到最底部，但鼠标不可能飞出货区去触发滚动，因为拖拽循环把鼠标捕获了。WPF 的 ScrollViewer 在拖拽状态下不会自动响应鼠标轮子，但 ScrollViewer 内部有自动滚动逻辑，前提是你要在 DragOver 事件里手动触发。常见做法是拿 ScrollViewer 的 ScrollableHeight 和 VerticalOffset 判断是否到达边界，然后用 ScrollToVerticalOffset 步进滚动。
private void OnDragOverWithAutoScroll(object sender, DragEventArgs e) { var listBox = sender as ListBox; var scrollViewer = FindVisualChild<ScrollViewer>(listBox); if (scrollViewer == null) return; var pos = e.GetPosition(listBox); var scrollMargin = 40; // 距离上下边界多少像素时开始滚动 if (pos.Y < scrollMargin) { // 向上滚动：每次滚 3 个像素，直到顶部为止 if (scrollViewer.VerticalOffset > 0) scrollViewer.ScrollToVerticalOffset(scrollViewer.VerticalOffset - 3); } else if (pos.Y > listBox.ActualHeight - scrollMargin) { // 向下滚动：每次滚 3 个像素，到底为止 if (scrollViewer.VerticalOffset < scrollViewer.ScrollableHeight) scrollViewer.ScrollToVerticalOffset(scrollViewer.VerticalOffset + 3); } }滚动步长 3 像素是一个经验值。步长太大，滚动会一跳一跳地不跟手；太小，滚动速度跟不上鼠标移动速度，用户会以为没反应。EventManager 的拖拽循环大约每 20 毫秒触发一次 DragOver，3 像素每帧相当于每秒 150 像素，足够大多数场景使用。如果还需要更平滑的滚动手感，可以把步长和鼠标距离边界的距离挂钩，越靠近边缘滚得越快，但要注意步长过大会导致滚动 overshoot，列表直接从顶部跳到底部。
5. 避坑与排查：拖拽不生效、数据为 null、界面残留的五类高发问题
5.1 拖拽永远不触发 Drop 事件
现象：鼠标拖到目标 ListBox 上方，指针显示禁止符号，松开鼠标后 Drop 事件完全不触发。目标 ListBox 的 AllowDrop 已经设为 true，DragOver 也写了，但就是没有反应。
原因：DragOver 事件处理函数里设置了 e.Effects = DragDropEffects.None，但没有设 e.Handled = true。事件未被标记为已处理，WPF 的拖拽框架没有收到有效的 Effect 更新，默认按 None 处理，Drop 自然不触发。另一种情况是 DragOver 里把 e.Effects 设置成了 Move，但源端 DoDragDrop 传入的 allowedEffects 里没有 Move。
解决：DragOver 里每次处理完都写 e.Handled = true；DoDragDrop 的 effects 参数至少包含 Move。同时检查 Drop 事件的签名是 DragEventHandler 而不是 RoutedEventHandler，挂错委托类型也会导致事件不触发。
5.2 目标端 GetData 拿到的永远是 null
现象：Drop 事件里 GetDataPresent 返回 true，但 GetData 强制转换后得到 null，或者根本取不到数据。
原因：DataObject 创建时格式名与读取时不一致。典型错误是源端写了 SetData(typeof(OrderItem), item) 和 SetData("DragSourceListBox", listBox)，目标端却用 GetData("OrderItem") 去取业务数据。字符串格式名匹配是区分大小写的，OrderItem 和 orderitem 是两个完全不同的键。另一个隐蔽原因：SetData 时传了 null 值，DataObject 会认为没有数据可存，GetDataPresent 也会返回 false。
解决：源端和目标端统一用 typeof(OrderItem) 作为格式键，不要手写字符串。业务数据不允许为 null，初始化时做空值检查。如果必须在 DataObject 里传多个对象，每个都用自定义的 Type 键，不要复用已有键名。
5.3 拖拽结束但源列表的选中状态错乱
现象：拖拽完成后，源列表原本选中的那一行变成了未选中，或者目标列表新插入的那行没有被选中，再或者整个源列表的选中项变成了 null。
原因：ListBox 的选中状态受 ItemsControl 的默认行为影响。当你把 ListBoxItem 的 DataContext 搬走之后，ListBox 发现数据项消失了，会自动清理选中项。如果源 ListBox 绑定了 SelectedItem，而搬移后这个数据对象已经不在源集合里，SelectedItem 变成 null 是正常现象。但如果你没有在 ViewModel 里处理这个状态变化，UI 会表现出“失魂”的样子。
解决：拖拽结束时，显式处理源 ListBox 的 SelectedItem：跨列表拖拽场景，源 ListBox.SelectedItem = null；同列表重排场景，重新选中搬移后的那条数据。更规范的做法，是在 ViewModel 里暴露 SelectedOrder 属性，在搬移逻辑里显式赋值，而不是依赖控件的默认行为。
5.4 拖拽到 ListBox 空白区域时 Drop 无效果
现象：两个 ListBox 之间拖拽，拖到有数据行的位置能正常放下，但拖到底部空白区域或者顶部空白区域，Drop 触发后数据没有插入到预期位置。
原因：DragOver 里的命中测试只认 ListBoxItem，空白区域没有命中任何 Item，e.Effects 被设成了 None，Drop 事件不触发。但用户把数据拖到空白处，语义上是想追加到列表尾部，这是完全合理的操作，不应被拒绝。
解决：DragOver 里不要只找 ListBoxItem，还要判断鼠标位置是否在 ListBox 的可视区域内。做法是命中测试后先查 ListBoxItem，查不到就判断鼠标 Y 坐标是否超过最后一项的底部位置，超过则允许拖放并把插入索引设置为集合末尾。需要注意虚拟化场景下最后一项的真实位置未必等于 Item 数量乘以估算高度。
// 没有命中 ListBoxItem 时，不代表不能放 var item = FindAncestor<ListBoxItem>(hit); if (item == null) { // 检查鼠标是否落在 ListBox 的空白区域（但仍在可视区内） if (pos.Y >= 0 && pos.Y <= targetListBox.ActualHeight) { e.Effects = DragDropEffects.Move; // 此时插入位置应为集合末尾 } else { e.Effects = DragDropEffects.None; } }5.5 拖拽样式残留：松开鼠标后分隔线没有消失
现象：用 Adorner 做了插入位置指示器，拖拽结束时用 AdornerLayer.Remove 清理，但界面上偶尔还留着一条蓝色线条，或者拖到另一个窗口再回来，指示线还在。
原因：AdornerLayer.Remove 时传入的 Adorner 实例和创建时不是同一个。常见于你在 DragOver 里每次都 new 一个 Adorner，然后 Remove 时传入的是旧实例，AdornerLayer 找不到匹配项，于是旧的残留在线。另一个原因：拖拽取消了（按 Esc），QueryContinueDrag 里触发了 DragAction.Cancel，这时收尾逻辑没执行 Remove。
解决：坚持一个拖拽会话只创建一个 Adorner 实例，会话结束时用同一个实例去 Remove。写一个 try-finally 结构，把 Adorner 清理放到 finally 里，保证无论 Drop 还是 Cancel 都会执行。清理前记得把 Adorner 从 AdornerLayer 里移除，再将其关联的视觉对象置为 null，防止内存泄漏。
6. 拖拽收尾的一个好习惯：把数据搬移从事件里抽出来做料层拦截
做得多了会发现，WPF 拖拽最容易腐坏的地方不是事件逻辑本身，而是把业务搬移逻辑直接写死在 Code-Behind 里。两个 ListBox 的拖拽还好说，当你需要支持三个、四个列表互相拖拽，或者同一个列表里还要区分拖到上半区和下半区的语义时，事件代码会指数级膨胀。我的习惯是写一个泛型的 DragDropBehavior 类，把“命中项、取数据、计算插入索引”这些重复操作封装起来，业务层只暴露一个 MoveItem(from, to, newIndex) 方法。
但比封装更重要的一个细节是拖拽会话的全局状态管理。每一次 DoDragDrop 都应该对应一个唯一的会话 ID，用这个 ID 去关联 DataObject、源 ListBox、拖拽的起始索引和 Adorner 实例。会话结束后统一回收资源。如果你不做这一步，多个 ListBox 共用一套拖拽逻辑时，很容易出现上一个拖拽会话的残留引用被下一个会话误用的情况。
// 用一个会话对象统一管理拖拽状态 public class DragSession { public Guid Id { get; } = Guid.NewGuid(); public ListBox SourceListBox { get; set; } public object Data { get; set; } public int SourceIndex { get; set; } public InsertionAdorner Adorner { get; set; } public void CleanUp() { if (Adorner != null) { var layer = AdornerLayer.GetAdornerLayer(Adorner.AdornedElement); layer?.Remove(Adorner); Adorner = null; } Data = null; } }从那以后，我每次写 ListBox 拖拽都强制自己走一遍这件事：先定义好数据格式的类型键，再写 Dragover 的效果判定，最后才碰 Drop 里的集合搬移。尤其是会话对象创建后，CleanUp 一定要放在 finally 或拖拽结束回调里执行，这个习惯帮我省掉了大量“不知什么时候多了一条线”“为什么拖完源列表还残留高亮”的排查时间。希望帮到你。
本文还有配套的精品资源，点击获取
