dataTransfer.files 支持多文件拖放，但需用户按 Ctrl/Cmd 多选后拖拽，且 dragover/drop 中必须调用 preventDefault()；multiple 属性对拖放无效；移动端不支持；读取大文件需校验、分批、用 URL.createObjectURL 预览。
拖拽多选文件时 dataTransfer.files 只返回 1 个文件？
不是浏览器 bug，是常见误读：HTML5 拖放 API 中 dataTransfer.files 确实支持多文件，但必须满足两个前提——用户用 Ctrl/Cmd + 拖拽多个文件（非批量选中后整体拖），且目标区域未阻止默认行为或未错误过滤 dataTransfer.items。
实操建议：
- 务必在
dragover和drop事件中调用event.preventDefault()，否则浏览器会拒绝读取dataTransfer.files - 不要只监听
change事件——那是<input type="file" multiple>的路径，拖放场景下它根本不会触发 - 优先用
event.dataTransfer.files（FileList 对象），比遍历items更直接、兼容性更好（IE10+、所有现代浏览器）
multiple 属性对拖放行为完全无效？
对。把 multiple 写在 <div draggable="true"> 或随便一个容器上毫无作用——它只对 <code><input type="file"> 有效，且仅控制「点击选择」时是否允许多选。拖放的多文件能力由操作系统和浏览器原生支持，跟 HTML 属性无关。
容易踩的坑：
立即学习“前端免费学习笔记（深入）”；
- 误以为加了
multiple就能拖多个——实际拖单个或多个，全看用户怎么操作、目标区是否正确接收 - 混淆「拖放上传」和「文件输入框上传」两种机制，混用逻辑导致
files.length === 0 - 在移动端测试时发现拖放不可用——没错，iOS/Android 基本不支持 DOM 拖放 API，别在这儿浪费时间适配
如何安全读取拖入的多个文件并避免内存爆炸？
直接循环调用 FileReader.readAsDataURL() 处理几十个大文件，极易触发内存警告甚至页面崩溃。关键不是“能不能读”，而是“要不要一次性全读”。
推荐做法：
- 先用
file.name、file.size、file.type做轻量校验（比如过滤掉 >100MB 的视频） - 对图片类文件，优先用
URL.createObjectURL(file)快速生成预览链接，而不是转 base64 - 如需内容解析（如读取 CSV 文本），用
FileReader.readAsText()并限制单次并发数（例如最多同时处理 3 个） - 记得在
load后调用URL.revokeObjectURL()清理引用，防止内存泄漏
Chrome/Firefox 拖入文件夹报错 NotSupportedError 怎么办？
因为标准拖放 API 默认不暴露文件夹结构——dataTransfer.files 里只有文件，没有目录对象。想支持拖文件夹，必须改用 dataTransfer.items 并调用 item.webkitGetAsEntry()（Chrome/Edge）或 item.getAsFileSystemHandle()（Firefox 111+，需 HTTPS + 用户手势）。
现实约束：
- Firefox 目前仅部分版本支持
getAsFileSystemHandle()，且要求页面在安全上下文（HTTPS）中运行 -
webkitGetAsEntry()是非标准方法，Safari 已弃用，Chrome 未来也可能移除 - 即使拿到文件夹 Entry，递归读取仍需异步遍历，不能同步获取全部文件列表
多数业务场景下，不如明确提示用户“请拖入文件，而非文件夹”，省去兼容性纠缠。
