HTML Fetch设置请求头方法

Fetch 请求头必须通过 Headers 实例来设置，普通对象会被静默忽略；需要显式配置 credentials 才能发送 Cookie；当 Content-Type 为 application/json 时，body 必须使用 JSON.stringify，否则后端无法接收到数据。

在使用 Fetch API 发起请求时，请求头的设置看似简单，实则包含多个关键细节。许多开发者都曾在此遇到问题：代码逻辑看起来没有问题，但后端却收不到预期的数据或认证信息。下面将逐一梳理这些关键点。

Fetch 请求头必须通过 Headers 对象构造

第一个常见错误是直接传入一个普通对象。例如，可能会写成 { 'Content-Type': 'application/json' }。但 Fetch API 并不接受这种字面量对象，而是要求使用 Headers 构造函数创建实例。

如果使用普通对象，某些关键请求头（如 Authorization）会被静默忽略，尤其在 POST 请求或需要携带凭证的场景下，问题会变得非常明显。

正确的做法如下：

const headers = new Headers();
headers.append('Content-Type', 'application/json');
headers.append('Authorization', 'Bearer abc123');

fetch('/api/data', {
  method: 'POST',
  headers,
  body: JSON.stringify({ x: 1 })
});

以下是一些实用的小技巧：

• 初始化时也可以使用数组：new Headers([['Content-Type', 'application/json']])，写法更简洁。
• 如需覆盖同名的请求头，使用 set() 方法替代 append()，可以避免重复。
• 注意，Content-Length 等一些安全相关的请求头，浏览器会自动设置，手动设置反而可能被忽略。

哪些请求头会被 Fetch 拒绝或覆盖

即使使用了 Headers 实例，也并非所有请求头都能自由设置。浏览器出于安全考虑，对部分敏感请求头有严格限制。

如果尝试设置 Cookie、Host、Origin、Referer 等请求头，浏览器会直接抛出 TypeError: Invalid header 错误，不会发出请求。

常见的被拦截或限制的请求头包括：

• Accept-Charset、Accept-Encoding（除非服务端明确支持，否则设置可能无效）
• Connection、Keep-Alive、Proxy-Authenticate
• Set-Cookie —— 这一点尤其重要，它是响应头，客户端无法在请求中主动设置，只能由服务端在响应中返回。

如果在控制台看到类似 Refused to set unsafe header "xxx" 的警告，说明该请求头已被浏览器的安全策略屏蔽，没有绕过的办法。

携带 Cookie 需要显式配置 credentials

这是另一个常见问题。默认情况下，fetch 请求不会自动携带 Cookie。即使在 headers 中设置了相关字段，也无法生效，关键在于 credentials 选项。

该选项有三个值：

• credentials: 'omit'：默认值，表示不发送 Cookie。
• credentials: 'same-origin'：仅在同源请求时发送 Cookie，这是最常用的设置。
• credentials: 'include'：始终发送 Cookie。需要注意的是，在跨域请求中使用此选项时，后端必须返回 Access-Control-Allow-Credentials: true 响应头，否则请求会失败。

许多登录状态问题都源于此。可能已经配置了 Authorization 请求头，但后端身份验证依赖的是 Cookie。如果漏配了 credentials，就会出现“请求头看起来正常，但用户却莫名其妙退出登录”的异常情况。

Content-Type 为 application/json 时 body 必须为字符串

最后一个经典错误发生在发送 JSON 数据时。很多人设置了 Content-Type: application/json，就直接将一个 JavaScript 对象赋给了 body。

结果后端收到的可能是莫名其妙的 [object Object] 字符串，或者根本无法收到数据。原因是 fetch 不会自动对对象进行序列化。

• 错误示例：body: { name: 'alice' }
• 正确做法：body: JSON.stringify({ name: 'alice' })

同理，如果后端要求的是 Content-Type: application/x-www-form-urlencoded，那么 body 应使用 URLSearchParams 对象来构造，而不是手动拼接字符串。手动拼接容易在处理空格、中文等特殊字符时出现编码错误。

总结来说，设置 Fetch 请求头的关键点在于理清以下几个容易混淆的关联：credentials 选项与 Cookie 的发送、Content-Type 与 body 格式的匹配，以及浏览器对某些敏感请求头的强制限制。最常见的疏忽是忘了配置 credentials 却指望 Cookie 生效，或者忘了使用 JSON.stringify 就直接把对象塞进 body。处理好这些细节，网络请求部分基本就能稳定运行。