Ajax请求如何添加自定义响应头，前端ajax设置请求头方法

在前后端分离的架构中，Ajax请求的跨域资源共享（CORS）问题始终是前端开发必须跨越的一道技术门槛，核心上文小编总结非常明确：要在Ajax请求中成功添加自定义响应头或处理跨域请求，关键在于服务端正确配置Access-Control-Allow-Headers和Access-Control-Allow-Origin，而前端则需通过XMLHttpRequest或Fetch API显式设置请求头，并确保浏览器预检请求（Preflight Request）顺利通过，任何一方的配置缺失或错误，都会导致浏览器拦截请求，抛出“No ‘Access-Control-Allow-Origin’ header is present”或“Request header field xxx is not allowed by Access-Control-Allow-Headers”等错误。

服务端配置：CORS策略的核心基石

Ajax请求能否携带自定义Header，首先取决于服务端的CORS策略，浏览器出于安全考虑，默认禁止前端脚本读取跨域响应中的自定义字段,服务端必须在HTTP响应头中明确声明允许前端访问哪些头部信息。

以Nginx为例，这是最常见的Web服务器配置场景,你需要在location块中添加以下指令：

add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization, X-Custom-Header';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';

这里的关键点在于Access-Control-Allow-Headers，如果你在前端请求中添加了X-Custom-Header，服务端必须在此处列出该头部名称，否则浏览器会在预检请求失败后直接阻断后续的实际请求，对于Java Spring Boot应用，则可以通过@CrossOrigin注解或配置WebMvcConfigurer来实现相同的效果，确保allowedHeaders包含所有自定义头部。

前端实现：精准控制请求头

在前端层面，添加响应头（实际上是发送请求头）主要有两种方式：传统的XMLHttpRequest和现代Fetch API。

使用XMLHttpRequest时，开发者需要在open方法之后、send方法之前调用setRequestHeader，需要注意的是，某些头部如Content-Type、Accept等由浏览器自动管理，手动设置可能导致意外行为，因此建议仅设置业务相关的自定义头部，如X-Token或X-Request-Id。

var xhr = new XMLHttpRequest();
xhr.open('POST', 'https://api.example.com/data', true);
xhr.setRequestHeader('Content-Type', 'application/json');
xhr.setRequestHeader('X-Custom-Header', 'my-value');
xhr.onload = function() {
    console.log(xhr.responseText);
};
xhr.send(JSON.stringify({ key: 'value' }));

对于现代开发，Fetch API提供了更简洁的语法，通过headers对象传递配置，代码可读性更强,且天然支持Promise链式调用。

fetch('https://api.example.com/data', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
        'X-Custom-Header': 'my-value'
    },
    body: JSON.stringify({ key: 'value' })
})
.then(response => response.json())
.then(data => console.log(data));

预检请求与复杂请求的处理机制

当Ajax请求包含非简单请求（如自定义Header、Content-Type为application/json、或Method为PUT/DELETE）时，浏览器会自动先发一个OPTIONS请求进行预检,这是CORS机制的安全防线。

许多开发者在此阶段遇到困惑：明明前端设置了Header，后端也返回了200，但实际请求依然失败，原因往往在于服务端未正确处理OPTIONS请求，服务端必须对OPTIONS请求返回200状态码，并在响应头中包含与POST/GET请求相同的CORS头部信息，如果服务端忽略了OPTIONS请求，预检失败,浏览器将不会发送后续的真实业务请求。

常见误区与优化建议

1. 不要滥用通配符：在生产环境中，Access-Control-Allow-Origin应尽量避免使用，而是指定具体的域名,以防止CSRF攻击。
2. 敏感头部保护：如果涉及Cookie或认证信息，需设置withCredentials: true，同时服务端Allow-Origin不能为,必须明确指定域名。
3. 缓存预检结果：通过Access-Control-Max-Age设置预检请求的缓存时间，可以减少不必要的OPTIONS请求,提升性能。

相关问答

Q1: 为什么设置了Request Header，浏览器依然报错“Request header field is not allowed”？

A: 这通常是因为服务端未在Access-Control-Allow-Headers中声明该自定义头部，浏览器在发送非简单请求前会进行预检，如果服务端返回的预检响应中不包含前端请求的Header名称，浏览器将拒绝发送实际请求，解决方案是检查服务端CORS配置,确保所有自定义Header都在允许列表中。

Q2: 如何在Ajax请求中同时携带Cookie和自定义Header？

A: 这需要前后端协同配置，前端需在XMLHttpRequest中设置xhr.withCredentials = true或在Fetch中设置credentials: 'include'，服务端必须将Access-Control-Allow-Origin设置为具体的前端域名（不能是），并添加Access-Control-Allow-Credentials: true，服务端还需确保Access-Control-Allow-Headers包含前端发送的所有自定义头部。

希望本文能帮助您彻底解决Ajax响应头配置难题，如果您在实际开发中遇到其他CORS相关问题，欢迎在评论区留言讨论,您的反馈将帮助更多开发者避开技术陷阱。