WinForm启用拖拽需设AllowDrop=true，WPF靠事件注册；文件路径直接可用，无需解码；跨进程拖拽受DPI/远程桌面限制。
WinForm 中启用文件拖拽必须设置 AllowDrop
默认情况下 WinForm 控件（包括窗体本身）不响应拖放事件，最常被忽略的一步就是没设 AllowDrop = true。这个属性必须显式设为 true，否则 DragEnter 和 DragDrop 事件根本不会触发。
实操建议：
- 在设计器中选中窗体或目标控件 → 属性面板里找到
AllowDrop→ 设为True - 或在代码中初始化时设置：
this.AllowDrop = true;（窗体）或panel1.AllowDrop = true;（Panel 等容器） - 若拖入的是多个文件，
e.Data.GetData(DataFormats.FileDrop)返回string[]，不是单个路径 - 注意：
DragEnter里一定要检查数据格式并设置e.Effect，否则光标会显示“禁止”图标，用户以为拖不进去
WPF 中拖拽事件名和数据获取方式不同
WPF 没有 AllowDrop 属性开关，而是靠注册事件来启用；且数据提取逻辑和 WinForm 不一致，容易混淆。
实操建议：
- 在 XAML 中为窗体或控件添加：
PreviewDragOver="Window_PreviewDragOver"和Drop="Window_Drop" -
PreviewDragOver中必须设置e.Handled = true;并调用e.Effects = DragDropEffects.Copy;，否则Drop事件不会触发 - 在
Drop事件中，用e.Data.GetData(DataFormats.FileDrop)获取文件路径数组，和 WinForm 一样返回string[] - WPF 的
DragDrop.DoDragDrop是用于发起拖拽（比如从 TreeView 拖出），和接收无关，别误用
拖入文件路径含中文或空格时无需额外处理
.NET 框架底层已对拖放路径做了正确解码，string[] 中拿到的就是完整、可直接使用的本地路径，包括含中文、空格、括号等字符的路径。
常见错误现象：
- 手动拼接路径字符串（如
"file:///" + path）→ 导致File.Exists返回false - 误用
Uri.UnescapeDataString或WebUtility.UrlDecode→ 路径被二次破坏 - 把路径当 URL 处理，传给
HttpClient或浏览器控件 → 应该用new Uri(path).AbsoluteUri转成 file:// URL（仅当需要传给 Web 控件时）
跨进程拖拽在高 DPI 或远程桌面下可能失效
Windows 的拖放本质是进程间通信，当源程序和目标程序 DPI 缩放比例不一致（比如一个设 125%，另一个 100%），或运行在远程桌面/Windows Terminal 中，DragEnter 可能完全不触发。
这是系统级限制，非代码缺陷。临时缓解方式：
- 确保两个应用都设为“高 DPI 感知”，在项目属性 → 应用程序 → 高 DPI 感知中勾选
- 在 app.manifest 中添加
<dpiaware>true/PM</dpiaware>（WinForm）或确保 WPF 的Application.EnableVisualStyles()已调用 - 若仍失败，退而求其次：提供“浏览文件夹”按钮作为备用入口，不要只依赖拖拽
真正稳定的拖放体验，往往取决于用户环境是否统一，而不是你代码写得多漂亮。
