winforms拖拽必须设置目标控件的allowdrop=true，否则系统不发送拖拽消息；dragenter中需校验dataformats.filedrop并设effect，dragdrop中应安全转换string[]、处理编码与长路径。
WinForms 中启用拖拽必须设置 AllowDrop
不设这个属性，哪怕写了所有事件处理，文件一拖进来就直接弹窗拒绝——Windows 根本不会把拖拽消息发给控件。它不是可选配置，是硬性开关。
常见错误：只在 Form_Load 里注册 DragEnter 和 DragDrop，但忘了在设计器或构造函数里写 this.AllowDrop = true;，或者只给 Panel 设了，没给真正想接收文件的 TextBox 或 ListView 单独设。
-
AllowDrop必须对**目标控件本身**设置，父容器设了不等于子控件自动继承 - 如果用自定义控件，需重写
OnDragEnter并确保基类调用正常 - WPF 不用这个属性，WinForms 场景下漏掉它，100% 拖拽失效
DragEnter 里别只写 e.Effect = DragDropEffects.Copy
很多示例代码直接无条件设为 Copy，结果用户拖着文件夹、快捷方式甚至网页链接过来，程序也傻乎乎接受——然后 DragDrop 里取 e.Data.GetData(DataFormats.FileDrop) 就返回 null，崩得毫无预兆。
正确做法是在 DragEnter 里先校验数据格式和内容类型：
- 检查
e.Data.GetDataPresent(DataFormats.FileDrop)是否为true - 若需限定后缀，可提前用
e.Data.GetData(DataFormats.FileDrop) as string[]取出路径数组，再遍历判断扩展名（注意：此时只是预览，不能做耗时操作） - 仅当确认可处理时才设
e.Effect = DragDropEffects.Copy，否则设None，系统会自动显示禁止图标
DragDrop 事件里文件路径可能含空格和非 ASCII 字符
直接用 File.OpenRead(path) 或 new StreamReader(path) 很容易抛 FileNotFoundException 或乱码——不是路径错了，是没正确处理编码或路径转义。
真实场景中，用户从微信、钉钉、桌面中文路径拖入，string[] 里的路径本身就是完整、合法的 .NET 字符串，无需解码、无需替换斜杠：
- 直接用
File.Exists(path)判断，不要自己拼接或正则清洗 - 读文本文件时，明确指定编码，比如
File.ReadAllText(path, Encoding.UTF8)，避免默认 ANSI 导致中文乱码 - 若要支持长路径（>260 字符），确保项目启用了
longPathAware（.NET Core 3.1+ 默认开启，.NET Framework 需改 app.config）
拖拽多个文件时，DataFormats.FileDrop 返回的是 string[] 不是单个路径
新手常犯错误：把 e.Data.GetData(DataFormats.FileDrop) 强转成 string，结果运行时报 InvalidCastException。这个数据格式固定返回字符串数组，哪怕只拖了一个文件。
安全取法只有这一种：
var files = e.Data.GetData(DataFormats.FileDrop) as string[];
if (files?.Length > 0)
{
foreach (var path in files)
{
// 处理每个 path
}
}
另外注意：files 里路径末尾不含反斜杠，也不带引号，就是干净的全路径字符串；如果是文件夹，它也会出现在数组里，需要自行用 Directory.Exists() 区分。
拖拽体验是否“顺”，关键不在特效多炫，而在边界情况有没有兜住——比如用户拖进一个损坏的快捷方式、拖了 500 个文件、中途取消、或者拖到禁用状态的控件上。这些地方没判空、没设 Effect、没用异步加载，交互就会突然卡住或报错。做一次就要想到用户怎么“不按套路”来。
