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