必须设 enctype="multipart/form-data" 的唯一场景是表单中使用了 ；其他编码类型无法传输文件字节，即使混有文本字段也必须设置该值，且 asp.net 中需注意大小写。
enctype 属性决定浏览器如何把表单数据“打包”发给服务器——不是可有可无的装饰，而是直接影响后端能否正确收到文件、中文、二进制内容的关键开关。
什么时候必须设 enctype="multipart/form-data"
只有一种场景非设不可：表单里用了 <input type="file">。其他编码类型（比如默认的 application/x-www-form-urlencoded）根本无法传输原始文件字节，后端收不到文件，甚至可能直接丢弃整个请求体。
- 即使表单同时含文本字段和文件字段，也必须设为
multipart/form-data，不能只靠后端“兼容” -
formenctype属性可在单个提交按钮上覆盖该设置，适合同一表单内混用“纯文本提交”和“带文件提交”两种行为 - ASP.NET Web Forms 中通过
HtmlForm.Enctype属性设置，赋值时需注意大小写（如"multipart/form-data"，不是"Multipart/Form-Data"）
application/x-www-form-urlencoded 是怎么“编码”的
这是浏览器默认值，所有字段名和值都会被 URL 编码（空格变 +，中文变 %E4%BD%A0），再拼成 key1=value1&key2=value2 这样的字符串放进请求体。它轻量、高效，但不支持文件，且对二进制数据或大量文本不友好。
- 后端解析时通常自动解码，但若字段值本身含
&或=，可能被误切分——这不是 bug，是协议设计使然 - 在 ASP.NET 中，如果没显式设置
HtmlForm.Enctype，就等同于留空字符串，浏览器按默认规则处理 - 不要试图用它传 Base64 字符串：体积膨胀约 33%，还可能因长度超限被中间代理截断
text/plain 看似简单，其实最危险
它把字段原样拼成 key1=value1\nkey2=value2 发过去，不编码、不转义、不加边界。规范明确说明：该类型“仅供调试使用”，浏览器实现差异大，多数现代框架（包括 ASP.NET）压根不解析这种格式。
- Chrome 和 Firefox 对
text/plain的实际行为不一致，有的忽略换行，有的保留但不识别字段结构 - 如果你看到表单提交后后端收不到任何值，先检查是不是误设成了
text/plain - 它不能用于生产环境的任何实际交互，连日志调试都建议改用
console.log(new FormData(form))
ASP.NET Web Forms 中设置 HtmlForm.Enctype 的坑
这个属性看着像普通控件属性，但它的生效时机和作用域容易被误解：它只影响该 <form runat="server"></form> 标签生成的最终 HTML 输出，不改变服务端控件的事件模型或 ViewState 传输机制。
- 在
Page_Load里动态赋值有效，但在Init阶段设可能被后续模板逻辑覆盖 - 如果页面用了母版页（Master Page），要确认
<form></form>标签确实由当前页面控制，而不是被母版页硬编码了enctype - 设完之后务必用浏览器开发者工具的 Network 面板看真实发出的请求头和请求体，别只信后端日志——很多问题出在请求根本没按预期发出
真正难的不是记住三种取值，而是每次加 <input type="file"> 时，条件反射去补上 enctype="multipart/form-data"；以及每次调试表单接收异常时，第一反应是打开 Network 面板看请求体结构，而不是立刻翻后端代码。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
