form enctype="application/json"在现代浏览器中不能可靠使用，主流浏览器（Chrome 125+、Firefox 127+、Safari 17.5+）仅实验性支持，仍会降级为application/x-www-form-urlencoded；真正可行的是fetch()+event.preventDefault()或hidden字段+后端解析。
form enctype="application/json" 在现代浏览器中到底能不能用
不能直接用，除非你明确知道目标浏览器支持 HTML Living Standard 中尚未完全落地的 enctype="application/json" 提案。当前（2026年6月）主流浏览器（Chrome 125+、Firefox 127+、Safari 17.5+）对它的支持仍是实验性或部分实现：表单字段会被序列化为 JSON，但 submit 事件仍会触发原生提交逻辑，且无法控制请求头中的 Content-Type —— 浏览器仍可能降级为 application/x-www-form-urlencoded，尤其在 redirect 或 target 等场景下。
常见错误现象：enctype="application/json" 写了，但抓包发现请求头是 Content-Type: application/x-www-form-urlencoded，后端收不到 JSON body；或者字段名含方括号（如 user[name]）时，JSON 结构被错误扁平化。
- 该特性依赖浏览器对 HTML spec 中 enctype=json 的定义 的完整实现，目前仅 Chromium 128+ 在 strict mode 下稳定支持
- 即使支持，
<input type="file">与enctype="application/json"互斥，混合使用会直接退回到默认编码 - 服务端若未显式检查
req.headers['content-type'] === 'application/json'，而是只按传统方式解析req.body（如 Express 的urlencoded()中间件），就会漏掉整个 JSON body
为什么 fetch() + event.preventDefault() 是更可靠的选择
因为它是唯一绕过浏览器表单编码限制、完全掌控请求头和请求体的方式。关键不在“怎么写 fetch”，而在“怎么拦截并接管 submit 行为”。
典型错误是绑了 submit 事件却不调用 event.preventDefault()，导致表单先走原生提交（跳转/刷新），再执行 fetch（无效或重复请求）。
- 必须用
<button type="button">或显式event.preventDefault()阻止默认行为 -
fetch()的body必须是字符串：JSON.stringify({id: 1, tags: ["a"]})，传对象会报TypeError: Request with GET/HEAD method cannot have body - 必须手动设置
headers: {'Content-Type': 'application/json'}，否则 Express、Spring Boot 等框架不会触发@RequestBody解析逻辑 - 如果表单含文件，
fetch()无法直接处理File对象 → 改用FormData+multipart/form-data，此时 JSON 字段只能作为普通文本字段塞进去，不能混在 JSON body 中
用 hidden input 塞 JSON 字符串的实操要点
这是兼容性最强的折中方案：保持原生 <form> 提交，把 JSON 当作一个字段值传过去，后端负责 JSON.parse()。但它对内容安全和结构完整性要求极高。
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
常见错误：直接写 <input name="payload" value='{"user": "Alice's account"}'> → 单引号破坏 HTML 属性边界，导致 DOM 解析失败或 XSS 漏洞。
- 前端必须先
JSON.stringify()，再做 HTML 实体转义（如用DOMPurify.sanitize()或textContent方式生成元素） - 字段名建议用语义明确的名称，如
payload、json_data，避免与普通字段（如name、email）冲突 - 后端收到后，必须校验该字段存在、非空、且能被
JSON.parse()成功解析；否则抛SyntaxError会导致 500，应捕获并返回 400 - 注意：换行、Unicode 控制字符（如
\u2028）、HTML 特殊符号（<,>）都需在序列化前处理，否则可能被浏览器截断或解析异常
后端如何统一兼容 form 和 JSON 提交
不要指望前端“选对 enctype”来决定后端逻辑，而应在服务端根据 Content-Type 头自动分流。Spring Boot 和 Express 都支持这种模式，但需主动配置，不是开箱即用。
典型陷阱：写了 @RequestBody User user，却没处理 application/x-www-form-urlencoded 场景，导致表单提交 400 或空对象。
- Spring Boot：需自定义
HandlerMethodArgumentResolver，检查request.getContentType()，匹配application/json时走@RequestBody，匹配application/x-www-form-urlencoded时走@ModelAttribute或手动解析request.getParameterMap() - Express：禁用默认
urlencoded()中间件的extended: false模式，改用raw()中间件读取原始 body，再根据req.headers['content-type']分支处理：application/json→JSON.parse(req.body)，application/x-www-form-urlencoded→querystring.parse(req.body.toString()) - 无论哪种方案，都必须对 JSON 字段做严格 schema 校验（如用 Joi、Zod），因为前端塞进 hidden input 的 JSON 可能被篡改或格式错误
最易被忽略的一点：当表单同时含文件和 JSON 数据时，multipart/form-data 编码下 JSON 字符串只是普通文本字段，无法自动还原为嵌套对象——后端必须手动提取该字段再解析，且要处理好文件流和文本字段的并发读取顺序。
