导致 dragover 不触发 drop 的根本原因在于未在 dragover 事件中调用 e.preventDefault()，浏览器默认会阻止投放行为。必须同时监听 dragover 和 drop 两个事件，并在各自回调中均调用 preventDefault()；当子元素存在时，需为其添加 pointer-events: none 以确保事件冒泡不被阻断。此外，文件上传场景无需为 HTML 元素设置 draggable="true"。
dragover 不触发 drop 的根本原因
不少开发者在实现拖放上传时都会遇到这样的困惑：明明写了 drop 事件的监听，但文件拖入目标区域后毫无响应。绝大多数情况下，问题根源都出在 dragover 事件里——没有调用 e.preventDefault()。
浏览器对拖放操作有一套默认行为：它会将拖入的文件视为“打开”或“下载”动作，而非交给页面上的 drop 事件处理。必须通过 preventDefault() 明确告知浏览器：“这片区域由我接管，请勿干预。”否则连 drop 事件都不会被派发。
常见的错误写法：只给 drop 绑定了监听器，却遗漏了 dragover，或者虽然监听了 dragover 但未调用 preventDefault()。
- 核心原则：
dragover和drop都必须监听，且两者内部均需调用e.preventDefault() dragenter和dragleave属于增强体验的辅助事件，主要用于视觉反馈（如添加高亮类），与功能逻辑无关- 如果 drop 区域内包含子元素（例如
或图标），这些子元素会拦截事件冒泡。最简单的解决方案：为子元素设置pointer-events: none，让事件直接冒泡到容器层
draggable="true" 在文件上传中其实不需要
当用户从本地文件系统将文件拖拽到网页时，操作的对象是操作系统中的文件，而不是网页内某个 元素。因此完全不需要为任何 HTML 元素设置 draggable="true" 属性——该属性用于拖拽排序、页面内元素拖拽等场景（例如可拖拽列表），与文件上传完全是两回事。
真正的文件拖放上传依赖浏览器对操作系统文件的原生支持。只需在目标区域上监听 dragover 和 drop，就能从 e.dataTransfer.files 中获取文件列表。
- 设置
draggable="true"虽然不会报错，但毫无必要，甚至可能让人误以为“需要从页面内拖出某个元素” - 如果希望用户从页面内拖拽图片或文本到上传区，那才需要结合
dragstart和dataTransfer.setData()实现，这是另一套逻辑，与本地文件上传无关 - 文件上传场景中，
e.dataTransfer.files是一个只读的FileList对象，无法增删，只能遍历处理
多文件上传必须用异步队列，别直接 forEach + fetch
最容易踩的坑：用户一次性拖入 20 个文件，开发者直接使用 Array.from(files).forEach(file => upload(file)) 并发发起所有上传请求。后果呢？浏览器连接数被瞬间打满，后端触发限流，部分请求被静默丢弃——尤其在用户拖入 20+ 文件时，控制并发数至关重要。
推荐的方案是用 Promise 队列，每次只并发 3–5 个请求，其余文件排队等待空闲 slot：
function uploadQueue(files, maxConcurrency = 3) { const queue = Array.from(files); const results = []; let active = 0; return new Promise((resolve) => { function next() { if (queue.length === 0 && active === 0) return resolve(results); if (active >= maxConcurrency || queue.length === 0) return; active++; const file = queue.shift(); uploadOne(file).then(res => { results.push({ file: file.name, success: true, ...res }); }).catch(err => { results.push({ file: file.name, success: false, error: err.message }); }).finally(() => { active--; next(); }); } while (active < maxConcurrency && queue.length) next(); });}
uploadOne(file)内部建议使用FileReader.readAsArrayBuffer(file)，而不是readAsDataURL，因为大文件生成超长 base64 字符串会卡住 UI 线程- 上传前务必进行文件类型和大小校验，直接读取
file.type和file.size即可（同步操作，无需 FileReader） - 后端接收的字段名必须与接口约定一致，例如
formData.append('files', file)，否则 multipart 解析会失败
drop 区域样式与兼容性细节
视觉反馈做不好的话，用户根本不知道哪些区域可拖放、拖入后是否生效。但仅靠 CSS :hover 不够，必须通过事件驱动状态变化。
- 在
dragenter触发时添加高亮类（例如dropZone.classList.add('drag-over')），在dragleave时移除。注意：鼠标快速划过子元素可能多次触发dragleave/dragenter，建议加入防抖处理，或者利用event.relatedTarget判断是否真的离开了容器 - IE11 不支持
dataTransfer.files，不过该浏览器基本已淘汰；Safari 对dragover的preventDefault()要求更严格，务必确保监听器正确绑定到目标 DOM 节点上 - 移动端（iOS/Android 浏览器）不支持文件拖放 API，必须降级为点击
的形式，不能指望拖放功能覆盖全平台
还有一个容易忽略的细节：drop 事件中获取的 e.dataTransfer.files 是实时快照，而非引用。如果上传过程中需要过滤某些文件（例如根据大小），不要试图直接修改 files 对象——它是只读的，只能自行新建一个数组来处理。
