form 的 enctype 属性到底该设成什么
浏览器提交表单时用什么编码方式，完全由 form 元素的 enctype 属性决定，不是由页面 <meta charset> 或 HTTP 头控制的。它只影响表单数据如何被序列化发送，和服务器端怎么解析直接挂钩。
-
enctype="application/x-www-form-urlencoded"（默认值）：所有字段名和值都会被 URL 编码（空格→%20，中文→%E4%BD%A0等），拼成类似name=%E4%BD%A0&file=&city=shanghai的字符串。适合纯文本字段，但无法上传文件 -
enctype="multipart/form-data"：每个字段单独分块，带边界标识（boundary），原样传输二进制内容。必须用这个才能让<input type="file">正常工作 -
enctype="text/plain"：几乎没人用。字段用换行分隔，空格不编码，值里有换行会直接破坏格式，服务端极难可靠解析
为什么 enctype="multipart/form-data" 上传文件后后端收不到字段
常见现象是：表单里既有 <input type="file"> 又有普通文本框，设了 enctype="multipart/form-data"，但后端只拿到文件，其他字段全空。
- 不是前端漏传，是后端没正确解析 multipart 格式——比如用读取 raw body 的方式去解析，而不是调用框架提供的
formdata或request.files/request.form接口 - Node.js 的
express默认不处理 multipart，得加multer；Python Flask 默认支持，但要用request.form.get('xxx')取文本字段，request.files.get('xxx')取文件 - 如果混用
fetch+FormData提交，不用手动设enctype，浏览器会自动设对，且自动加正确的Content-Type头（含 boundary）
用 fetch 提交表单时要不要手动设置 Content-Type
不要。只要传的是 FormData 实例，浏览器会自动设置 Content-Type: multipart/form-data; boundary=----...，并按需组织请求体。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 手动加
headers: {'Content-Type': 'multipart/form-data'}反而会出错：浏览器发现你指定了不带boundary的类型，就放弃自动构造，发一个空 body 或报错 - 想确认是否生效？打开 DevTools → Network → 点开请求 → Headers → 查看
Content-Type字段，里面一定有boundary=后缀 - 如果后端收不到数据，先检查是不是用了
JSON.stringify()把FormData转成了字符串——那它就不再是FormData了，浏览器不会特殊处理
表单编码和页面字符集（<meta charset>）的关系
它们管的是两件事：<meta charset> 决定 HTML 文件本身怎么解码（比如中文标签、占位符文字是否显示正常），而 enctype 决定表单数据提交时怎么编码。
立即学习“前端免费学习笔记（深入）”；
- 即使页面是
UTF-8，用默认application/x-www-form-urlencoded提交中文，浏览器依然会把它转成 UTF-8 编码再 URL 编码（如“你好”→%E4%BD%A0%E5%A5%BD） - 服务端收到后，必须用 UTF-8 解码 URL 编码部分，否则就是乱码。PHP 要设
mb_internal_encoding('UTF-8')，Node.js 的querystring.parse()默认就是 UTF-8 - 如果页面是
GBK，但表单用了enctype="multipart/form-data"，文件名里的中文仍按页面编码读取——这时后端更易乱码，尽量统一用 UTF-8
enctype，后端就得用对应方式解析，少一个环节就丢数据。尤其是 multipart 场景下，字段和文件在同一个请求里，但解析路径完全不同。 
