html5拖放需在dragstart中调用datatransfer.setdata()传数据，dragover必须preventdefault()才能触发drop，移动端不支持原生api需降级处理。
dragstart 事件里必须设置 dataTransfer
HTML5 拖放功能不会自动传递被拖元素的内容，dragstart 中不调用 dataTransfer.setData()，后续所有 drop 事件都拿不到数据——哪怕你只是想拖一个 <div> 到另一个区域做位置交换。
<p>常见错误是只写 <code>event.dataTransfer.effectAllowed = 'move' 就以为够了，其实没设数据，drop 里 getData() 返回空字符串，逻辑直接断掉。
-
setData('text/plain', 'item-123')最常用，适合传 ID 或简单标识 - 如果要传结构化数据（比如对象），得先
JSON.stringify()再塞进去 - 不能用
setData('application/json', ...)期望浏览器自动解析——各浏览器支持不一致，老老实实用text/plain - 拖拽图片或文件时，
dataTransfer.files是只读的，但不需要手动setData，它自带
dragover 默认被浏览器阻止，必须显式 preventDefault
很多开发者卡在“drop 事件根本没触发”，原因就是没在 dragover 里调用 event.preventDefault()。这个行为不是 bug，是规范强制要求：只有明确声明“我接受拖入”的目标元素，才能触发 drop。
注意：preventDefault() 必须在 dragover 里调，写在 dragenter 或别的地方无效；而且不能只在条件成立时才调——哪怕你想限制只允许拖到某类容器，也得先 preventDefault()，再在 drop 里校验逻辑。
立即学习“Java免费学习笔记（深入）”；
- 经常和
event.dataTransfer.dropEffect = 'move'配合使用，控制光标样式 - 如果目标区域是
contenteditable或表单控件，可能还需额外处理焦点，否则拖入后光标不响应 - 移动端 Safari 对
dragover的触发很保守，有时需给目标加draggable="true"才能激活（尽管它并不真拖）
drop 事件里记得 e.preventDefault() 和 e.stopPropagation()
即使 dragover 已正确拦截，drop 事件中仍需调用 e.preventDefault()，否则部分浏览器（尤其是 Chrome）会尝试执行默认行为——比如把文本拖进页面变成新标签页打开链接，或把文件拖入触发下载。
更隐蔽的问题是事件冒泡：drop 发生在子元素上，但父容器也绑了监听，结果同一拖拽被多个 handler 处理。除非你刻意设计嵌套响应，否则大概率要 e.stopPropagation()。
- 顺序很重要：先
preventDefault()，再取dataTransfer.getData('text/plain')，最后操作 DOM - 如果拖的是文件，用
dataTransfer.files获取FileList，不要试图从getData()读文件内容 - 别在
drop里直接修改dataTransfer，它是只读的；所有状态更新应通过业务变量或 DOM 属性完成
移动端不支持原生 drag/drop，得降级处理
iOS 和 Android 主流浏览器（包括 Chrome for Android）对 HTML5 拖放 API 支持极差：要么完全不触发 dragstart，要么 dataTransfer 为空，甚至 drop 根本不触发。这不是配置问题，是 WebKit 和 Blink 的长期限制。
真实项目里必须准备 fallback：监听 touchstart → touchmove → touchend 模拟拖动，用 transform 移动元素，配合碰撞检测判断是否“放入”目标区。别指望加个 draggable="true" 就能在手机上跑通。
- 第三方库如
interact.js或sortablejs的移动端支持，本质都是绕过原生 API 自己实现的 - 如果产品必须支持移动端拖放，优先评估是否可用点击/长按 + 弹窗选择替代，比硬啃 touch 模拟稳定得多
- 测试时务必真机验证，模拟器里的 drag 事件行为和真实触控差异很大
拖放看着简单，真正落地时最麻烦的从来不是怎么写 dragstart，而是跨浏览器兼容、移动端降级、以及用户手滑拖错位置后的状态回滚逻辑——这些往往比 API 本身更消耗时间。
