如果說 MVC 是「後端包辦一切」，那前後端分離就是「後端只管資料，前端只管畫面」；兩者最根本的差異在於渲染發生的位置：
── MVC ──────────────────────────────────────────────
瀏覽器 ──請求──▶ 後端（組好 HTML）──▶ 瀏覽器（顯示）
── 前後端分離 ────────────────────────────────────────
瀏覽器 ──請求──▶ 後端（回傳 JSON）──▶ 瀏覽器（自行渲染）
後端不再負責產生 HTML，它只提供結構化的資料（通常是 JSON）；畫面要長什麼樣子，完全是前端的責任。
用 ASP.NET Core Web API 來說明
後端：只負責資料，不碰畫面
1[ApiController]
2[Route("api/[controller]")]
3public class ProductsController : ControllerBase
4{
5 private readonly AppDbContext _db;
6 public ProductsController(AppDbContext db) => _db = db;
7
8 [HttpGet]
9 public async Task<IActionResult> GetAll()
10 {
11 var products = await _db.Products.ToListAsync();
12 return Ok(products); // 純 JSON，沒有 HTML
13 }
14
15 [HttpPost]
16 public async Task<IActionResult> Create(ProductDto dto)
17 {
18 // 驗證邏輯、商業規則...
19 var product = new Product { Name = dto.Name, Price = dto.Price };
20 _db.Products.Add(product);
21 await _db.SaveChangesAsync();
22 return CreatedAtAction(nameof(GetAll), new { id = product.Id }, product);
23 }
24}
後端回傳的是這樣的 JSON：
1[
2 { "id": 1, "name": "商品 A", "price": 100 },
3 { "id": 2, "name": "商品 B", "price": 250 }
4]
前端：自行呼叫 API，自行決定怎麼渲染以及資料要怎麼呈現，後端對此一無所知，兩者只透過 API 合約溝通。
前後端分離的優點
職責分離，邊界清楚
後端工程師專注在商業邏輯、資料處理、效能優化；前端工程師專注在 UI 設計、互動體驗、狀態管理；兩邊各自做好自己的事，不需要了解對方的細節。
一套 API，多端共用
這是前後端分離最核心的優勢。同一套後端 API，可以同時服務：
┌─ Web（React / Vue）
後端 API（JSON）────┼─ iOS App（Swift）
├─ Android App（Kotlin）
└─ 第三方服務（ERP 串接）
MVC 架構下，要支援 App 就需要另外再開一套 API，等於重複工作。
前後端可獨立部署與擴展
前端可以部署到 CDN，讓靜態資源在全球節點就近提供，速度快且成本低；後端則可以依照 API 流量彈性水平擴展，兩者互不影響。
可以並行開發
只要前後端團隊事先約定好 API 格式（透過 Swagger / OpenAPI 文件），就可以各自獨立開發，前端先用假資料（Mock）開發畫面，後端同時實作 API，最後再對接。
使用者體驗更流暢
SPA（Single Page Application）架構下，頁面切換不需要整頁重新載入，只有資料部分透過 API 更新，互動體驗接近原生 App。
前後端分離的缺點
首次載入速度慢
載入順序是：下載 HTML → 下載 JS bundle → 執行 JavaScript → 打 API → 渲染畫面，比起 MVC 直接收到完整 HTML 多了幾個步驟，首次顯示時間（Time to First Meaningful Paint）可能相對較長。
CORS 跨域問題
當前端和後端部署在不同網域時，瀏覽器的安全機制會阻擋跨域請求，必須在後端正確設定 CORS Header。
1// ASP.NET Core 需要明確設定 CORS
2builder.Services.AddCors(options =>
3{
4 options.AddPolicy("AllowFrontend", policy =>
5 policy.WithOrigins("https://your-frontend.com")
6 .AllowAnyHeader()
7 .AllowAnyMethod());
8});
在純 MVC 架構下則不需要考慮這個問題。
前端狀態管理變複雜
畫面狀態從後端 Session 移到了前端，需要自行管理；隨著應用規模增長，可能需要引入狀態管理工具，學習成本不低。
引入了新的 Bug 類型
前後端分離帶來了 MVC 架構下不存在的問題：
- Race Condition：多個 API 請求同時發出，後回來的覆蓋先回來的
- Token 過期：JWT 在操作到一半時過期，需要有完善的 Refresh 機制
- 錯誤處理層次增加：後端的 Exception 要序列化成 JSON，前端要正確解析並呈現
維護兩套專案
部署流程、CI/CD Pipeline、版本管理，都需要同時考慮前後端兩個專案，DevOps 複雜度增加。
為什麼業界趨勢走向前後端分離？
為什麼前後端分離成為主流，原因可能可以歸結成幾個結構性的改變：
- 多端需求成為標配：現代產品幾乎都需要同時支援網頁和 App，前後端分離讓同一套 API 服務所有客戶端，是非常自然的解決方案。
- 使用者體驗的期望提高：使用者已習慣如 Gmail、Google Maps、Notion 這種「App 感」的互動體驗，傳統整頁 Reload 的使用者體驗已經難以達到這個標準。
- 前端生態系的成熟：React、Vue 等框架的出現，讓前端有能力獨立承擔複雜的狀態管理，前端不再只是「呈現後端吐出的 HTML」，而是一個完整的應用程式層。
- 微服務架構的普及：現代後端系統走向微服務，每個服務以 API 對外溝通，前端只是眾多 API 消費者中的一個；在這個背景下，前後端分離是自然而然的結果，而非刻意的選擇。
- 前後端專業分工：前端和後端的技能樹越來越不同，分離架構讓各自專注本職，大型團隊的開發效率大幅提升。
前後端分離解決了 MVC 在多端支援、互動體驗、團隊分工上的限制，這是它成為主流的原因，但它帶來的複雜度也是存在的，不應被忽視；這兩種架構沒有絕對的優劣之分，只有使用情境適不適合的問題。