WinForms窗体需设AllowDrop=true并处理DragEnter（检查DataFormats.FileDrop且设e.Effect）和DragDrop事件；WPF需设AllowDrop=true并处理DragOver（设e.Effects）和Drop事件；拖入路径为string[]，须强制转换并判空，长路径需系统级支持。
WinForms 窗体怎么开启拖拽支持
默认情况下，WinForms 窗体不响应拖放事件，必须手动启用。关键就两步：AllowDrop 设为 true，再订阅 DragEnter 和 DragDrop 事件。
常见错误是只设了 AllowDrop = true 却没处理 DragEnter，结果拖文件到窗体时鼠标显示“禁止”图标，根本拖不进来。
-
AllowDrop必须在窗体或控件初始化后设置（比如InitializeComponent()之后），不能晚于事件订阅 -
DragEnter里必须检查e.Data.GetDataPresent(DataFormats.FileDrop)，并设e.Effect = DragDropEffects.Copy，否则系统认为不接受该拖放操作 - 如果拖入的是目录（而非文件），
DataFormats.FileDrop仍能识别，但路径末尾不带\，需自行判断是否存在子项
C# 如何从 DragDrop 事件中提取文件路径
DragDrop 事件的 e.Data.GetData(DataFormats.FileDrop) 返回的是 string[]，不是单个字符串，别直接转 ToString() —— 那会得到数组类型名，不是路径。
典型误用：e.Data.GetData(DataFormats.FileDrop).ToString() → 输出 System.String[]，路径全丢了。
- 务必强制转换：
var files = e.Data.GetData(DataFormats.FileDrop) as string[] - 空值检查不能少，某些第三方工具拖入可能返回
null - 路径含中文或空格完全没问题，.NET 原生支持，不用额外解码或转义
- 若需区分文件/文件夹，可用
File.GetAttributes(path)检查是否含FileAttributes.Directory
WPF 中实现拖拽获取文件路径有什么不同
WPF 不用设 AllowDrop 属性，但必须显式在 XAML 或代码中启用：比如 myWindow.AllowDrop = true，否则事件根本不触发。
事件名和参数结构也不同：DragOver 替代 DragEnter，Drop 替代 DragDrop，且 e.Data.GetData(DataFormats.FileDrop) 在 WPF 中返回的是 string[]，和 WinForms 一致。
- WPF 的
DragOver里必须设e.Effects = DragDropEffects.Copy，否则拖入时鼠标仍是禁用状态 - WPF 支持更细粒度的数据格式（如
Text、Bitmap），但拖文件时基本只用DataFormats.FileDrop - 若绑定到
ItemsControl类控件，注意线程问题：拖放事件在 UI 线程触发，但路径处理逻辑若涉及 IO，建议用Task.Run包裹，避免卡界面
拖入路径含特殊字符或长路径时要注意什么
.NET 本身对长路径（>260 字符）支持有限，尤其在旧版 Windows 上，默认受限。即使路径能取到，后续用 File.Exists() 或 Directory.GetFiles() 可能返回 false 或抛 PathTooLongException。
不是拖拽逻辑的问题，而是后续 IO 调用的兼容性瓶颈。
- Windows 10 1607+ 可通过组策略或应用清单启用长路径支持，但需用户环境配合，代码层无法绕过
- 路径含
:、|、?等非法字符？实际不会出现——系统级拖放已过滤掉非法路径，GetData返回的一定是合法路径字符串 - 若需校验路径有效性，优先用
Path.IsPathRooted()+File.GetAttributes()，比File.Exists()更轻量且不触发磁盘访问
拖拽本身很简单，难的是边界情况：空数组、权限不足、长路径、跨进程剪贴板失效。别假设“用户拖进来的一定是个能读的文件”。
