draggable="true"仅开启可拖状态，不自动触发事件；必须监听dragstart并调用setData("text/plain","")，且drop区需在dragover中preventDefault()。
这里有个关键认知需要厘清：给元素加上 draggable="true"，仅仅是开启了拖拽流程的“入场券”，它本身并不是一个自动生效的开关。想让拖拽真正工作起来，后续的事件监听和 dataTransfer 操作一个都不能少。
draggable="true"为什么加了还是拖不动？
很多开发者会困惑，明明属性设了，怎么元素还是纹丝不动？这得从浏览器的“潜规则”说起。实际上，浏览器只对三类元素“网开一面”，默认启用了原生拖拽逻辑：href 属性的 链接，以及用户选中的文本。除此之外的其他元素，比如你常用的 ，即便老老实实写上 draggable="true"，也顶多是在视觉上让你觉得它能拖（鼠标指针可能会变化），但关键的 dragstart 事件根本不会触发。
那么，正确的做法是什么？你需要手动补全以下几步：
- 必须显式监听
dragstart事件：这是拖拽开始的信号。在这个事件的处理函数里，必须调用event.dataTransfer.setData()方法。哪怕你暂时没有数据需要传递，塞一个空字符串进去（比如setData("text/plain", "")）也是必要的，这相当于向浏览器确认“拖拽动作已就绪”。 - 警惕CSS的“隐形杀手”：如果你的CSS里为元素设置了
user-select: none（禁止文本选择）或pointer-events: none（禁用指针事件），它们会在鼠标按下的阶段就直接拦截操作，导致拖拽根本无法启动。 - 属性必须“对号入座”：
draggable属性必须直接写在那个要被拖动的元素自身上。只写在它的父容器里是没用的，浏览器不会向下继承这个状态。
dragstart 里 setData() 的 type 参数怎么选？
到了 setData() 这一步，type 参数的选择可不是随便起个名字那么简单。它本质上是一个需要被浏览器识别的MIME类型标识符。如果填错了，后果可能是Firefox完全拒绝接收数据，或者在Chrome里你只能拿到一个空字符串。
怎么选才能确保兼容性？记住这几个原则：
- 跨浏览器“安全牌”：首选
"text/plain"和"text/html"。对于结构化的数据，稳妥的做法是先调用JSON.stringify()转换成字符串，再存入"text/plain"类型中。 - 慎用自定义类型：尽量避免使用像
"app/id"、"json"这类自定义的type字符串。除非你能百分百确定，整个拖放逻辑都发生在同一个页面内，并且你完全掌控着拖拽起点和终点的所有事件处理代码。 - 注意大小写：
setData("Text", "value")这种首字母大写的写法已经过时了，部分现代浏览器可能不再识别。统一使用小写的"text/plain"是最保险的。
drop 区域为什么始终不响应？
这是另一个高频“踩坑点”：代码写了一大堆，拖拽元素时也有反应，但一松手，目标区域毫无动静。90%的情况下，问题都出在 dragover 事件上——你忘了在里面调用 preventDefault()。
请注意，这不仅仅是一个“最佳实践”或“优化建议”，而是浏览器的强制规定：如果目标区域的 dragover 事件没有被阻止默认行为，那么后续的 drop 事件就根本不会派发出来。所以，这一步是绕不开的。
具体操作时，还有几个细节值得关注：
- 目标区域必须监听
dragover：并在其事件回调函数中，同步执行event.preventDefault()。 - 处理容器嵌套：如果作为投放区的容器内部还有子元素，
dragover事件可能会因为冒泡而高频触发。建议将监听器绑定在父级容器上，并视情况使用event.stopPropagation()来控制事件的影响范围。 - 忘掉 dropzone 属性：那个古老的
dropzone属性早已被标准废弃，现代浏览器完全无视它。别再指望通过设置这个属性来“自动启用”投放功能了。
话说回来，很多拖拽功能失效的问题，根源往往不在于复杂的交互逻辑设计，而在于这些基础环节是否真的打通了：dragstart 到底触发了没有？dragover 的默认行为阻止了没有？setData 用的类型浏览器认不认？这三个环节只要有一个出了纰漏，整个拖拽链条在起点就断掉了，连调试工具里都可能看不到后续的事件流。
立即学习“前端免费学习笔记（深入）”；
