文件上传必须设置enctype="multipart/form-data"，它是唯一支持二进制文件传输的编码类型；其他值如application/x-www-form-urlencoded或text/plain会导致文件内容损坏或丢失。
enctype 不是可选配置，它是文件上传能成功的前提。没设对，input type="file" 选了文件也传不到后端——表单会把文件当普通字符串发过去，后端收不到二进制流。
enctype="multipart/form-data" 是唯一合法值
文件上传必须用这个值，其他如 application/x-www-form-urlencoded 或 text/plain 都会丢文件内容。浏览器看到 enctype="multipart/form-data" 才会把文件拆成边界分隔的二进制块（boundary），并附上 Content-Disposition 和真实 Content-Type 头。
常见错误现象：req.files 为空、request.FILES 无数据、Node.js 的 multer 报 Unexpected field。
- 必须和
method="post"搭配，GET不支持文件传输 - 不能写成
enctype="MUTIPART/FORM-DATA"（大小写敏感，全小写才稳定） - 如果用了前端框架（如 React/Vue），别用
form原生提交，否则容易漏掉该属性；手动构建 FormData 时不用设它，但用原生<form></form>就必须显式声明
accept 属性不等于 MIME 校验
accept 只影响文件选择对话框的过滤界面，和最终 HTTP 请求里的 Content-Type 无关。它既不控制浏览器发什么 MIME，也不影响服务端收到的 Content-Type 字段值。
例如：<input type="file" accept="text/html"> 选一个 report.html，浏览器可能发 Content-Type: text/html；但如果用户改后缀为 report.jpg 再选，也可能发 Content-Type: image/jpeg——这取决于系统注册的 MIME 映射，不是你写的 accept 决定的。
-
accept=".html,.htm"和accept="text/html"效果不同：前者靠扩展名匹配，后者靠系统 MIME 注册表，后者更准但不可控 - 不要在前端依赖
file.type判断真实类型——它来自操作系统，可被绕过；比如空文件、无扩展名、或伪造注册表项都会让这个值失效 - 真正要校验的，是服务端读取文件前几百字节，用
libmagic或file命令识别真实 MIME，而不是信任请求头里的Content-Type
服务端收到的 Content-Type 不可信
HTTP 请求中文件字段的 Content-Type 头（即 multipart body 里每个 part 的 Content-Type）完全由客户端生成，可任意篡改。Flask 的 request.files['f'].mimetype、Express 的 req.file.mimetype 都直接反射这个头，不能用于安全判断。
典型风险场景：上传一个 JS 文件，把扩展名改成 .html，再伪造 Content-Type: text/html，就能绕过只检查 mimetype 的逻辑。
- Node.js 中，用
busboy或formidable接收原始 buffer 后，再调用file-type库解析魔数 - Python 中，用
python-magic（libmagic 绑定）读取request.files['f'].read(1024)，比只看.filename或.mimetype可靠得多 - 即使校验通过，也要重命名文件（如 UUID + 固定后缀），并存到非 Web 直接可访问路径，防止上传 HTML 后被浏览器执行
最易被忽略的一点：很多人以为设了 accept 和 enctype 就算完成 MIME 控制，其实真正的防线只在服务端读取文件头那几十字节——其余全是提示或装饰。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
