HTML 文件夹上传需用 webkitdirectory directory multiple 同时启用,通过 event.target.files 获取扁平化文件列表并累加 .size 得总大小,再串行上传、手动累加已传字节数计算整体进度。

HTML 本身不支持直接上传文件夹(input[type="file"] 默认禁用目录选择),必须显式启用 webkitdirectory 或 directory 属性,且进度条能否实时更新,取决于你是否能获取每个文件的总大小——而浏览器对文件夹遍历后得到的 FileList 是扁平化的,不含原始路径结构,但所有文件对象的 .size 可读。
怎么让 input 支持文件夹选择并拿到全部文件
关键不是“上传文件夹”,而是“让用户选中一个文件夹,前端递归读取其中所有文件”。现代浏览器(Chrome、Edge、Firefox ≥ 97)支持以下写法:
<input type="file" id="folderInput" webkitdirectory directory multiple>
注意三点:
-
webkitdirectory和directory必须同时存在,保证兼容性 -
multiple属性不可省,否则只返回单个File(即使选的是文件夹) - 事件触发后,
event.target.files返回的是包含所有嵌套文件的FileList,但**不包含子目录对象或占位符**——也就是说,没有“空文件夹”项,也不会报错跳过,只返回实际文件
为什么 upload.onprogress 拿不到整个文件夹的总进度
xhr.upload.onprogress 的 e.total 是当前正在上传的那个 File 的大小,不是整个文件夹。如果你串行上传(一个接一个),就无法用单次 onprogress 表示整体进度;如果并行上传,又面临并发控制与总字节数叠加的复杂度。
真正可行的方案是:先遍历 FileList 累加所有 .size 得到 totalBytes,再在每次上传完成一个文件时累加已传字节数,手动计算整体百分比。
常见错误现象:
- 直接把
e.total当作文件夹总大小 → 实际只是当前文件大小,进度条会反复从 0 跳到 100% - 没预计算总大小,等第一个文件上传完才开始统计 → 用户看到进度条卡在 0% 几秒,体验断层
- 忽略大文件夹下
FileList.length可达数千,遍历时未做节流或异步处理 → 页面卡死
如何实现可信赖的整体进度条(含代码骨架)
核心逻辑:预计算 + 分文件上报 + 手动累加。不需要第三方库,纯原生 JS 即可。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面,使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力: - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面; - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”; - 提及位于 `apps/console/src/featur
步骤简述:
- 监听
change事件,调用Array.from(event.target.files)转为数组 - 用
files.reduce((sum, f) => sum + f.size, 0)算出totalBytes - 用
for...of串行上传(推荐,避免并发混乱),每完成一个文件,更新uploadedSoFar += file.size - 每次更新后重算
Math.round((uploadedSoFar / totalBytes) * 100),设给
示例关键片段:
const files = Array.from(event.target.files);<br>const totalBytes = files.reduce((a, f) => a + f.size, 0);<br>let uploadedSoFar = 0;<br><br>async function uploadAll() {<br> for (const file of files) {<br> const formData = new FormData();<br> formData.append('file', file);<br> const xhr = new XMLHttpRequest();<br> xhr.open('POST', '/upload');<br> xhr.onload = () => {<br> uploadedSoFar += file.size;<br> const percent = Math.round((uploadedSoFar / totalBytes) * 100);<br> document.getElementById('uploadProgress').value = percent;<br> };<br> xhr.send(formData);<br> }<br>}
⚠️ 注意:xhr.upload.onprogress 在这里**不用监听**——它对单个文件有效,但干扰整体节奏;我们只靠 xhr.onload 做确定性累加,更稳。
容易被忽略的边界情况
文件夹上传不是“点一下就走完”的操作。真实场景中,以下几点常被跳过但直接影响可用性:
- 用户取消选择或刷新页面 → 需保存
uploadedSoFar到sessionStorage,支持恢复(否则重传重复文件) - 某文件上传失败(如 413、网络中断)→ 必须有
xhr.onerror捕获,并标记该文件失败,不能简单跳过导致总进度不准 - 超大文件夹(>10GB)→ 浏览器可能因内存占用过高崩溃,建议限制
files.length或总totalBytes上限,并提前提示 - 部分文件被系统拒绝访问(如 macOS 的受保护目录)→
FileList中不会包含它们,但用户无感知,需在预计算后对比预期数量做校验
进度条动起来不难,难的是动得准、不骗人、断了能续——这些细节不在 DOM 更新里,而在你对 FileList 的信任边界和对失败路径的预设中。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!










