快捷導(dǎo)航

Vite前端API調(diào)用與本地開發(fā)代理配置策略詳解

更新時(shí)間：2025年12月30日 08:48:08 作者：nvd11

本文詳細(xì)介紹了如何在前端代碼中使用相對(duì)路徑定義后端API URL,并通過Vite開發(fā)服務(wù)器的代理配置,解決了跨域資源共享（CORS）問題和環(huán)境差異問題,通過這套組合方案,實(shí)現(xiàn)了同一份前端代碼在本地開發(fā)和生產(chǎn)環(huán)境下的無縫運(yùn)行

一、核心問題

現(xiàn)代 Web 開發(fā)中，前端應(yīng)用（運(yùn)行在瀏覽器）和后端 API（運(yùn)行在服務(wù)器）通常是分離的。這會(huì)帶來兩個(gè)主要問題：

跨域資源共享 (CORS)：在本地開發(fā)時(shí)，前端運(yùn)行在 http://localhost:5173，而后端 API 運(yùn)行在云端的 https://gateway.jpgcp.cloud。由于源（協(xié)議、域名、端口）不同，瀏覽器會(huì)出于安全策略，默認(rèn)阻止前端直接調(diào)用后端 API。
環(huán)境差異：前端代碼需要一種方法，既能在本地開發(fā)時(shí)正確調(diào)用云端 API，又能在部署到生產(chǎn)環(huán)境后，正確地調(diào)用生產(chǎn)環(huán)境的 API，而不需要每次都手動(dòng)修改代碼。

二、解決方案：“相對(duì)路徑” + “Vite 代理”

我們采用了一套標(biāo)準(zhǔn)的、優(yōu)雅的組合方案來解決以上所有問題。

1. API URL 風(fēng)格：使用相對(duì)路徑

我們修改了 src/services/api.ts 文件，將 API 的 URL 定義為一個(gè)相對(duì)路徑。

代碼 (src/services/api.ts):

// The URL of your backend API. Using a relative path works for both
// local development (with proxy) and production deployment.
const API_URL = '/chat-api-svc/api/v1/chat';

// ...
const response = await fetch(API_URL, { ... });

原理與優(yōu)勢(shì)：

當(dāng) URL 以 / 開頭時(shí)，瀏覽器會(huì)自動(dòng)將當(dāng)前頁(yè)面的協(xié)議和域名加在它的前面。
在生產(chǎn)環(huán)境: 頁(yè)面在 https://gateway.jpgcp.cloud/chat/，請(qǐng)求就會(huì)發(fā)往 https://gateway.jpgcp.cloud/chat-api-svc/api/v1/chat。這正好能匹配上我們 GKE Gateway 中的路由規(guī)則，實(shí)現(xiàn)了同源調(diào)用，沒有 CORS 問題。
在本地開發(fā)環(huán)境: 頁(yè)面在 http://localhost:5173/chat/，請(qǐng)求就會(huì)發(fā)往 http://localhost:5173/chat-api-svc/api/v1/chat。這個(gè)地址本身是無效的，但它為我們的第二步——Vite 代理——創(chuàng)造了條件。

2. Vite 代理配置

為了讓本地開發(fā)時(shí)的 API 請(qǐng)求能成功，我們配置了 Vite 的開發(fā)服務(wù)器，讓它充當(dāng)一個(gè)代理。

配置 (vite.config.ts):

// ...
export default defineConfig({
  // ...
  server: {
    host: true,
    // This proxy configuration is for the local development server ONLY.
    proxy: {
      // 當(dāng)開發(fā)服務(wù)器收到一個(gè)以 '/chat-api-svc' 開頭的請(qǐng)求時(shí)...
      '/chat-api-svc': {
        // ...就將它轉(zhuǎn)發(fā)給這個(gè)目標(biāo)地址。
        target: 'https://gateway.jpgcp.cloud',
        // 改變請(qǐng)求的 Origin 頭，對(duì)于 HTTPS 和虛擬主機(jī)托管是必需的。
        changeOrigin: true,
      },
    },
  },
  // ...
})

原理與優(yōu)勢(shì)：

這個(gè) server.proxy 配置僅在 npm run dev 時(shí)生效，對(duì)生產(chǎn)構(gòu)建沒有影響。
它告訴 Vite：“你就是中間人。所有發(fā)給你的、路徑以 /chat-api-svc 開頭的請(qǐng)求，都不要自己處理，而是原封不動(dòng)地轉(zhuǎn)發(fā)給 https://gateway.jpgcp.cloud，然后再把那邊的響應(yīng)拿回來，交給瀏覽器。”
對(duì)于瀏覽器來說，它始終認(rèn)為自己是在和 localhost:5173 通信，因此完全規(guī)避了 CORS 問題。

三、總結(jié)

通過**“前端使用相對(duì)路徑”和“本地開發(fā)環(huán)境使用代理”**這套組合拳，我們實(shí)現(xiàn)了：

一套代碼，兩種環(huán)境無縫運(yùn)行：同一份前端代碼，無需任何修改，既可以在本地開發(fā)時(shí)調(diào)用云端 API，也可以在部署后調(diào)用生產(chǎn)環(huán)境的網(wǎng)關(guān)。
徹底解決 CORS 問題：無論是本地還是生產(chǎn)，從瀏覽器的視角來看，API 調(diào)用都是同源的。
配置清晰，易于維護(hù)：API 的真實(shí)地址只存在于一處（Vite 的代理配置中），便于未來修改。生產(chǎn)環(huán)境的路由則完全由 GKE Gateway 的配置來管理。

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

您可能感興趣的文章: