“拖拽上传？不就是把照片‘扔’进网页里嘛！”
📱 为什么 iPad 能成功？因为它“傻”
2010 年，iPad 横空出世。大家一边嘲笑它“只是个大号 iPhone”，一边偷偷下单——因为它太好用了！你不需要看说明书，手指一划、一拖、一放，事情就办成了。
这种“傻瓜式”的交互体验，正是 HTML5 拖拽（Drag and Drop）API 的灵魂所在。
而今天，我们就用一段不到 100 行的代码，复刻一个“能拖能放”的图片小游戏，并顺便聊聊：为什么拖拽交互是用户体验的“作弊器”？
🧩 HTML5 拖拽：不是所有元素都“愿意配合”
先泼一盆冷水：HTML5 的拖拽 API 其实有点“傲娇” 。
- 默认情况下，只有图片、链接、选中文本等少数元素可以拖拽。
- 想让一个
<div>变成可拖拽？得手动加draggable="true"。 - 更坑的是：光设置 draggable 还不够，你还得在事件里写一堆
preventDefault()，否则浏览器会一脸懵：“你到底想干啥？”
不信？试试下面这个经典翻车现场：
<div class="fill" draggable="true"></div>
你以为它能拖了？NO！ 如果你不监听 dragover 并阻止默认行为，目标区域根本不会触发 drop 事件——就像你往垃圾桶扔垃圾，结果垃圾桶说：“我不收。”
所以，记住口诀：
dragStart 开始拖，dragOver 必须拦，drop 才能落下来！
🎮 实战：5 个格子，1 张图，拖来拖去真上头
来看我们今天的主角代码（已精简注释版）：
<div class="empty">
<div class="fill" draggable="true"></div>
</div>
<div class="empty"></div>
<!-- 再来 3 个 empty... -->
样式亮点：
.fill：一张 150x150 的随机图（来自 picsum.photos，每天换新图，强迫症福音）.empty：白色边框格子，准备接收拖拽- 拖动时
.hold加粗边框，.hovered高亮目标区域（虚线 + 深色背景）
JS 逻辑三板斧：
-
开始拖（
dragStart）：- 只有
.fill能拖，其他元素直接preventDefault - 给自己加个
hold类，视觉反馈“我被抓走了” setTimeout瞬间隐藏原图（避免“影子”残留）
- 只有
-
进入/离开目标（
dragEnter/dragLeave）：dragEnter：目标格子变虚线 + 深灰背景 → “快放我这儿！”dragLeave：恢复原样 → “哼，不要你了”
-
放手（
drop）：- 把
.fill直接append到目标格子 - 清除 hover 样式
- 把
💡 为什么用事件委托？
因为.fill会不断移动，如果给它自己绑事件，容易丢失。而body始终在，用冒泡机制稳如老狗。
📱 移动优先？不，是“体验优先”！
注意这段媒体查询：
@media (max-width:800px) {
body {
flex-direction: column;
}
}
当屏幕小于 800px（比如手机），格子从横向排列变成纵向堆叠——这才是真正的 Mobile First 思维：
不是“先做 PC 再缩”，而是“先考虑用户在哪用”。
毕竟，谁会在手机上横向滑动五个格子？累死手！
🤔 为什么 Google 上传要用拖拽？
你有没有注意到：Gmail、Google Drive、甚至掘金后台，都支持拖拽上传？
因为：
- 降低认知成本：用户不需要找“上传按钮”，直接“扔进去”就行。
- 符合现实隐喻：就像把文件从桌面拖进文件夹。
- 爽感拉满：看着文件“飞”进网页，多巴胺分泌+10086！
而这一切，背后就是 HTML5 的 drop 事件 + File API。
拖拽的本质，是把数字世界变得“可触摸”。
✅ 总结：拖拽交互的三大心法
- 可拖元素要显式声明：
draggable="true" - 目标容器必须拦截 dragOver：否则 drop 不生效！
- 视觉反馈不能少：hover、hold、drop 状态都要有变化
🚀 最后彩蛋：你的下一步
现在，你可以：
- 把
.fill换成多个图片，做成“拼图游戏” - 在
drop里加入FileReader，实现拖拽上传 - 用
localStorage记住用户摆放位置，刷新不丢
拖拽不是炫技，而是让用户“无感操作”的终极武器。
“好的交互，应该像空气——你感觉不到它的存在，但缺了它会窒息。”
