原生拖放必须用drag系列事件+draggable属性，仅设draggable="true"不够，须在dragstart中调用setData()；目标区需在dragover中preventDefault()才能触发drop；读文件用files、文本用getData('text/plain')；移动端和iframe需特殊处理。
JavaScript 原生拖放功能不是靠 mousedown/mousemove 模拟出来的，而是必须用浏览器原生的 drag 系列事件 + 正确设置 draggable 属性，否则在多数场景下（比如跨 iframe、系统级拖入文件）会直接失效。
如何让元素变成可拖拽状态
仅加 draggable="true" 属性还不够，很多开发者漏掉关键一步：必须为该元素绑定 dragstart 事件，并在其中调用 event.dataTransfer.setData() 设置拖拽数据。否则 Chrome/Firefox 会静默禁用拖拽（不报错，但拖不动）。
-
draggable属性只控制「是否允许拖拽」，不触发任何逻辑 -
dragstart是唯一能合法写入dataTransfer的时机，其他事件里调用setData()会被忽略 - 常见错误：
<div draggable="true">文本</div>—— 没有dragstart处理，实际无法拖动
为什么 dragover 事件必须 preventDefault
目标区域要接收拖入，必须在 dragover（以及 dragenter）事件中调用 event.preventDefault()。这是浏览器的安全限制：不显式声明“我接受拖放”，就默认阻止 drop。
- 只在
drop里preventDefault()不够，dragover被阻止后根本不会触发drop - 可以只对特定类型允许拖入，例如判断
event.dataTransfer.types.includes('text/plain')再决定是否preventDefault() - 不加
preventDefault()的典型表现是：拖到目标区时鼠标变成“禁止”图标（圆圈斜杠），松手无反应
如何安全读取拖入的文件或文本
drop 事件里的 dataTransfer 对象内容取决于来源：本地文件拖入走 files，网页内拖拽走 getData()，粘贴板拖入可能两者都有。不能假设单一路径。
立即学习“Java免费学习笔记（深入）”；
- 读文件：用
event.dataTransfer.files（FileList），不要试图用getData('Files')—— 这个类型不存在 - 读文本：优先用
event.dataTransfer.getData('text/plain')，兼容性比getData('Text')更好 - 读 HTML 片段：
getData('text/html')，但注意 XSS 风险，需过滤或用DOMPurify - 注意：Safari 对
files的支持较晚（iOS 16.4+ 才稳定），旧版需降级方案
移动端和 iframe 场景下的典型失效点
原生拖放 API 在移动端默认被禁用（iOS Safari 完全不支持 dragstart），且跨 iframe 拖拽时，子 frame 必须显式监听自身 dragover 并 preventDefault()，父 frame 无法代劳。
- 移动端替代方案只能用
touchstart/touchmove+ CSStransform模拟，无法触发系统级拖放（如拖进备忘录） - iframe 中启用拖放需满足两个条件：iframe 的
sandbox属性不含allow-scripts以外的限制，且内部文档已执行过用户手势（如点击）以激活权限 - Electron 应用里，
webPreferences.draggable = false会全局禁用，需手动设为true并处理-webkit-app-region
真正难的不是写出拖放代码，而是判断当前上下文是否支持原生 API、是否需要 fallback、以及如何让 dataTransfer 的数据在不同来源间保持语义一致 —— 这些细节往往在集成时才暴露。
