必须设置allowdrop=true并订阅dragenter事件，在dragenter中检查e.data.getdatapresent(dataformats.filedrop)且设e.effect=dragdropeffects.copy，否则系统拒绝拖入。
如何让 WinForm 窗口接收拖入的文件
默认情况下，WinForm 窗口不响应文件拖拽——必须手动启用 AllowDrop 属性，否则 DragEnter 和 DragDrop 事件根本不会触发。
这是最常被忽略的第一步，尤其在设计器里拖控件后容易忘记设这个属性。
-
this.AllowDrop = true;必须在窗体（或目标控件）初始化后设置，比如InitializeComponent()之后 - 如果拖拽目标是某个
PictureBox或Panel，则需对那个控件单独设AllowDrop = true，窗体设了没用 - 仅设
AllowDrop不够，还必须订阅至少一个拖拽事件（通常是DragEnter），否则系统会拒绝拖入（光标显示为禁止符号）
DragEnter 里该做什么判断
DragEnter 是拖拽悬停时的“准入检查”，不是用来取文件路径的地方。它的核心任务是告诉系统：“我接受什么类型的数据”。
常见错误是直接在 DragEnter 里调用 e.Data.GetData(DataFormats.FileDrop) ——这会提前消耗数据，导致后续 DragDrop 中取不到。
- 只检查
e.Data.GetDataPresent(DataFormats.FileDrop)，返回true即可放行 - 若只接受 .txt 文件，可加一层扩展名预判：
var files = (string[])e.Data.GetData(DataFormats.FileDrop); if (files.Length > 0 && Path.GetExtension(files[0]).Equals(".txt", StringComparison.OrdinalIgnoreCase)) - 不要在
DragEnter里做耗时操作（如 IO、网络请求），它会被高频触发，卡顿明显
DragDrop 里安全读取文件路径
DragDrop 是唯一该取实际文件路径的地方。注意：Data.GetData(DataFormats.FileDrop) 返回的是 string[]，不是单个字符串。
很多人用 (string)e.Data.GetData(...) 强转，结果抛出 InvalidCastException。
- 务必用
string[] files = (string[])e.Data.GetData(DataFormats.FileDrop); - 检查
files是否为null或空数组，避免 NullReferenceException - 路径含中文或空格完全没问题，.NET 返回的就是完整、已解码的本地路径，无需额外处理
- 若需异步加载大文件，别在
DragDrop事件里直接调用File.ReadAllBytes，建议用Task.Run或await避免界面冻结
为什么拖进来了却没反应？几个硬坑
现象是拖文件到窗口，光标变圆圈又变禁止符号，松手没反应——大概率不是逻辑错，而是环境或权限问题。
- Visual Studio 调试时以管理员身份运行，而资源管理器是非管理员，Windows 会阻止跨权限拖拽（UAC 隔离），关掉 VS 管理员模式或用普通方式启动程序即可
- 目标路径含 OneDrive / SharePoint 同步文件夹时，某些版本 Windows 会返回临时重定向路径，
File.Exists可能返回false，应优先用try/catch+File.OpenRead实测可读性 - 拖入快捷方式（.lnk）文件时，
DataFormats.FileDrop默认不包含其真实路径，需用Shell32解析，不属于基础拖拽范畴
拖拽本身不复杂，但权限模型和数据传递时机这两个点，几乎覆盖了 90% 的“明明代码写了却不动”的情况。
