enctype="multipart/form-data"是文件上传的硬性前提，仅确保浏览器发送二进制数据而非[object file]，但不解决大文件内存占用、分片或进度控制问题；真正可靠的大文件上传必须绕开表单，用file.slice()手动分片并配合fetch/xhr上传。
enctype="multipart/form-data" 是大文件上传的硬性前提，但不解决内存问题
只要表单里有 <input type="file">，就必须设 enctype="multipart/form-data"，否则浏览器根本不会发送文件二进制数据——它只会把字段变成 [object File] 或空字符串。但这只是“能传”，不是“能稳传”。enctype 本身不控制内存占用、不支持分片、不提供进度监听，它只定义请求体格式：多部分边界（boundary）包裹每个字段，包括文件内容。
常见错误是以为加了这个属性就能上传 1GB 文件。实际上，浏览器会把整个文件读进内存再打包发出去，Chrome 在 500MB+ 就可能卡死或报 RangeError: Maximum call stack size exceeded。这不是后端配置问题，是 HTML 表单提交机制本身的限制。
为什么不能靠调整 enctype 值来优化大文件上传
enctype 只有三个合法值：application/x-www-form-urlencoded（默认，不传文件）、multipart/form-data（唯一支持文件）、text/plain（W3C 标准中不支持文件上传）。试图用 text/plain 或伪造其他值，结果都是后端收不到文件内容，甚至直接 400 错误。
-
application/x-www-form-urlencoded会 URL 编码所有内容，文件变成无意义字符串，后端无法还原 -
text/plain不被任何主流浏览器用于文件上传，<input type="file">在这种模式下等同于失效 - 改
enctype不影响请求大小限制、不分片、不流式传输——这些都由浏览器底层提交逻辑决定，前端无法干预
真正影响大文件上传的是提交方式，不是 enctype
想传大文件，必须放弃 <form>.submit()</form> 这种原生提交。因为一旦调用，控制权就交给浏览器，你再也插不进切片、校验、重试或进度反馈逻辑。
可行路径只有一条：拿到 File 对象，用 file.slice(start, end) 手动切片，再用 fetch 或 XMLHttpRequest 单独发每一片。关键点：
- 每片大小建议
5 * 1024 * 1024（5MB），太小 HTTP 开销占比高，太大单次读取易爆内存 - 必须用
Math.min(start + chunkSize, file.size)防越界，最后一片容易InvalidStateError - 并发数严格限制在 3–5 路，
Promise.all直接扔 200 片会压垮浏览器连接池 - 每片请求头必须带
Content-Range，如bytes 0-5242879/1073741824，服务端靠它拼接
enctype 的实际作用仅止于“让文件能被发出”
它的价值只体现在请求发出那一刻：告诉浏览器“接下来要构造一个带 boundary 的 multipart 请求体”。至于这个请求体有多大、含几个文件、是否超时、失败后怎么续，enctype 完全不管。
容易被忽略的细节：
-
enctype必须写在<form></form>标签上，写在<input>上无效 - 即使表单里混着文本字段（如
<input name="title">），它们也会和文件一起被打包进同一个 multipart 请求，不用额外处理 - 如果用了 Vue/React 等框架的表单拦截（比如
@submit.prevent），但没手动构造FormData或调用fetch，那enctype就形同虚设——请求还是普通 POST
真正卡住大文件上传的，从来不是 enctype 写没写对，而是有没有意识到：它只是起点，不是解法。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
