必须用等块级元素作容器并设draggable="false"，监听dragover（需preventdefault）、drop和dragleave事件；仅作降级入口，不响应拖拽。
拖拽区域的HTML结构怎么写才支持多文件
必须用 <div> 或其他块级元素作为容器，且需显式设置 <code>draggable="false"（防止文本被意外拖走），同时监听 dragover、drop 和 dragleave 事件——仅靠 <input type="file" multiple> 无法触发拖拽行为，它只是原生选择器。
常见错误是直接把 <input type="file"> 套在 <label></label> 里就以为能拖拽，实际它只响应点击，不响应 drop。真正起作用的是包裹它的容器元素。
- 容器必须设
role="region"或aria-label提升可访问性 - 避免用
<form></form>直接包裹拖拽区，否则drop事件可能被表单默认行为拦截 - 不要给容器设
contenteditable="true"，否则会抢走drop事件
如何让drop事件正确读取多个文件
drop 事件的 event.dataTransfer.files 是一个 FileList，天然支持多文件，但容易忽略两点：一是必须在 dragover 中调用 event.preventDefault()，否则浏览器会执行默认下载行为；二是 dataTransfer.items 可能包含非文件项（比如文本、链接），需要过滤。
实操建议：
- 在
dragover回调里只做event.preventDefault()和event.stopPropagation()，别做文件校验——太早判断反而影响性能 - 从
event.dataTransfer.files读，别用items，除非你要处理粘贴图片等特殊场景 - 检查
files.length === 0的情况，某些系统（如 macOS Safari）在拖入文件夹时可能返回空FileList
input[type="file"] 在拖拽流程里起什么作用
它不是摆设，而是兜底方案和文件读取入口。拖拽落下的文件最终仍要交给 <input type="file" multiple> 的 files 属性或 FileReader 处理，但不能直接把拖拽的 FileList 赋值给 input.files（DOM 属性只读）。
所以典型流程是：拖拽 → 拿到 FileList → 用 Array.from(files) 转成数组 → 逐个上传或预览。此时 <input> 的作用只剩两个：
- 提供“点击选择文件”的降级路径
- 复用其
accept、capture等属性做前端类型限制（但注意：这些属性对拖拽无效，仅约束点击选择）
为什么拖拽后文件名显示异常或乱码
不是编码问题，而是没正确提取 File.name。有些文件系统（如 NTFS）会在文件名里带 Unicode 字符或控制字符，而 File.name 是只读字符串，不能直接用于 DOM 渲染——尤其当插入 innerText 时可能被浏览器转义。
安全做法：
- 用
document.createTextNode(file.name)插入，而非拼接字符串 - 上传前对
file.name做正则清洗：file.name.replace(/[/\?%*:|"]/g, "_")，避免后端解析失败 - 不要依赖
file.webkitRelativePath，它只在拖拽文件夹时存在，且 Chrome 已弃用
拖拽上传真正的复杂点不在结构，而在事件生命周期控制和 File 对象的边界处理——比如用户连续两次拖入，第二次 drop 触发时第一次还没上传完，这时候该清空队列还是排队，得看业务逻辑，HTML 结构本身管不了这个。
