分片上传是唯一可行方案，因直接上传超大文件会触发前端OOM、后端413错误、Nginx拦截及PHP超时；需前端用File.slice()切2–5MB分片并流式读取，后端提供分片接收、状态查询与合并三类接口，并实现并发控制、断点续传及精准错误重试。
直接上传超大文件（比如 5GB+）在纯 HTML 表单里根本走不通——enctype="multipart/form-data" 会把整个文件塞进内存或临时磁盘，前端卡死、后端 413、Nginx 拦截、PHP 超时，全都会炸。必须用分片上传（chunked upload），这是唯一能落地的方案。
为什么不能用 <input type="file"> 直传
浏览器对 input[type="file"] 本身没大小限制，但后续链路层层设卡：
-
XMLHttpRequest或fetch发送整个File对象时，会尝试加载全部内容到内存，10GB 文件直接触发 OOM，页面无响应 - 服务端如 PHP 的
post_max_size、Node.js 的body-parser默认只收几 MB - Nginx 的
client_max_body_size默认 1MB，Apache 的LimitRequestBody同样极小 - 即使调高所有阈值，单次 HTTP 请求仍不可靠：网络抖动、超时、代理中断都会导致整传失败，重试成本极高
怎么用 File.slice() 安全切片
核心是绕过「读全量」，只取一段二进制做上传单元。关键点不是“怎么切”，而是“怎么切不崩”：
- 每片控制在
2 * 1024 * 1024到5 * 1024 * 1024（2–5MB），太小增加请求数，太大拖慢 FileReader 释放 - 别用
file.size做循环上限——它可能不准；用Math.ceil(file.size / chunkSize)算总片数 -
file.slice(start, end)返回新Blob，不是修改原文件，start/end 单位是字节，不是字符或行号 - 每次
FileReader用完立刻设为null，否则并发多片时 GC 来不及回收，内存持续上涨
示例片段：
立即学习“前端免费学习笔记（深入）”；
const chunk = file.slice(0, 2 * 1024 * 1024);
const reader = new FileReader();
reader.onload = () => {
uploadChunk(reader.result, 0); // ArrayBuffer
};
reader.readAsArrayBuffer(chunk);服务端必须支持分片状态管理
前端分片只是第一步，后端若还按传统方式接收 multipart，等于白干。关键接口要三类：
-
POST /upload/chunk：接收单片 + 元数据（fileId、index、total、size），校验后落盘为临时分片文件（如xxx_001.part） -
HEAD /upload/status?fileId=xxx：返回已传分片范围（用Content-Range: bytes 0-2097151/10485760格式），供前端跳过已传片 -
POST /upload/merge：收到全部分片后合并，校验SHA-256总哈希，成功才返回最终文件 ID
注意：fileId 不能用 name + size 拼接——重名冲突；推荐用首 1MB 内容哈希 + lastModified 组合生成，浏览器用 crypto.subtle.digest() 算，服务端复现校验。
并发控制和断点续传容易被忽略的坑
并发不是越多越好，浏览器对同域并发请求有硬限制（Chrome 默认 6 个），盲目 Promise.all 会导致大量请求 pending 或被 cancel：
- 硬限并发数为
3或5，用 Promise 队列（如p-limit）串行调度，避免连接池打满 - 每个请求带
AbortSignal，用户点暂停时能立刻中止 pending 请求，而不是等 timeout - 断点续传依赖客户端持久化状态：上传中崩溃后，必须从
sessionStorage或IndexedDB恢复uploadedChunks集合，否则重头开始 - 服务端返回
400但没说明哪片错？前端要解析响应体里的错误字段（如{"chunkIndex": 42, "reason": "hash_mismatch"}），精准重传而非全量重试
真正难的从来不是“怎么传”，而是“传一半断了怎么办”和“怎么让服务端不以为你在发洪水”。分片只是工具，状态同步、错误定位、资源清理，才是超大文件上传稳不稳的关键。
