text/plain 编码仅将空格转为+，其余字符（含中文、emoji、引号、换行）原样发送；现代Web框架默认不解析它，需手动读取原始流，无字段结构，不适用于生产，仅用于调试原始字节流。
text/plain 的编码行为到底是什么
它不是“不编码”，而是只做最基础的空格转 +，其余字符（包括中文、emoji、引号、换行）原样发送，不做 URL 编码。比如输入 hello 世界\n"test"，请求体里就是原样这串字符，中间的空格变成 +，但 世 和 \n 都没被转义。
为什么浏览器不报错，但后端几乎收不到有效数据
现代 Web 框架（Express、Flask、Django、Spring Boot）默认只解析 application/x-www-form-urlencoded 和 multipart/form-data 两种 Content-Type。遇到 text/plain，它们通常：
- 直接忽略整个请求体，
req.body为空对象或undefined - 不触发任何解析中间件（如
body-parser、express.json()） - 需手动读取原始流（
req.on('data', ...)或req.rawBody），且无字段名/值结构可言
它真能用于“轻量化提交”吗
不能。所谓“轻量”是错觉——text/plain 并不节省体积，也不提升性能：
- 空格变
+是冗余操作，没压缩效果 - 中文等字符仍以 UTF-8 字节流发送，体积和
application/x-www-form-urlencoded相当甚至更大（后者会把中文转成%E4%B8%96这类短码，而text/plain就是原始字节） - 没有字段边界，多个 input 会连成一片，比如
name=alice&age=25在text/plain下变成name=alice age=25，根本无法安全拆分
真正轻量的替代方案是：用 fetch 发 JSON（Content-Type: application/json），或坚持用默认 application/x-www-form-urlencoded —— 它有标准解析、字段隔离、框架原生支持。
唯一靠谱的使用场景：临时调试原始字节流
仅当你要确认浏览器实际发了什么字符（比如排查空格/换行是否被前端 JS 截断、验证特殊符号是否损坏），才用 enctype="text/plain" 搭配一个极简后端（如 Python 的 http.server 或 Node.js 的 http.IncomingMessage），手动打印 req.rawHeaders 和 req.pipe(process.stdout)。它不是生产方案，也不解决任何真实工程问题。
别把它当成“更简单”或“更原始”的选项——它的存在意义，就是让你看清其他两种编码方式在掩盖什么。
