WinForms控件拖拽起点是DoDragDrop方法而非鼠标事件本身；必须在MouseDown或MouseUp中调用它才能触发拖拽生命周期，否则DragEnter等事件不会触发，且AllowDrop=true为硬性前提。
WinForms 中控件拖拽的起点是
，不是鼠标事件本身
很多人卡在“明明写了
，却拖不起来”，根本原因是没调用
—— 它才是触发整个拖拽生命周期的唯一入口。Windows 消息循环只在你显式调用它时才进入拖拽模式，否则所有
/
都不会触发。
常见错误现象：
从不被调用；鼠标变成禁止符号（圆圈斜杠）；松手后无任何反应。
必须在
或
（非
）中调用
，否则可能被系统忽略
传入的数据对象不能为
，哪怕只是占位：比如
、
或
第二个参数（
）建议先写
，别一上来就用
，否则跨进程或跨应用时容易因权限/格式协商失败而静默失败
和
的区别：一个管“能不能进”，一个管“能不能停”
只触发一次，用于判断目标控件是否接受该拖拽数据；
持续触发（每几十毫秒一次），用于动态反馈位置、高亮区域或禁用特定区域。
使用场景：实现“仅允许拖到面板内，但面板上某个按钮区域不可放”——
设为
，
里根据
判断是否悬停在按钮上，是则设
。
两个事件里都必须设置
，否则目标控件认为“不支持”，后续
不会触发
不要在
里做耗时操作（如 IO、复杂计算），它频繁触发，会导致拖拽卡顿甚至系统降级为“无动画拖拽”
如果目标控件是自定义绘制的（比如继承
并重写
），记得调用
，否则基类逻辑（如光标切换）可能丢失
WPF 和 WinForms 的拖拽不是一回事，混用
会失效
WinForms 中
是硬性开关，缺了它，所有拖拽事件都不注册；WPF 中
只是 XAML 声明，背后依赖
等路由事件，且默认不启用——两者底层消息机制完全不同。
C知道
CSDN推出的一款AI技术问答工具
下载
错误现象：WPF 控件设置了
，也写了事件处理，但
就是不触发。
WPF 必须确保拖拽源调用了
（注意命名空间是
，不是 WinForms 的
）
WPF 目标控件若嵌套在
或
下，可能被事件路由截断，需检查
是否被意外设为
WinForms 控件嵌在 WPF 的
中时，拖拽无法穿透——这是设计限制，不是 bug。想交互就得用纯 WinForms 或纯 WPF 方案
拖拽过程中获取真实坐标，别信
返回的是屏幕坐标，而
或
事件里的
是相对于事件目标控件左上角的客户端坐标。直接混用会导致定位偏移，尤其在 DPI 缩放或多显示器环境下更明显。
性能影响：反复调用
在
中属于低效操作，每次都会触发窗口消息查询。
优先用事件参数自带的
和
，它们已转换好，零开销
如果真需要全局坐标（比如拖拽时显示浮动提示窗），用
（WinForms）或
（WPF），比
更可靠
DPI 感知应用里，记得在
中声明
，否则
可能返回缩放前的坐标
拖拽的真正复杂点不在“怎么开始”，而在“怎么判断此刻该不该接受、该用什么效果、坐标是否可信”。这些细节藏在事件参数和上下文里，而不是文档标题里。
DoDragDropMouseDownDoDragDropDragEnterDragOverDragEnterMouseDownMouseUpMouseMoveDoDragDropnullthisnew object()"dummy"DragDropEffectsDragDropEffects.MoveAllDragEnterDragOverDragEnterDragOverDragEnterMoveDragOvere.X/e.Ye.Effect = DragDropEffects.Nonee.EffectDragDropDragOverPanelOnPaintbase.OnDragOver(e)AllowDropControl.AllowDrop = trueAllowDrop="True"UIElement.DragEnterAllowDrop="True"DragEnterDragDrop.DoDragDropSystem.Windows.DragDropSystem.Windows.FormsScrollViewerAdornerLayere.HandledtrueWindowsFormsHostCursor.PositionCursor.PositionDragOverDragDrope.X/e.YPointToClient(Cursor.Position)DragOvere.Xe.YControl.MousePositionMouse.GetPosition(null)Cursor.Positionapp.manifesthighDpiAwarePointToClient