enctype="multipart/form-data"是文件上传的硬性前提，只要表单含<input type="file">就必须显式设置且method为POST；否则浏览器静默丢弃文件字段，后端收不到任何二进制内容。
enctype="multipart/form-data" 是上传文件的硬性前提
只要表单里有 <input type="file">，就必须显式写 enctype="multipart/form-data"。不写、写错（比如拼成 mutlipart/form-data）、或依赖默认值，都会导致后端收不到文件——req.file 是 undefined，request.files 为空，$_FILES 里没有对应项。
这不是后端框架没配好，而是浏览器压根没把文件字节发出去。前端提交时看似正常，但请求体里只有文本字段，文件字段被静默丢弃。
-
method必须是POST；GET不允许带 body，设了也无效 - 即使表单同时含文本输入框和文件输入框，也必须统一用
multipart/form-data，不能“部分用默认编码” - ASP.NET Web Forms 中通过
HtmlForm.Enctype设置，注意大小写：必须是"multipart/form-data"，不是"Multipart/Form-Data"
application/x-www-form-urlencoded 是默认值，但会破坏文件上传
不写 enctype 就等于 enctype="application/x-www-form-urlencoded"。它把所有字段转成 key1=value1&key2=value2 格式，URL 编码空格、中文、emoji 等——这对纯文本表单没问题，但对文件完全失效。
你选了文件，<input type="file"> 的 value 在这个编码下只显示文件名（如 "avatar.jpg"），不包含任何二进制内容。后端收到的只是个字符串，不是文件流。
- 适合场景：登录、搜索、分页、纯文本编辑等无文件交互
- 不适合传 Base64 字符串：体积膨胀约 33%，且可能被代理截断
- 字段值若本身含
&或=，会被误切分——这是协议限制，不是 bug
text/plain 几乎不该出现在生产环境
enctype="text/plain" 只会把字段原样拼成 username=john doe\nage=25 发送，不编码、不加 boundary、不支持文件。现代框架（Express、Flask、ASP.NET）基本不解析它，浏览器实现也不一致。
唯一合理用途：临时调试，想肉眼确认浏览器到底发了什么原始字符。但它不能替代 console.log(new FormData(form))，更不能用于真实交互。
- 如果后端收不到任何字段，先检查是不是误设成了
text/plain - 它不被
fetch或XMLHttpRequest的FormData自动识别 - 别指望它解决中文乱码——它只是把乱码原样发过去
formenctype 属性能覆盖单个按钮的编码行为
同一个表单里，有时需要“纯文本提交”和“带文件提交”共存。这时不用拆成两个 <form>，直接给提交按钮加 formenctype：
<form id="myForm"> <input name="title"> <input type="file" name="cover"> <button type="submit">仅提交标题</button> <button type="submit" formenctype="multipart/form-data">连封面一起提交</button> </form>
注意：formenctype 只影响该按钮触发的提交，其他按钮仍走 <form> 的 enctype 值。这个特性在混合操作场景中很实用，但容易被忽略。
真正容易出问题的地方不在语法，而在于：很多人以为“后端能自动适配”，结果卡在“为什么文件字段总是空”。其实浏览器打包方式决定了后端能不能拿到字节——这个开关，必须由前端明确打开。
