Fetch调用中：传递普通对象与new Headers(...)的请求头有何差异？

问题背景：
重构代码时遇到fetch调用混用两种请求头格式，示例代码如下：

const headers = {
    Authorisation: 'Bearer some token data',
    'Content-Type': 'application/json'
}

console.log(new Headers(headers));

/* OUTPUT OF CONSOLE LOG
headers: HeadersList {
    [Symbol(headers map)]: [Map],
    [Symbol(headers map sorted)]: null
}
*/

疑问：在fetch调用中，传递普通对象格式的请求头与使用new Headers(...)创建的请求头之间是否存在显著差异？

在绝大多数常规fetch场景下，两种格式最终发送的HTTP请求头效果一致，但在内部处理逻辑、功能扩展性上存在几个关键区别：

1. 头名称规范化处理 #

Headers实例会自动将头名称转换为HTTP标准格式（首字母大写，其余小写，比如把authorisation修正为标准的Authorization）；而普通对象的键名会被原样传递——虽然HTTP头本身不区分大小写，但部分场景下可能因大小写不一致引发潜在问题（比如后端严格匹配头名称的情况）。

2. 重复头的处理逻辑 #

• 普通对象：如果存在同名键，后定义的值会直接覆盖前值。比如{ 'Cookie': 'a=1', 'Cookie': 'b=2' }最终只会保留b=2。
• Headers实例：支持通过append()方法添加多个同名头，最终会合并为一个用逗号分隔的合法多值头（符合HTTP规范，比如Cookie、Set-Cookie这类允许多值的头）。

3. 可操作能力差异 #

Headers实例是可迭代对象，内置append()、delete()、get()、has()等便捷方法，适合需要动态修改、查询头信息的场景；而普通对象只能通过常规的属性赋值/删除操作修改，没有这些内置方法支持。

4. 内部存储结构 #

正如控制台输出显示的，Headers实例内部采用Map结构存储头信息，在处理大量或复杂头数据时，遍历、查找的效率更优；普通对象则是常规的键值对存储，适合简单的头定义场景。

实践建议 #

对于日常的fetch请求（比如设置Authorization、Content-Type这类常见头），两种写法的最终发送效果完全一致——浏览器会自动将普通对象转换为Headers实例进行处理。重构时可根据团队编码规范统一格式即可。

内容的提问来源于stack exchange，提问作者physicsboy