text/plain enctype 不支持文件上传，浏览器仅发送文件名字符串而非二进制数据，后端无法获取文件内容；它仅适用于调试表单原始值，不可用于生产环境文件传输。
text/plain enctype 会把文件输入变成纯文本名
设 enctype="text/plain" 后， 字段不会发送二进制内容，浏览器只发一个字符串——就是你选的文件名（比如 "report.pdf"），不带任何文件数据。后端收到的只是名字，不是文件本身。
- 空格会被转成
+，但中文、emoji、斜杠等特殊字符不编码，可能触发解析错误 -
Content-Type请求头仍是text/plain，但实际 body 是键值对格式：username=admin&avatar=report.pdf（注意没有 boundary） - W3C 明确说明该类型“不支持文件上传”，主流框架（如 Express + multer、Django
request.FILES）压根不处理这种请求体
浏览器对 text/plain 的实现非常有限
几乎所有现代浏览器（Chrome/Firefox/Safari/Edge）都忽略 text/plain 在含 type="file" 表单中的语义——它既不触发文件读取，也不构造 multipart boundary，更不会流式传输。你看到的请求体，本质是把所有字段值拼成一行，用换行分隔，但实际发送时仍走 URL 编码逻辑的变体。
- 开发者工具 Network 面板里能看到
Content-Type: text/plain，但 payload 里找不到filename=或Content-Type:子头，证明它没走 multipart 流程 - 若表单同时有
method="GET"，整个行为退化为 query string 拼接，文件字段直接被丢弃（GET 不支持 body） - IE 和旧版 Edge 完全不支持
text/plain提交，会 fallback 到默认的application/x-www-form-urlencoded
为什么不能用 text/plain 绕过大文件限制
有人误以为换 enctype 能“轻量化”上传，但 text/plain 对请求大小、分片、超时、内存占用毫无影响——它只是改变了序列化规则，而浏览器提交机制本身仍按原策略打包整个表单数据（包括你选的大文件路径字符串）。真正卡住上传的，从来不是编码类型，而是 这种阻塞式同步提交。
- 哪怕你只传一个 1KB 的文件名字符串，只要表单里有
，浏览器仍会尝试读取整个文件并决定是否允许提交（受maxFileSize等 UA 限制） -
text/plain不提供流式传输能力，也不触发fetch或XMLHttpRequest的进度事件，无法监控或中断 - 服务端如果硬要解析
text/plain表单，得自己写 parser，且无法还原原始文件字节
text/plain 唯一可用的场景是调试表单原始值
它唯一靠谱的用途，是在开发阶段快速观察用户输入的原始字符串长什么样：空格是否保留、换行是否生效、特殊字符是否被转义。但一旦涉及文件、二进制、非 ASCII 文本，立刻失效。
- 测试时可临时加
enctype="text/plain"，配合console.log(event.target.elements)查字段值，但上线必须切回multipart/form-data - 不要在生产环境用它做“兼容降级”——没有后端框架能可靠反向兼容这种格式
- 如果真需要纯文本提交（比如日志上报），直接用
fetch发 JSON，别套
真正需要上传文件时，enctype 只能是 multipart/form-data；其他两个值都是纯文本通道，连“通道”都算不上——它们根本没设计承载文件的能力。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
