axios如何解决跨域问题：分环境配置方案

axios如何解决跨域问题分为开发环境前端代理、生产环境后端CORS配置、JSONP三种主流方案，开发环境优先用脚手架代理，无需修改后端代码，生产环境优先启用服务端CORS响应头；开启cookie凭证传输时，axios必须配置withCredentials:true，同时后端要同步开启允许凭证，且Access-Control-Allow-Origin不能配置为通配符*；仅GET请求可选用JSONP，POST请求无法使用该方案；该方案边界限制为：浏览器同源策略只拦截浏览器发起的请求，Node环境下使用axios不会触发跨域限制。

axios前端代理配置（开发环境）

你在VueCLI项目里修改vue.config.js的devServer.proxy，把/api前缀的请求转发到后端真实地址，同时把axios的baseURL写成/api，不要填写完整后端域名，浏览器只会请求同域下的/api地址，不会触发跨域校验。

配置核心参数只有三项。

target填写后端接口地址，changeOrigin设置为true修改请求源，pathRewrite把请求路径里的/api前缀替换为空，保证接口路由匹配正常。

Vite项目则在vite.config.js的server节点下编写proxy配置，写法和VueCLI保持一致，仅配置文件路径不同。

axios实例只需要把baseURL设置成/api，不需要额外添加跨域请求头，代理由开发服务器完成，不会经过浏览器同源策略校验。

axios配合后端CORS（生产环境首选）

这是线上正式环境的稳定方案，前端只需要补充axios凭证配置，核心配置都放在后端接口响应头里。

当接口需要携带cookie、登录凭证时，你必须在axios全局配置里开启withCredentials:true，只开启前端配置而后端不配合，请求依然会被浏览器拦截。

后端需要同时设置四项响应头：指定允许访问的前端域名、开启允许自定义请求头、开放GET与POST等请求方式、开启允许发送凭证；同时Access-Control-Allow-Origin只能填写具体域名，不能使用星号通配符，否则凭证传输会直接失效。

SpringBoot项目可以直接在控制器类添加@CrossOrigin注解，快速开启单接口跨域；全局跨域则编写CORS配置类，统一管理所有接口的跨域规则。

axios实现JSONP跨域（仅GET请求可用）

axios自带JSONP请求方法，仅适用于纯GET接口，POST请求无法使用该方式，这是该方案最明显的使用边界。

调用axios.jsonp方法，传入接口地址与回调函数名称，后端接收callback参数，返回包裹JSON数据的函数调用语句，浏览器把返回内容当作脚本执行，就能拿到接口数据，绕过同源策略限制。

该方案不需要后端配置CORS头，缺点是只能发起GET请求，无法传递复杂请求头，现代前后端分离项目大多只把它作为兼容老旧接口的备选方案。

三种跨域方案选型对比

容易踩坑的配置细节

不要在axios请求头里手动添加Access-Control-Allow-Origin，这个响应头只能由后端服务器返回，前端自行添加不会生效，还会触发预检请求异常。

开启withCredentials之后，后端必须严格限定前端域名，不能设置为*，否则浏览器会直接拒绝接收响应内容。

OPTIONS预检请求报错，大多是后端没有配置允许自定义请求头，需要在Access-Control-Allow-Headers里添加Token、Authorization这类自定义字段。