HTML表单中Input类型为File的切片上传逻辑在HTML源代码层的设计

作者：袖梨 2026-06-19

HTML 的 <input type="file"> 不支持切片，切片上传完全由 JavaScript 控制：通过 File.slice() 手动截取 Blob，用 FormData 逐块发送，并携带 chunk_index、total_chunks、upload_id 等元信息，后端需配合实现续传与幂等。

File input 本身不支持切片，得靠 JavaScript 拆

HTML 的 <input type="file"> 只负责选文件、暴露 File 对象，上传逻辑（包括切片）完全由 JS 控制。浏览器不会自动把大文件切成块发出去——这是常见误解。你看到的“切片上传”全是前端用 File.slice() 或 ArrayBuffer 手动截取，再逐块调用 fetch 或 XMLHttpRequest 发送。

选中文件后，从 input.files[0] 拿到 File 实例，它继承自 Blob，所以能用 .slice(start, end)
start 和 end 单位是字节，不是字符或 chunk 数；注意 end 是开区间（不包含），别写成 end - 1
切片后得到的是新 Blob，需包装进 FormData 并设好字段名（如 file_chunk），否则后端收不到二进制数据
别在 change 事件里直接开始上传——用户可能快速换文件，得先清掉上一次的 pending 请求，避免竞态

FormData 里怎么传切片和元信息？

每个切片请求必须带上下文：第几块、总块数、文件唯一标识（如 file.name + file.lastModified 拼的 hash）、原始文件大小。这些不能只靠 URL 参数传，容易被拦截或长度超限；统一塞进 FormData 最稳妥。

用 formData.append("chunk_index", i)、formData.append("total_chunks", Math.ceil(file.size / chunkSize))
文件块本身用 formData.append("file", blob, file.name) —— 第三个参数会设 Content-Disposition 的 filename，后端解析时依赖这个
如果服务端要求签名或 token，也得作为字段加进去，比如 formData.append("upload_id", uploadId)
注意：FormData 不能直接 append ArrayBuffer，必须转成 Blob（new Blob([arrayBuffer])）

切片大小设多少？1MB 还是 5MB？

没有固定值，取决于网络环境和后端限制。设太小（如 128KB）会导致 HTTP 头开销占比飙升、请求频次过高；设太大（如 20MB）则单次失败重传成本高，且可能触发浏览器内存警告（尤其移动端）。

常见实践是 1–5MB：PC 端可设 4MB，弱网或移动端建议 1–2MB
别硬编码死值，可结合 navigator.onLine 和 NetworkInformation.effectiveType（如有）动态调整
后端必须明确告知最大单块大小（如 Nginx 的 client_max_body_size、Spring 的 spring.servlet.multipart.max-request-size），前端切片不能超这个值
注意：某些 CDN 或 WAF 会额外限制单次请求体，比如阿里云 SLB 默认 10MB，超了直接 413，得提前对齐

上传中断后怎么续传？关键不在 HTML，而在 JS 状态管理

续传能力跟 <input type="file"> 无关，全靠 JS 记录已成功上传的 chunk_index 列表，并在恢复时跳过它们。HTML 层只需保证文件对象可复用（即不销毁 File 引用）。

立即学习“前端免费学习笔记（深入）”；

上传前生成唯一 uploadId（如基于文件 path + size + lastModified 的 hash），用于服务端识别同一文件的多次上传
每块上传成功后，本地存一份 { uploadId, uploadedChunks: [0,1,3] } 到 localStorage 或 indexedDB（后者更可靠）
重新开始时，先发个 GET /upload/status?upload_id=xxx 查询已传块，再对比本地记录，取并集去重
别依赖 input.files 在页面刷新后还存在——它会被清空，必须让用户重新选，但只要文件没变，uploadId 还能对上