需显式声明自定义请求头，因浏览器仅允许9个安全头跨域发送，添加如authorization等自定义头会触发预检；服务端须通过access-control-allow-headers精确列举（逗号分隔），不可用，且启用凭据时access-control-allow-origin不能为。
服务端配置允许的自定义请求头，核心是设置 Access-Control-Allow-Headers 响应头，告诉浏览器哪些非标准请求头可以被客户端合法携带发送。
为什么需要显式声明自定义头
浏览器默认只允许客户端在跨域请求中发送一组“安全头”（如 Accept、Content-Type 等 9 个），一旦你在 fetch 或 XMLHttpRequest 中设置了像 Authorization、X-Request-ID、X-App-Version 这类自定义头，浏览器就会触发预检（OPTIONS）请求。若服务端响应中没包含对应头名，预检失败，后续请求直接被拦截。
关键配置要点
-
必须列出所有要用到的自定义头名，多个用英文逗号+空格分隔，例如：
Authorization, X-User-Token, Content-MD5 - 如果用了
Content-Type: application/json，它本身虽是标准类型，但因值不在“简单请求白名单”内（仅 text/plain / form-data / x-www-form-urlencoded），也会触发预检，所以Content-Type也需出现在Access-Control-Allow-Headers中 - 不能写通配符
*—— 该头不支持通配，必须明确枚举 - 若同时启用了凭据（
credentials: 'include'），则Access-Control-Allow-Origin不能为*，必须指定具体源，否则整个 CORS 会失效
常见后端配置示例
Express（Node.js）：
app.use((req, res, next) => {
res.header('Access-Control-Allow-Origin', 'https://your-frontend.com');
res.header('Access-Control-Allow-Credentials', 'true');
res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization, X-User-ID, X-Trace-ID');
next();
});
.NET 6+（Minimal API）：
builder.Services.AddCors(options => {
options.AddPolicy("CustomHeaders", policy => {
policy.WithOrigins("https://your-frontend.com")
.AllowAnyMethod()
.WithHeaders("Content-Type", "Authorization", "X-User-ID") // 显式列出
.AllowCredentials();
});
});
app.UseCors("CustomHeaders");
Nginx（反向代理层补充）：
location /api/ {
add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization, X-App-Key';
add_header 'Access-Control-Allow-Origin' 'https://your-frontend.com';
add_header 'Access-Control-Allow-Credentials' 'true';
# 其他 CORS 头...
}
调试建议
- 用浏览器开发者工具的 Network 面板查看预检（OPTIONS）响应，确认
Access-Control-Allow-Headers是否存在且拼写准确（大小写不敏感，但建议统一小写） - 注意：即使前端代码没显式加 header，某些库（如 Axios）可能自动注入
X-Requested-With，若未在服务端声明，也会导致预检失败 - 开发阶段可临时设为
Access-Control-Allow-Headers: *（部分现代浏览器支持，但非标准，生产环境勿用）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
