Vite 的 server.headers 仅设置开发服务器响应头，不影响 API 跨域；跨域由后端 CORS 响应头（如 Access-Control-Allow-Origin）控制，前端无法通过请求头解除限制。
在 Vite 中，server.headers 不能用于配置“自定义请求头”来开启跨域限制——它只负责设置开发服务器响应给浏览器的 响应头（Response Headers），而跨域限制（CORS）本质是由浏览器根据后端返回的响应头（如 Access-Control-Allow-Origin）决定的，不是靠前端加请求头实现的。
更关键的是：前端无法通过添加请求头来“开启”或“解除”跨域限制。同源策略是浏览器强制执行的安全机制，前端发送的任何请求头（包括自定义头如 X-Auth-Token）一旦触发预检（OPTIONS），是否放行完全取决于后端返回的响应头是否合规。
server.headers 的真实用途
它仅用于让 Vite 开发服务器在返回 HTML/静态资源时附带指定响应头，例如：
- 设置
Content-Security-Policy防止 XSS - 添加
Strict-Transport-Security强制 HTTPS（开发环境一般不用） - 写入
X-Frame-Options: DENY防止被嵌入 iframe
⚠️ 它对 API 接口请求（如 axios 调用 /api/login）完全无效，因为这些请求走的是代理转发（target），Vite 不会把 headers 塞进代理出去的请求里，也不会覆盖后端返回的 CORS 头。
真正影响跨域行为的关键配置项
要安全、可控地处理跨域，应聚焦以下两处：
-
后端必须返回正确的 CORS 响应头：如
Access-Control-Allow-Origin: http://localhost:5173（禁用*配合 credentials）、Access-Control-Allow-Credentials: true、Access-Control-Allow-Headers明确列出前端实际用到的头（如Authorization,Content-Type） -
Vite 代理需正确转发且不干扰响应头：确保
changeOrigin: true，避免 Host 校验失败；不额外注入重复的Access-Control-Allow-Origin（否则浏览器报错“Header contains multiple values”）
为什么你可能看到 server.headers 被误用？
常见误解场景：
- 想用
server.headers = { 'Access-Control-Allow-Origin': '*' }“绕过”跨域 → 实际无效，该头只会出现在 Vite 返回的 index.html 上，不影响接口响应 - 代理后仍报跨域，误以为是前端没发对头 → 真因往往是后端返回了两个
Access-Control-Allow-Origin（比如 Nginx 和 SpringBoot 同时写了），或credentials: true时用了*
安全建议：最小权限原则
开发阶段别用 *，生产环境更要严格限定：
- 后端配置允许来源为具体前端域名（如
https://your-app.com），而非通配符 - 仅暴露必需的请求头：
Access-Control-Allow-Headers: Content-Type, Authorization - 预检请求（OPTIONS）必须返回 204 或 200，且不含响应体
- Vite 代理不处理 headers，但可借助
configure钩子做响应拦截（高级用法，需谨慎）
