HTML原生表单不支持自定义请求头，这是浏览器安全限制；必须改用fetch+FormData模拟提交，或通过服务端中转代理实现。
HTML原生表单不支持自定义请求头（Custom Headers），这是浏览器安全模型的硬性限制，不是写法或配置问题。想在表单提交时加 Authorization、X-Request-ID 等 header，必须换方案。
为什么 form.submit() 无法设置 Custom Headers
浏览器对 <form> 的 submit() 行为做了严格约束：它只构造标准 HTTP POST/GET 请求，自动设置 Content-Type: application/x-www-form-urlencoded（或 multipart/form-data），但禁止脚本干预请求头。这是同源策略和 CSRF 防护的一部分，无法绕过。
-
form.action和form.method只控制目标 URL 和动词，不暴露 header 控制权 -
form.enctype只能间接影响Content-Type，不能新增 header - 任何尝试在
submit前用 JS 修改 header（如form.headers = {...}）都会被忽略
替代方案：用 fetch() + FormData 模拟表单提交
这是最常用、兼容性好（Chrome 42+、Firefox 39+、Safari 10.1+）、且能完全控制 header 的方式。关键点是复用原有表单 DOM 结构，不破坏语义和可访问性。
- 保留
<form>标签和所有name属性，确保无障碍支持和无 JS 降级能力 - 拦截
submit事件，阻止默认行为：event.preventDefault() - 用
new FormData(formElement)提取数据，自动处理input、select、textarea和文件字段 - 调用
fetch(url, { method: 'POST', headers: { 'Authorization': 'Bearer xxx' }, body: formData })
示例片段：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
document.querySelector('form').addEventListener('submit', async function(e) {
e.preventDefault();
const formData = new FormData(this);
const response = await fetch(this.action, {
method: 'POST',
headers: {
'Authorization': 'Bearer ' + localStorage.getItem('token'),
'X-Trace-ID': Date.now().toString()
},
body: formData
});
});
注意 FormData 与 JSON 的 Content-Type 差异
直接把 FormData 丢给 fetch 时，浏览器会自动设置 Content-Type: multipart/form-data; boundary=...，后端需按此格式解析。如果后端只认 application/json，就不能用 FormData，得手动序列化：
- 用
Object.fromEntries(new FormData(form))转成普通对象 - 再用
JSON.stringify()编码，并显式设置headers: { 'Content-Type': 'application/json' } - 但注意：文件字段会丢失——
File对象不能直接 JSON 序列化，必须用FormData或分步上传
服务端中转是唯一“假装用表单”的兜底方案
如果必须保持纯 HTML 表单行为（比如嵌入第三方页面、无法改前端逻辑），只能让请求先打到自己的后端接口，由它添加 header 后再代理转发：
- 前端
form.action改为指向自己域名下的中转 endpoint，如/api/forward - 中转接口接收
application/x-www-form-urlencoded或multipart/form-data，解析出参数 - 用 Node.js
axios或 Pythonrequests发起带 header 的二次请求 - 把响应透传回前端（注意处理状态码、CORS、超时）
这个方案增加延迟和运维负担，且 header 中的敏感信息（如 token）会短暂出现在你自己的服务日志里，需额外脱敏。
真正需要 Custom Headers 的场景，基本都意味着你已脱离传统表单范式——header 是身份、追踪、权限的载体，而原生表单设计初衷只是提交键值对。别强行封装，该切就切。
