WinForms中DragDrop事件无法获取文件路径，主要因未设置AllowDrop=true且未在DragEnter中设置e.Effect；需先用GetDataPresent判断再取string[]路径，并注意UAC、快捷方式、高DPI等兼容问题。
WinForms里DragDrop事件拿不到文件路径？检查AllowDrop和DragEnter
直接拖文件进窗体却没触发DragDrop，大概率是漏了两步基础设置。WinForms默认不响应拖拽，必须手动开启：窗体或控件的AllowDrop属性得设为true；同时得先处理DragEnter事件并明确告诉系统“我接受这个拖拽”，否则系统直接忽略后续DragDrop。
-
AllowDrop = true必须在InitializeComponent()之后、或设计器里勾上，仅设DragDrop事件处理器没用 -
DragEnter里必须写e.Effect = DragDropEffects.Copy;（或Move），不能只读e.Data - 如果拖的是桌面快捷方式，
Data.GetData(DataFormats.FileDrop)会返回空——它只认真实文件路径，不解析.lnk
Data.GetData(DataFormats.FileDrop)返回null？确认数据格式和权限
常见错误是直接强转(string[])e.Data.GetData(DataFormats.FileDrop)导致NullReferenceException。其实e.Data.GetData()在非文件拖拽（比如文本、网页链接）时返回null，且Win10/11下从资源管理器拖文件到高DPI缩放的窗体，偶尔因UAC隔离导致数据不可达。
- 务必先用
e.Data.GetDataPresent(DataFormats.FileDrop)判断再取值 - 返回值是
string[]，不是单个string，哪怕只拖一个文件 - 路径含中文或特殊字符完全没问题，.NET 4.7.2+默认UTF-8，不用额外解码
- 如果程序以管理员身份运行，而文件资源管理器是非管理员模式，拖拽会被系统拦截——此时
GetDataPresent始终返回false
WPF里用Drop事件？别忘了PreviewDragOver和AllowDrop="True"
WPF的拖拽逻辑比WinForms更隐晦：光写Drop事件不够，必须设AllowDrop="True"，而且如果父容器（比如Grid）吞掉了拖拽事件，子控件收不到。更麻烦的是，WPF默认对某些区域（如TextBox内）禁用拖拽，需主动干预。
-
AllowDrop="True"要写在实际接收拖拽的控件上，不是整个Window - 在
PreviewDragOver里写e.Handled = true;，否则Drop可能不触发（尤其当鼠标经过文本框时） - 获取文件路径仍用
e.Data.GetData(DataFormats.FileDrop)，但WPF下返回的是string[]，和WinForms一致 - 如果拖入的是文件夹，数组里是文件夹路径，不是其内部文件——要递归遍历得自己写
入库前校验文件名和路径，避开Path.GetFullPath的坑
拿到string[]后别急着存数据库。用户可能拖入相对路径（极少见但可能）、带../的路径、或空字符串（比如拖了个损坏的快捷方式）。直接拼接或调用Path.GetFullPath可能抛ArgumentException或返回意外路径。
- 逐个检查
string.IsNullOrEmpty(path)和File.Exists(path) || Directory.Exists(path) - 用
Path.IsPathRooted(path)过滤掉明显非法路径（如"abc.txt"） -
Path.GetFullPath在遇到..\时会向上解析，若原始路径来自不受信输入，可能跳出预期目录——入库前建议用Path.GetInvalidFileNameChars()扫一遍文件名部分 - 数据库存路径时，推荐存相对路径（相对于应用固定根目录）而非绝对路径，避免迁移时失效
真正卡住人的往往不是事件绑定，而是拖拽数据在不同UAC级别、DPI缩放、快捷方式场景下的行为差异。多测几种环境，比死磕某一行代码更省时间。
