draggable="true"仅开启拖拽入口，不自动触发行为；必须监听dragstart并调用setData()、dragover中持续preventDefault()，且移动端原生不支持。
draggable 属性设为 true 后为什么元素还是拖不动
根本原因不是 draggable 单独起作用，而是它只控制「是否允许被拖拽」这个开关，不提供拖拽逻辑本身。浏览器默认只对图片、链接、选中的文本等少数元素启用原生拖拽；即使你写了 <div draggable="true">试试看</div>，没后续处理，松手就结束，也不会触发任何事件。
真正让拖拽“生效”的，是必须监听并实现一整套拖拽事件链：dragstart、dragover、drop（还有 dragend、dragenter 等）。其中两个关键点常被忽略：
-
dragover事件默认被浏览器取消（preventDefault），不手动阻止，drop就永远不会触发 -
drop事件目标必须是dragover允许的区域——也就是你得在dragover里调用event.preventDefault()
如何让一个 div 成为合法的 drop 区域
光给容器加 draggable="true" 没用；它得是接收方，而不是被拖方。常见错误是把 draggable="true" 加在目标容器上，其实应该加在被拖元素上，目标容器只需监听事件。
正确做法：
立即学习“前端免费学习笔记（深入）”；
- 被拖元素（如
<p draggable="true">拖我</p>）设置draggable="true" - 目标容器（如
<div id="dropzone"></div>）不需draggable属性，但必须监听dragover和drop - 在
dragover回调中必须写event.preventDefault()，否则浏览器认为“不允许投放” - 在
drop回调中，记得再调一次event.preventDefault()（防止打开文件/链接等默认行为）
示例关键片段：
<div id="dropzone">拖到这里</div>
<p draggable="true">拖我</p>
<script>
const dropzone = document.getElementById('dropzone');
dropzone.addEventListener('dragover', e => e.preventDefault()); // 必须
dropzone.addEventListener('drop', e => {
e.preventDefault();
console.log('投放成功');
});
</script>
dataTransfer 对象里放什么才真能传数据
dragstart 里用 event.dataTransfer.setData() 写入的数据，才是 drop 时能取到的内容。很多人只改了 innerHTML 或设了 dataset，却忘了这一步，结果 drop 里 getData() 返回空字符串。
注意点：
- 必须在
dragstart中调用setData()，且类型（第一个参数）要和getData()一致，比如都用'text/plain' - 不能传对象或函数，只支持字符串；想传结构化数据，得先
JSON.stringify() - 浏览器对非标准 MIME 类型（如
'application/json'）兼容性差，建议统一用'text/plain'或'text/html'
例如：
document.querySelector('p').addEventListener('dragstart', e => {
e.dataTransfer.setData('text/plain', 'hello from dragstart');
});
移动端和 Safari 的 draggable 支持很有限
HTML5 原生 draggable 在 iOS Safari 和大部分安卓 WebView 中基本不可用：不触发 dragstart，或拖拽中途卡死。这不是代码问题，是浏览器故意禁用——因为触摸交互和鼠标差异大，原生实现不稳定。
如果你的应用必须支持触屏拖拽：
- 不要依赖
draggable="true"+ 原生事件链 - 改用
touchstart/touchmove/touchend手动模拟，或引入轻量库如interact.js或sortablejs - 用
CSS touch-action: none防止滚动干扰（但会禁用双指缩放等）
简单判断是否可用：在 Safari 中打开一个仅含 <div draggable="true"></div> 的页面，长按试试——大概率毫无反应。
别在 draggable 上花太多调试时间，尤其当需求明确要跨端时。原生拖拽的坑，多数时候不如重写一套 touch 友好的逻辑来得稳。
