在 drop 事件中用 Array.from(e.dataTransfer.files) 转数组，filter 掉 size≤0 的项，再 reduce 累加；须校验总大小（非单个文件），并同步前后端限制，移动端需降级处理 input change 事件。
拖拽区域 drop 事件里怎么汇总所有文件大小
拿到 e.dataTransfer.files 后，它是个只读的 FileList，不能直接用 reduce 或 sum，得先转成数组再累加。别漏掉空文件（比如用户拖了文件夹或无效项），file.size 可能为 0 或 undefined，尤其在 iPad Safari 上有延迟问题。
- 用
Array.from(files)转换，再filter(file => file.size > 0)剔除无效项 - 累加用
files.reduce((sum, f) => sum + f.size, 0)，别写成files.map(f => f.size).reduce(...)——多一次遍历不必要 - 总大小超限时，建议清空
e.target.value（如果绑在 input 上）或置空 UI 状态，避免用户误点重复提交
为什么只校验单个文件大小不够用
很多代码只检查 file.size ，这只能拦住单个大文件，但用户可能拖 20 个 4MB 的图片，总和 80MB，后端照样收不住。Nginx 默认 client_max_body_size 是 1MB，没调大就直接返回 413，前端 fetch 却只看到网络错误，找不到原因。
- 前端总大小限制应略小于后端配置（比如后端设 20m，前端卡在 18m），留出 multipart 边界符和字段开销
- 服务端必须同步限制：Express + multer 要设
limits: { fileSize: 20 * 1024 * 1024 }，且fileFilter里不能只看单个file.size，得维护累计值（需自定义中间件） - PHP 和 Python 同理，
$_SERVER['CONTENT_LENGTH']或request.content_length是整个请求体长度，比单纯加总files更准，但需在接收前拦截
移动端拖拽总大小限制要特别注意什么
iPad Safari 不支持桌面级拖拽 API，所谓“拖拽上传”实际是点击触发 ，然后从文件 App 选中多个文件。这时 change 事件里的 e.target.files 才是真实来源，但 size 读取可能延迟或为 0。
- 加
setTimeout(..., 100)再读file.size，否则判断逻辑失效 - 不要依赖
dragover或drop在 iOS 上做总大小控制——它们根本不会触发 - 降级方案里，对
input[type="file"]的change事件也要做同样总和校验，逻辑复用，别写两套
FormData 发送前如何避免重复计算或漏判
构造 FormData 时，你 append 的是 File 对象本身，不是内容。所以前端总大小校验必须在 append 之前完成，而不是等 fetch 出错才处理。
- 校验失败立刻
return，别走到fetch()那步；否则用户看到“上传中”但实际卡死 - 别在
for循环里逐个 append 后再算总和——append 不影响File对象，但逻辑容易错乱 - 如果允许用户删减已选文件（比如预览列表里点 ×），记得重新计算剩余文件总大小，而不是沿用初始值
真正难的不是加总，是前后端对“总大小”的定义是否一致：前端按 File.size 加总，后端按流式接收字节数累计，中间还有 Nginx、CDN、反向代理可能截断。只要有一层没对齐，就会出现“前端说没超，后端收不到”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
