拖拽上传需正确处理事件节奏与状态管理：dragover必须preventDefault()以触发drop；需兼容paste粘贴图片；移动端须fallback至file input；drop后须清除临时类、loading态及错误提示，大文件需前置校验。
拖拽上传不是“加了dragover和drop就完事”，真正卡顿、失响应、误触发的根源，往往藏在事件处理节奏、视觉反馈时机和移动端兜底策略里。
为什么dragover里必须调用preventDefault()
这是硬性前提，不是可选项。浏览器默认会拦截非可编辑区域的拖放行为，不调用preventDefault()，drop事件压根不会触发——你拖得再用力，页面也收不到。
- 只在
dragover中调用，dragenter和drop里不需要重复写 - 如果目标区是
contenteditable或input，默认行为可能不同，建议统一加event.stopPropagation()防干扰 - 别只监听
drop：没dragover的拦截，drop永远是死信
怎么让拖拽区反馈更自然（含粘贴兼容）
用户顺手Ctrl+V粘贴截图，结果界面毫无反应，体验立刻断层。拖拽和粘贴逻辑复用，才是直觉操作的关键。
- 监听
paste事件，在event.clipboardData.items里遍历找type.startsWith('image/')的Blob - 对粘贴图片，用
new File([blob], 'pasted.png', { type: blob.type })包装成标准File对象，后续上传流程完全复用 -
dragenter时加临时 class（如is-drag-over），但dragleave不保证总触发，得加防抖 + 定时器兜底清除 - 移动端不支持
drag系列事件，必须 fallback 到<input type="file">，别试图强行模拟
drop后UI状态重置常被忽略
连续拖两次，第二次卡住？大文件拖入后直接发请求，后端返回413 Payload Too Large？这些都不是DragEvent的问题，而是状态管理没跟上。
立即学习“前端免费学习笔记（深入）”；
-
drop处理完必须清掉所有临时 class、loading 状态、错误提示，否则下一次拖拽会被前一次残留状态阻塞 - 大文件要提前校验：
files[0].size > 100 * 1024 * 1024（100MB）就直接提示，别等fetch发出去再等失败 - 上传中禁用拖拽区，避免用户重复触发；但要用
pointer-events: none而非disabled（div不支持disabled） - 上传失败后，别只弹个
alert，要把拖拽区恢复可交互，并保留已选文件名（方便重试）
最复杂的点不在拖拽本身，而在“拖完之后”——状态是否干净、反馈是否明确、边界是否兜住。一个没清掉的is-uploading类，可能让整个功能在第二次使用时彻底失效。
