Vite配置代理和后端服务器CORS

核心区别：作用的环境完全不同

Vite 代理（Proxy） ：只在你的电脑本地开发时（运行 npm run dev）有效。它其实是启动了一个本地 Node 服务器充当"中间人"。
后端 CORS：是服务器端实打实的跨域配置，主要在生产环境（线上）发挥作用。

Vite 代理是怎么绕过跨域的？

跨域限制是浏览器的安全机制，但服务器之间互相发请求是没有这个限制的。

Vite 代理就是利用了这一点。在 vite.config.js 里配置后，前端发的请求其实都发给了本地的 Vite 开发服务器，Vite 收到后，再帮你把请求转发给真实的后端 API。

对于浏览器来说，它只看到向同一个域名（比如 localhost:5173）发了请求，觉得是同源的，自然就不会报错了。

JavaScript 复制代码

// vite.config.js
export default {
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:3000',
        changeOrigin: true, // 骗过服务端，让它以为请求就是从 target 域名发出的
        rewrite: (path) => path.replace(/^/api/, '')
      }
    }
  }
}

本地开发时，两者冲突吗？

不冲突，但实际开发中通常只选其一。

最推荐的做法：前端配代理，后端不配 CORS。

这样做后端代码最干净，不需要专门为了配合前端本地调试去改跨域配置。这也更贴近真实的生产环境安全策略。
冗余的做法：前端配代理，后端也配 CORS。

能跑通，但后端的 CORS 相当于没用上，因为浏览器根本没做跨域拦截。
体验稍差的做法：前端不配代理，全靠后端 CORS。

前端直接请求 localhost:3000。虽然能工作，但每次复杂请求都会多出一步 OPTIONS 预检请求，看着有点繁琐。

生产环境怎么办？

Vite 的 proxy 配置在 npm run build 打包后就彻底失效了！

打包出来的产物只是一堆纯静态的 HTML/JS/CSS 文件。当把它们丢到服务器上后，就不存在 Vite 这个"中间人"了，代码里请求的 /api/users 就是直接向当前域名发起的。

所以在生产环境，解决跨域只能靠下面两招：

方案一：Nginx 反向代理（最常用，相当于线上的 Vite Proxy）

把前端静态文件和后端接口放在同一个域名下，通过 Nginx 按路径分发请求，这样浏览器看来依旧是同源的。

bash 复制代码

server {
    listen 80;
    server_name myapp.com;

    # 1. 访问网页，返回前端静态页面
    location / {
        root /var/www/frontend;
        try_files $uri /index.html;
    }

    # 2. 访问 /api，转发给后端服务
    location /api/ {
        proxy_pass http://backend:3000/;
    }
}

方案二：后端老老实实配 CORS

如果前端托管在 CDN 上，或者前后端域名注定不一样（比如前端 www.myapp.com，后端 api.myapp.com），那就必须让后端加上跨域头，指定允许你前端的线上域名访问：

JavaScript 复制代码

// 后端代码示例
app.use(cors({
  origin: 'https://www.myapp.com', // 写死前端的线上域名
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE']
}))

一句话总结

开发环境靠 Vite 代理 当中间人绕过浏览器限制，生产环境靠 Nginx 转发 或后端 CORS 来处理真实的跨域问题。两者是不同开发阶段的解决方案，各司其职。