HTML原生表单无法设置自定义请求头，如Authorization、X-Request-ID等；浏览器完全控制Header，前端无干预能力，必须改用fetch或XMLHttpRequest主动发起请求才能自定义头部。
HTML原生表单根本没法设自定义Header
直接说结论：<form> 标签和 <input type="file"> 本身不支持添加 Authorization、X-Request-ID 这类请求头。浏览器提交时走的是原生 multipart 表单流，连 Content-Type 都不允许你手动覆盖——它会自动加 boundary，你硬塞就会触发 Refused to set unsafe header "Content-Type" 错误。
常见错误现象：在 form 上写 headers 属性、或试图给 submit 事件加 fetch 并传 headers 却忘了禁用默认行为，结果表单照样刷新、JS 请求发了但没用。
- 所有通过
action+method直接提交的请求，Header 完全由浏览器控制，前端无干预入口 -
enctype="multipart/form-data"是必须的（尤其含文件），但它只影响请求体格式，不影响 Header - 跨域提交时，即使 action 写对了，没配好后端 CORS 响应头（如
Access-Control-Allow-Headers），自定义头也会被浏览器静默丢弃
用 fetch + FormData 替代 form.submit() 是最常用解法
绕过原生提交，改用 JS 主动构造请求，才能真正控制 Header。但要注意：fetch 对 Content-Type 有严格限制——只要你手动设了 headers: { 'Content-Type': 'multipart/form-data' }，浏览器就报错。
正确做法是：不传 headers 里的 Content-Type，让浏览器自动设；其他自定义头（如 Authorization）照常传。
立即学习“前端免费学习笔记（深入）”；
- 必须先
e.preventDefault()拦住原生提交，否则页面刷新，JS 请求白发 -
body直接传new FormData(form)，不要转成 JSON 或 URL 编码 - 后端必须支持 multipart 解析（如 Express 需
multer，ASP.NET Core 需绑定IFormFile） - 如果后端要求带凭证（如 Cookie），fetch 要加
credentials: 'include'，且响应头必须含Access-Control-Allow-Credentials: true
XMLHttpRequest 仍是兼容性更稳的选择
当项目还要支持 IE11 或旧版 WebView 时，XMLHttpRequest 比 fetch 更可靠，而且它的 setRequestHeader 对自定义头更宽容。
关键顺序不能错：必须在 xhr.open() 之后、xhr.send(formData) 之前调用 setRequestHeader。顺序反了，头就丢了。
-
xhr.setRequestHeader('Authorization', 'Bearer abc123')可以正常设 -
xhr.setRequestHeader('Content-Type', ...)会报错，别碰它——浏览器 sendFormData时自动设才合法 - 进度监听（
xhr.upload.onprogress）只有 XMLHttpRequest 支持，fetch没原生方案 - 注意
open()第三个参数必须为true（异步），false已废弃且阻塞主线程
后端没配对，前端再努力也白搭
前端设了头，但后端没在响应里回对应 CORS 头，请求照样被拦。尤其容易漏的是：Access-Control-Allow-Headers 必须显式列出你前端用的自定义头名，不能只写 *（带凭证时无效）。
- 例如前端用了
X-Upload-ID，后端响应头就得有Access-Control-Allow-Headers: X-Upload-ID - 如果用了
credentials: 'include'，后端Access-Control-Allow-Origin不能写*，得是具体域名 - Node.js + Express 示例：用
cors({ origin: 'https://your.site', credentials: true, allowedHeaders: ['Authorization', 'X-Upload-ID'] }) - ASP.NET Core 中，
services.AddCors()配置里也要明确WithExposedHeaders和AllowAnyHeader的取舍
Header 不是前端单方面能决定的事，它卡在前后端协作的缝隙里——漏掉任一环，请求就停在预检或响应阶段，连日志都看不到实际 body。
