ajax如何设置响应头，ajax设置响应头方法

在前后端分离的架构中,AJAX请求默认遵循同源策略，且浏览器出于安全考虑会屏蔽部分响应头信息，若需在前端JavaScript中获取后端设置的自定义响应头（如Token、业务状态码等），核心解决方案是在后端服务器配置Access-Control-Expose-Headers，并在AJAX请求中配合withCredentials属性处理跨域凭证，这是解决跨域数据交互中“头信息不可见”问题的唯一标准路径。

核心机制解析：为什么默认获取不到？

浏览器为了保障用户数据安全,实施了严格的同源策略，当发生跨域请求时，浏览器会自动过滤掉响应头中的大部分字段，仅暴露以下8个基础字段：

1. Cache-Control
2. Content-Language
3. Content-Type
4. Expires
5. Last-Modified
6. Pragma

任何自定义的响应头（X-Auth-Token、X-Request-Id 或 Authorization）默认都被浏览器拦截，前端无法通过 response.headers.get() 获取，这并非AJAX的缺陷，而是浏览器的安全机制，后端必须显式声明哪些头信息允许前端访问。

后端配置：Access-Control-Expose-Headers

要实现前端获取自定义响应头,第一步必须在后端服务器进行CORS（跨域资源共享）配置，关键在于添加 Access-Control-Expose-Headers 响应头。

Nginx 配置示例 在Nginx配置文件中，针对允许跨域的接口添加以下指令：

add_header Access-Control-Expose-Headers "X-Auth-Token, X-Request-Id";

这将告诉浏览器：“除了默认暴露的头信息外，请额外暴露 X-Auth-Token 和 X-Request-Id 给前端。”

Java Spring Boot 配置示例 在Spring Boot中，可以通过 @CrossOrigin 注解或全局配置实现：

@CrossOrigin(origins = "*", allowedHeaders = "*", exposeHeaders = "X-Auth-Token, X-Request-Id")
@GetMapping("/data")
public ResponseEntity getData() {
    // 业务逻辑
}

或者在拦截器中手动设置：

response.setHeader("Access-Control-Expose-Headers", "X-Auth-Token, X-Request-Id");

Node.js (Express) 配置示例

res.header('Access-Control-Expose-Headers', 'X-Auth-Token, X-Request-Id');

前端实现：AJAX 请求的最佳实践

配置好后端后,前端需确保请求方式正确，不同AJAX库的实现略有差异，但核心逻辑一致。

原生 XMLHttpRequest

const xhr = new XMLHttpRequest();
xhr.open('GET', 'https://api.example.com/data', true);
xhr.withCredentials = true; // 如需携带Cookie，必须设为true
xhr.onload = function() {
    // 获取自定义头信息
    const token = xhr.getResponseHeader('X-Auth-Token');
    console.log('获取到的Token:', token);
};
xhr.send();

Fetch API

fetch('https://api.example.com/data', {
    credentials: 'include' // 等价于 withCredentials
})
.then(response => {
    // 注意：Fetch API 中，如果未配置 exposeHeaders，headers.get() 仍可能返回 null
    const token = response.headers.get('X-Auth-Token');
    console.log('获取到的Token:', token);
})
.catch(error => console.error('Error:', error));

Axios Axios 默认会将所有响应头暴露出来（在大多数浏览器中表现良好，但为了规范，建议后端仍配置 exposeHeaders）。

axios.get('https://api.example.com/data', {
    withCredentials: true
}).then(response => {
    // Axios 将响应头挂载在 response.headers 上
    const token = response.headers['x-auth-token'];
    console.log('获取到的Token:', token);
});

常见陷阱与专业建议

1. 预检请求（Preflight）：如果请求方法不是GET/POST，或包含自定义头，浏览器会先发送 OPTIONS 请求，此时后端必须正确处理 OPTIONS 请求，并同样返回 Access-Control-Expose-Headers，否则预检失败，后续请求不会发送。
2. 大小写敏感性：HTTP头字段名不区分大小写，但在代码获取时，不同库的处理方式不同，建议统一使用小写或连字符格式，并在后端配置时保持一致。
3. 安全性考量：不要暴露敏感信息（如密码、内部密钥）到前端可访问的头信息中。Access-Control-Expose-Headers 应仅用于前端确实需要读取的业务数据。
4. 调试技巧：在浏览器开发者工具的 Network 面板中，查看响应头（Response Headers），确认 Access-Control-Expose-Headers 是否已正确返回，以及自定义头是否出现在列表中。

相关问答

Q1: 为什么后端已经设置了 Access-Control-Expose-Headers，前端依然获取不到自定义头？ A: 首先检查浏览器控制台是否有CORS错误提示，确认请求是否触发了预检请求（OPTIONS），如果是OPTIONS请求，后端必须对OPTIONS响应也设置 Access-Control-Expose-Headers，部分旧版浏览器或特定网络代理可能会过滤非标准头信息，建议使用最新标准浏览器测试，确保前端获取头信息的代码在请求成功回调中执行，而非异步完成前。

Q2: 如果后端无法修改代码，只能通过Nginx反向代理，该如何实现？ A: 可以在Nginx配置中直接添加头信息。

location /api/ {
    proxy_pass http://backend_server;
    proxy_hide_header Access-Control-Expose-Headers; # 隐藏后端可能存在的默认设置
    add_header Access-Control-Expose-Headers "X-Auth-Token, X-Request-Id" always;
    # 其他CORS配置...
}

通过 add_header 指令强制覆盖或补充响应头，确保前端能接收到暴露的头信息列表。

互动环节

在实际开发中,你是否遇到过因CORS配置不当导致的数据获取失败问题？欢迎在评论区分享你的解决方案或遇到的疑难杂症，我们将选取典型案例进行深度解析。