fetch拿不到formdata是因为未手动构造——正确做法是new formdata(form)，确保控件有name属性；post时勿设content-type，浏览器会自动生成含boundary的multipart头；需手动检查response.ok处理业务错误；防重复提交应使用issubmitting布尔变量控制请求发起。
Fetch提交表单时为什么拿不到FormData？
因为原生fetch不自动序列化表单字段，必须手动构造FormData对象——直接传form元素不行，传form.elements也不行。
正确做法是用new FormData(form)，它会自动读取所有带name属性的控件值（包括file、checkbox、multiple select等）。
- 确保每个输入控件都有
name属性，否则FormData会忽略它 - 禁用按钮（如
type="submit"）不会被包含，这是浏览器标准行为 -
disabled的控件也不会被收集，如需强制提交，得临时移除disabled
POST请求头要不要设Content-Type？
不用设，甚至不该设。当用FormData作为body时，浏览器会自动生成正确的multipart/form-data头，并附带动态boundary。
如果手动加了headers: {'Content-Type': 'multipart/form-data'}，反而会导致后端收不到数据——因为缺了boundary，服务端无法解析分段。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 只在发送纯JSON时才显式设置
Content-Type: application/json - 上传文件时必须用
FormData，不能转成JSON字符串 - 若后端要求
application/x-www-form-urlencoded，可用new URLSearchParams(new FormData(form))代替
如何处理Fetch失败和后端校验错误？
fetch只在网络异常（如断网、DNS失败）时reject，HTTP状态码如400、500仍算“成功”，必须手动检查response.ok或response.status。
后端返回的表单校验错误（比如邮箱格式不对），通常放在响应体里，需用response.json()或response.text()读取。
-
!response.ok是判断业务失败最简方式，比只看status >= 400更稳妥 - 后端返回
422 Unprocessable Entity时，response.json()大概率能拿到字段级错误信息 - 别忘了用
catch捕获网络层异常，比如TypeError: Failed to fetch
防止重复提交的关键在哪？
不是靠禁用按钮（容易被绕过），而是靠在fetch发起前标记“已提交中”，并在finally里重置——这样即使用户快速连点、刷新页面，也能避免多发请求。
注意：仅靠button.disabled = true不够，因为用户可能用回车提交、或用开发者工具删掉disabled属性。
- 用一个布尔变量（如
isSubmitting）控制是否允许发起新请求 - 在
fetch调用前判断，为true则直接return - 在
finally块里把isSubmitting设回false，不然出错后按钮永远卡住
FormData的边界行为、fetch对HTTP状态码的沉默处理、以及前端防重逻辑的落地细节，三者叠加最容易漏掉。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
