HTML5拖放API功能完整但适用场景有限，适合轻量级页面内交互；dragover必须preventDefault()才能触发drop，dataTransfer类型需严格匹配，移动端支持差，复杂排序需用SortableJS等库。
HTML5 拖放 API 本身功能是完整的，但“好用”取决于场景——它适合轻量、页面内、非精密的交互（比如卡片排序、简单文件上传），一旦涉及复杂布局、跨容器移动、视觉反馈或移动端适配，立刻暴露设计缺陷。
为什么 dragover 必须写 event.preventDefault()？
这是最常卡住开发者的点：浏览器默认禁止在任意元素上投放，dragover 触发时若不调用 preventDefault()，后续的 drop 事件根本不会触发，连控制台都不会报错，只会“静默失败”。
-
dragover是唯一一个必须阻止默认行为才能让投放生效的事件；drop里也得再调一次，否则部分浏览器（如旧版 Safari）仍可能跳转链接或打开文件 - 只监听
drop是不够的，没dragover的preventDefault()，drop永远不会来 - 如果目标区域是空 ，记得设
min-height或内容占位，否则它高度为 0，拖不进去dataTransfer 对象的类型和 setData() 容易踩哪些坑？
dataTransfer看似简单，但 MIME 类型不匹配、大小写敏感、多格式写入顺序都会导致getData()返回空字符串。-
setData('text/plain', 'abc')和getData('Text/Plain')不匹配——类型名必须完全一致，推荐统一用小写 - 多次调用
setData()不会覆盖，而是并存；但getData()只能按指定类型取最后一次写入的值 - 想传 DOM 元素引用？不行。只能传序列化数据（ID、JSON 字符串等），然后在
drop里用document.getElementById()查找 - 移动端基本不支持
dataTransfer的文件读取，event.dataTransfer.files在 iOS Safari 中始终为空
为什么拖拽排序在真实项目中几乎不用原生 API？
因为原生 API 缺少关键能力：无法获知“插入位置”（顶部/中间/底部）、不能响应式调整其他元素位置、没有拖拽中 placeholder 占位逻辑。
立即学习“前端免费学习笔记（深入）”；
- 原生
drop只告诉你“松手了”，但不知道该插到第几个子节点前——得自己算event.target和鼠标坐标，再遍历children - 没有
dragenter的“进入方向”信息，无法区分是拖到列表上方还是下方，导致排序错乱 - IE11 及以下、所有安卓 WebView、大部分鸿蒙系统 WebView 都存在 event 坐标偏移或事件丢失问题
- 真正上线的拖拽排序（如看板、课程表）基本都用
interact.js或SortableJS，它们底层绕过原生 API，用mousedown/mousemove/mouseup自行模拟
说到底，HTML5 拖放 API 是个“可用但不好扩”的规范：它解决了“能不能拖”的问题，却没解决“怎么拖得自然、可靠、可维护”的问题。如果你只是做个 demo 或内部工具，够用；但面向用户的产品级交互，建议直接上成熟库，别在
dragover里反复调试 preventDefault 的时机。 -
