HTML原生表单无法设置自定义Headers，因浏览器规范强制限制；method和enctype仅影响HTTP动词与Content-Type，无法添加Authorization等头；需用fetch手动传headers，且FormData不携带Headers。
HTML原生表单无法设置自定义Headers，这是浏览器规范强制限制，任何尝试在<form>标签里加headers属性或类似写法都无效。
为什么form的method和enctype不能替代Headers
很多人误以为设了method="POST"、enctype="multipart/form-data"就能控制请求头，其实它们只影响Content-Type这一项，且是浏览器自动推导的——你没法用HTML声明Authorization、X-Request-ID或Accept。这些字段必须由JavaScript发起的请求（如fetch）显式传入headers选项。
-
method只决定HTTP动词，不参与Headers构造 -
enctype仅影响Content-Type的取值，且值固定为application/x-www-form-urlencoded、multipart/form-data或text/plain，无法扩展 - 哪怕你在
<form action="/api" method="POST">里加data-headers='{"X-Token":"abc"}'，浏览器也完全忽略——它不是标准属性
fetch提交时Headers必须手动传，且FormData不能自动带
用fetch替代原生提交后，Headers要自己写进fetch()第二个参数的headers对象里。注意：new FormData(form)本身不含Headers，它只是数据载体；Content-Type由浏览器根据body类型自动设置，你不能也不该手动覆盖它（尤其对multipart/form-data）。
- 正确写法：
fetch("/api", { method: "POST", body: new FormData(form), headers: { "Authorization": "Bearer " + token } }) - 错误写法：
headers: { "Content-Type": "multipart/form-data" }——这会破坏文件上传，浏览器必须自动生成边界符 - 如果后端要求
Accept: application/json，必须显式加，否则默认是*/* - 自定义Header名含下划线（如
X-API-Key）没问题，但Cookie、Origin等敏感头会被浏览器屏蔽，无法手动设置
CSRF Token这类关键Header怎么安全注入
CSRF Token通常存在<meta name="csrf-token" content="xxx">或隐藏<input>里，但它不能直接变Header——必须由JS读取后拼进fetch的headers。容易踩的坑是Token过期没校验，或从dataset读错字段。
立即学习“前端免费学习笔记（深入）”；
- 推荐方式：从
<meta>读取，document.querySelector('meta[name="csrf-token"]').getAttribute('content') - 避免从
input[data-csrf]读——data-属性不参与提交，且易被JS动态修改导致不一致 - Token为空时
fetch应直接拒绝，而不是发一个无Token的请求（后端403不如前端拦截） - 不要把Token存在
localStorage再读取——跨域或iframe场景下可能拿不到，且增加XSS泄露风险
真正难的不是加Header，而是确保它每次提交都新鲜、可验证、不被绕过。比如Token从页面加载时取一次就复用，结果用户长时间停留后失效；或者多个表单共用一个<meta>却没做并发更新，导致其中一个提交失败。这些细节比语法更关键。
