.NET Core + Vue 全端開發：前後端分離的實務架構

我主力是後端，但很多專案是我一個人從 API 寫到畫面。這幾年我穩定用的組合是後端 .NET Core、前端 Vue。這篇講的不是入門教學，而是當你要用這個組合交付「真的會上線、要維護好幾年」的系統時，我學到的架構取捨。

為什麼選這個組合

.NET Core 跨平台、效能好、型別嚴謹，內建的依賴注入和中介軟體（middleware）機制讓分層很自然。Vue 則是學習曲線平緩、文件清楚，對一個後端背景的人來說，上手成本比其他框架低。

但選型的重點其實是：這個組合讓「一個人」能掌握全貌。前後端徹底分離、用 API 溝通，我可以把後端的嚴謹帶到前端，又不會被前端的複雜度淹沒。

前後端分離：契約先行

前後端分離最大的好處是各自獨立開發、獨立部署。但前提是：API 契約要先定義清楚。

我的習慣是後端用 OpenAPI/Swagger 把 API 規格產出來，前端依此對接。好處：

• 前端不用等後端寫完才能開工，先照契約 mock
• 契約即文件，減少「這個欄位到底叫什麼」的來回
• 可以用工具從 OpenAPI 直接產前端的型別與 API client，少寫一堆樣板、也少打錯欄位

契約一旦定了就盡量別亂改，要改就走版本控制（v1、v2），不要默默改掉一個欄位讓前端在正式環境爆掉。

後端分層別過度

.NET 圈子很流行各種架構（Clean Architecture、CQRS 等）。我的態度是：分層是手段不是目的。

對多數商業專案，我會保持務實的三層：

• Controller / API 層：只管接收請求、驗證、回應，不寫業務邏輯
• Service 層：業務邏輯集中在這裡，可被測試
• Repository / 資料存取層：把資料庫操作隔離

過度套用花俏架構，常常讓一個簡單的 CRUD 要改五個檔案。除非專案複雜度真的需要，否則我傾向先簡單，等痛點出現再重構。

認證：JWT 與該注意的地方

前後端分離後，認證通常走 token。後端發 JWT，前端帶在 Authorization header。幾個我會堅持的點：

• access token 短效，搭配 refresh token 換新，降低外洩風險
• token 不要塞太多敏感資料，它只是經過 base64、不是加密
• 後端每個受保護的 API 都要實際驗證權限，別以為「前端沒顯示按鈕」就安全——前端的隱藏只是體驗，真正的關卡永遠在後端

前端的狀態與錯誤處理

Vue 這端，我踩過最多的不是語法，而是狀態管理和錯誤處理：

• 共用狀態（登入資訊、權限）用 Pinia 之類集中管理，別到處傳 props
• API 呼叫統一包一層，集中處理 401（自動導去登入）、共用的錯誤提示、loading 狀態
• 表單驗證前後端都要做：前端做體驗（即時提示），後端做把關（最終防線）。只做前端驗證等於沒做

部署：兩種選擇

前後端分離後部署有兩條路：

• 各自獨立部署：前端打包成靜態檔放 CDN／靜態主機，後端 API 獨立一台。最乾淨，前端更新不影響後端
• 後端代管前端：把前端打包後的靜態檔由 .NET 一起服務。少一個部署目標，適合小專案

我多數情況選前者，因為前端改版頻率通常比後端高，分開部署讓兩邊的節奏互不干擾。

小結

用 .NET Core + Vue 做全端，我的幾個原則：

• 契約先行，用 OpenAPI 串起前後端
• 後端分層務實就好，別為架構而架構
• 認證用短效 token，權限把關一定在後端
• 前端集中管理狀態與錯誤，驗證前後端都做
• 前後端盡量獨立部署，互不卡

對後端工程師來說，能獨立交付全端不是要你變成前端專家，而是讓你看得懂整條鏈路——這在排查問題和跟團隊溝通時，價值遠超過多會一個框架。