draggable属性在文件上传中不应设为true，因其仅控制网页内元素拖动，与拖入操作系统文件无关；真正关键的是dragover事件中调用e.preventDefault()以允许投放。
draggable 属性在文件上传拖拽区域中不该设为 true，设了反而可能出问题；它和“拖入文件”完全无关，真正起作用的是 dragover 事件里是否调用了 e.preventDefault()。
为什么给上传区域加 draggable="true" 是错的
用户拖的是操作系统里的文件，不是网页上的 DOM 元素——draggable 控制的只是“网页内元素能否被拖动”，比如拖卡片排序。它对桌面文件毫无影响。
- 加了
draggable="true"不报错，但纯属冗余，还会误导你去监听dragstart这类源端事件 - 子元素（如图标、文字）可能因此触发默认文本拖拽，干扰 drop 行为
- 某些旧版 UI 组件（如早期 Element Plus）会内部误设，需用 CSS 强制覆盖：
div[draggable] { draggable: false !important; }
拖拽上传区域真正需要的两个 HTML 属性
不是 draggable，而是这两个：
-
draggable="false"：显式禁止该区域成为拖拽源，防止内部文本被意外拖走 -
tabindex="0"：让区域可键盘聚焦，空格/回车能唤起原生<input type="file">，保障无障碍支持
两者缺一不可。不加 tabindex="0"，键盘用户无法操作；不加 draggable="false"，鼠标划过文字时可能触发系统级文本拖拽，导致 drop 事件被吞。
立即学习“前端免费学习笔记（深入）”；
dragover 中不调 preventDefault() 就等于没写 drop 监听
这是 90% 的“拖进去没反应”问题的根源。浏览器默认把拖入文件当成“打开”或“下载”，必须明确告诉它：“这里允许投放”。
- 只监听
drop不够，必须同时监听dragover并在其中调用e.preventDefault() -
dragover是持续触发的，别在里面做重逻辑，只负责“开门” - 如果上传区域有子元素（比如
<p>或<svg>），它们会拦截事件，得给子元素加pointer-events: none确保事件冒泡到容器
drop 事件里怎么安全读取文件
e.dataTransfer.files 是只读的 FileList，不是数组，不能直接用 forEach 或展开运算符。
- 必须先转成真数组：
const files = Array.from(e.dataTransfer.files) - 检查
file.type或file.name做基础校验，注意同一文件多次拖入时lastModified可能不同 - 拖入文件夹时
dataTransfer.files为空，Chromium 系列可用webkitGetAsEntry()递归读取，但 Safari 和 Firefox 不支持
跨域上传的关键不在 drag/drop 阶段，而在后续 fetch 请求是否带 credentials: 'include'、后端是否返回正确的 Access-Control-Allow-Origin 头——这部分和 draggable 完全无关，但最容易被忽略。
