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