Fetch 请求无法设置 User-Agent，因浏览器安全策略禁止 JavaScript 修改该敏感请求头；可行方案包括后端代理、浏览器扩展或本地工具，而 X-Client-Version 等自定义头可正常发送。
Fetch 请求默认使用浏览器提供的 User-Agent，无法直接通过 headers 覆盖它——这是浏览器安全策略限制的硬性规则。你不能用自定义 Headers “伪造” User-Agent 发送给服务器。
为什么设置 User-Agent 头无效？
浏览器明确禁止 JavaScript 通过 fetch() 或 XMLHttpRequest 修改以下敏感请求头：
User-AgentRefererOriginHost-
Connection、Keep-Alive等连接相关头
即使你在 headers 中显式写入 {"User-Agent": "MyBot/1.0"}，浏览器也会静默忽略该字段，实际发出的仍是真实 UA。
可行的替代方案
如果你需要控制 User-Agent 行为，需跳出前端 fetch 的限制：
-
后端代理转发：在自己的服务器（如 Node.js、Python Flask）上接收请求，用服务端 HTTP 客户端（如
node-fetch、requests）发起带自定义 UA 的请求，再把响应返回给前端。 -
浏览器扩展或本地工具：通过 Chrome 扩展的
chrome.webRequestAPI 拦截并改写请求头（需对应权限）；或使用 Postman、curl、Python 脚本等非浏览器环境调试。 -
开发阶段临时绕过（仅限调试）：Chrome DevTools → Network → 右键请求 → “Copy as cURL”，粘贴到终端中手动修改 UA 后执行；或启用浏览器的“网络条件”模拟，但注意这只是影响
navigator.userAgent，不改变真实请求头。
能正常设置的自定义 Headers 示例
虽然 UA 不行，但你可以自由添加其他业务相关头：
fetch("/api/data", {
headers: {
"X-Client-Version": "2.1.0",
"X-Request-ID": "abc-123",
"Authorization": "Bearer token123"
}
});
这些会如实发送，且服务端可读取——适合身份标识、版本追踪、认证等场景。
不复杂但容易忽略：User-Agent 是浏览器守门员，不是 fetch 的配置项。真要控制它，得换地方发请求。
