HTML表单不支持分片上传，必须用File.slice()手动切片并配合fetch或XMLHttpRequest逐片发送；需限流并发、携带Content-Range头、避免整文件加载。

HTML 本身不支持“跨表单提交大文件”——<form></form> 提交是原子操作，无法切片、无法中断、无法监听进度。所谓“跨表单”，本质是放弃表单，改用 File.slice() 手动分片 + fetch 或 XMLHttpRequest 逐片发送。

为什么不能在

里做分片上传

浏览器对 enctype="multipart/form-data" 的处理是封闭的：选中文件后，整个 File 对象被锁定；调用 form.submit() 时，底层直接序列化全部内容为 multipart boundary 流，中间不可插入切片逻辑，也不响应 XMLHttpRequest.upload.onprogress。你传进去的是一个 File，它吐出来的就是一个完整请求体，没得商量。

• 试图给 <input type="file"> 绑定 change 后再用 FormData.append("file", file) 仍会触发整文件内存加载，尤其多文件时极易 OOM
• FormData.append("files", input.files) 看似批量，实则让浏览器为每个 File 保留完整引用，内存压力翻倍
• 服务端收到的永远是完整 multipart，没有 Content-Range、没有 chunkIndex，断点续传无从谈起

真正可行的分片入口只有 File.slice()

所有可控分片必须从 File.prototype.slice() 开始。它返回一个新 Blob，参数是字节偏移量（不是 MB 或字符），且 end 是开区间（不包含）。

• 务必用 Math.min(start + chunkSize, file.size) 防越界，否则最后一片可能抛 InvalidStateError
• 推荐分片大小：内网 5–10MB，百兆宽带 1–2MB，弱网环境 ≤1MB；太小导致 HTTP 头占比过高，太大易触发单次读取内存峰值
• 旧浏览器需兼容：file.webkitSlice?.(start, end) 或 file.mozSlice?.(start, end)，现代环境可直用 slice
• 别用 readAsDataURL 或整文件 readAsArrayBuffer，那是提前把炸弹拉响

并发上传必须限流，不能 Promise.all 全扔出去

1GB 文件切成 200 片，Promise.all(chunks.map(upload)) 会瞬间发起 200 个请求，远超浏览器同域并发上限（Chrome 默认 6），结果是大量连接挂起、内存暴涨、页面无响应。

DeepBI DHTML 页面生成器

生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

下载

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

• 安全并发数建议 3–5 路：用 Promise.allSettled + 固定长度队列，每次只保持最多 4 个请求在飞，完成一个再补一个
• 每个请求必须独立创建 fetch 或 XMLHttpRequest 实例，上传完立即设为 null，避免实例堆积
• 每片请求头必须带 Content-Range，例如 bytes 0-5242879/1073741824，服务端靠它定位写入位置
• 每片都要新建 FormData，再 .append('file', blob)，复用实例会导致 blob 引用错乱

fetch 和 XMLHttpRequest 在分片场景的关键差异

两者都能用，但细节决定稳定性：

• fetch 默认不支持上传进度监听，需手动包装 ReadableStream + TransformStream，复杂度高；XMLHttpRequest.upload.onprogress 开箱即用
• XMLHttpRequest.abort() 更可靠；fetch 中 AbortController 对已发出请求的终止效果依赖浏览器实现，部分旧版可能无效
• 若服务端要求自定义 header（如 X-Upload-Chunk-Index），fetch 可直接设置；XMLHttpRequest 需确认服务端是否允许该 header（CORS 预检可能失败）

真正麻烦的从来不是前端切片，而是服务端如何按 Content-Range 原子写入、如何校验分片完整性、如何合并时不覆盖错位、如何清理临时文件——前端只要把每片干净、有序、可重入地送出去就行；漏掉 Content-Range 或错用 multipart/form-data 包裹单片，后端就彻底没法识别。