winforms/wpf拖放需设allowdrop=true且顺序正确，dragenter中必须设e.effect并校验数据，dragdrop中须安全转换路径并线程同步；高dpi/远程桌面下可能失效。
WinForms 和 WPF 的拖放不是“设个属性就能用”，关键动作漏一步，鼠标光标就一直是禁止符号，根本拖不进来。
WinForms 必须设 AllowDrop = true，且顺序不能错
这个属性默认是 false，不手动打开，DragEnter 和 DragDrop 事件压根不会触发——哪怕你写了事件处理函数也没用。
- 设计器里：选中窗体或目标控件 → 属性面板 → 找到
AllowDrop→ 设为True - 代码里：必须在
InitializeComponent()之后、事件订阅之前设置，比如：this.AllowDrop = true;或listBox1.AllowDrop = true; - 如果拖的是文件，设在窗体或 Panel 级别通常够用；但如果是自定义数据（如
ListViewItem），目标控件本身也得设，父容器不会自动代收
DragEnter 里只检查格式不够，必须设 e.Effect 并验证数据
很多代码只写 if (e.Data.GetDataPresent(DataFormats.FileDrop)) e.Effect = DragDropEffects.Copy;，结果一拖 ZIP 或 .exe 进来就崩，或者松手后没反应。
- 先确认格式存在：
e.Data.GetDataPresent(DataFormats.FileDrop) - 再取数据并判空：
string[] files = e.Data.GetData(DataFormats.FileDrop) as string[];，检查files?.Length > 0 - 路径存在性、扩展名合法性、只读状态等业务逻辑，也得在这一步判断，无效时务必设
e.Effect = DragDropEffects.None - 别用
DragDropEffects.All图省事——它会让 Ctrl/Shift 键行为不可控，建议按需明确写Move、Copy或组合
DragDrop 中取路径必须强制转换为 string[]，别调 ToString()
e.Data.GetData(DataFormats.FileDrop) 返回的是数组对象，不是字符串。常见错误是直接 .ToString()，结果得到 "System.String[]"，路径全丢了。
- 正确写法：
string[] paths = e.Data.GetData(DataFormats.FileDrop) as string[]; - 空值检查不能省：
if (paths == null || paths.Length == 0) return; - 路径含中文、空格、括号完全没问题，.NET 拖放机制已原生解码，拿到的就是可直接传给
File.Exists()或new FileInfo()的本地路径 - 长路径（>260 字符）可能静默失败，建议用
Path.GetFullPath(path)预校验，提前暴露盘符不存在或相对路径拼错等问题
跨进程拖放时 DragDrop 可能不在 UI 线程执行
从资源管理器拖文件进来一般安全，但从另一个 .NET 进程（比如你自己写的辅助工具）拖数据时，DragDrop 事件回调可能在非 UI 线程触发，直接更新控件会抛 InvalidOperationException: “线程间操作无效”。
- 必须检查：
if (InvokeRequired) { Invoke((MethodInvoker)delegate { /* 更新UI */ }); return; } - WPF 虽然事件默认在 UI 线程，但若拖放源启用了 async 或后台线程，同样要留意；WPF 中可用
Dispatcher.Invoke安全调度 - 高 DPI 缩放不一致或远程桌面环境下，拖放事件可能完全不触发——这是 Windows 系统限制，和代码无关，需统一设“高 DPI 感知”缓解
