開發伺服器與 HMR
npm run dev 啟動的就是 Vite 的開發伺服器。它是 Vite 開發體驗的核心，也是 Vite 之所以「快」的主要原因。理解它的運作方式，能幫你判斷專案變慢時該從哪裡下手排查。
為什麼傳統工具開發時會慢
在 Vite 出現之前，多數建置工具（例如 Webpack）採用「先打包再服務」的模式：開發伺服器啟動前，必須先把整個應用程式的所有模組掃描、轉譯、打包成一個或多個 bundle。專案越大、模組越多，這個打包過程就越久；每次修改檔案，理論上也要重新打包受影響的範圍才能反映到瀏覽器。
Vite 的做法：原生 ESM 隨需編譯
Vite 開發模式把應用程式拆成兩種模組來源：
- 原始碼（source code）：例如你自己寫的
.tsx、.vue。這類模組不會預先打包。瀏覽器發出import請求時，Vite 才即時轉譯該檔案並回傳，也就是「隨需編譯（on-demand compilation）」。因為只處理瀏覽器當下真正要用到的模組，啟動速度幾乎不受專案總檔案數影響。 - 相依套件（dependencies）：例如
node_modules裡的第三方套件，通常不常變動、模組數量龐大。Vite 使用 esbuild（以 Go 撰寫，比一般以 JavaScript 撰寫的工具快上數十倍）預先把這些套件打包成少數幾個檔案，稱為「相依性預先打包（dependency pre-bundling）」，避免瀏覽器對單一套件內成百上千個小模組各自發出請求。
兩者搭配之下，Vite 開發伺服器不需要「等全部打包完才能開始」，冷啟動時間幾乎是常數，不會隨專案增長而線性變慢。
熱模組替換（Hot Module Replacement, HMR）
修改程式碼並存檔後，Vite 不會重新整理整個頁面，而是透過 HMR，只把「有變動的模組」在瀏覽器中原地替換：
- 元件的內部狀態（例如表單輸入到一半的值、展開中的選單）通常能被保留，因為畫面沒有整頁重新載入。
- HMR 更新的速度不會隨應用程式規模變大而變慢，因為 Vite 只需要處理發生變動的那個模組，而不是重新分析整個相依圖。
- 框架整合外掛（如
@vitejs/plugin-react、@vitejs/plugin-vue）會針對該框架的元件格式，實作更精準的 HMR 邊界，讓狀態保留更可靠。
HMR 與 Live Reload 的差異
Live Reload 是「有檔案變動就整頁重新整理」；HMR 則是「只替換變動的模組，盡量不影響其他部分的執行狀態」。Vite 預設走 HMR，只有在無法安全替換時（例如修改了框架無法判斷邊界的程式碼），才會退回整頁重新整理。
常用開發伺服器設定
在 vite.config 的 server 選項中，常見的客製化包含：
export default {
server: {
port: 3000, // 指定連接埠
open: true, // 啟動後自動開啟瀏覽器
proxy: {
// 將 /api 開頭的請求代理到後端伺服器，避免開發時的 CORS 問題
'/api': 'http://localhost:8080',
},
},
}
proxy 選項在前後端分離開發時特別實用：前端呼叫相對路徑 /api/...，由 Vite 開發伺服器代為轉發到實際的後端位址，正式環境再改由後端或反向代理處理，程式碼不需要為環境切換 URL。