前後端分離
前後端分離（英文名：Front-end and Back-end Separation）是一種現代Web應用架構模式，指將Web應用的前端（用戶界面與交互邏輯）與後端（業務邏輯與數據處理）在代碼倉庫、開發流程、部署運維等層面進行完全解耦，使前後端可獨立開發、測試與部署，並通過標準化API接口進行數據通信<[1]。該模式並非新興概念，而是隨著Web應用複雜度提升與團隊規模擴大而逐步形成的工程實踐，其核心思想在於職責分離：前端專注於頁面展示與用戶體驗，後端聚焦於業務邏輯與數據服務，二者通過明確的接口協議（如RESTful API）實現鬆耦合協作<[1]。
| 前後端分離 | |
|---|---|
| 中文名 | 前後端分離 |
| 英文名 | Front-end and Back-end Separation |
| 所屬領域 | 軟體工程 / Web開發 |
| 核心思想 | 職責分離、解耦合、獨立部署 |
| 通信方式 | RESTful API / GraphQL / HTTP |
| 典型技術棧 | React/Vue/Angular + Spring/Node/Django |
| 相關概念 | 單頁應用（SPA）、微服務、MVC |
Web開發的早期階段，如CGI（通用網關接口）時期，後端程序同時負責數據處理和頁面生成，前後端職責高度混雜<[1]。隨著Web應用的發展，前後端分離架構的演進主要經歷了三個階段：
模板渲染時代採用服務端渲染技術（如JSP、PHP），前後端代碼耦合於同一服務端項目中，前端交互頁面混雜在後端邏輯里，造成開發複雜度高、代碼維護困難<[2]。
AJAX局部刷新時代通過異步JavaScript和XML技術實現頁面局部刷新，提升了用戶體驗，但前後端職責仍未完全分離<[1]。
SPA與API驅動時代以React、Vue等前端框架為代表，前端應用作為獨立的單頁應用（SPA），通過API接口與後端進行數據交互，實現了前後端的徹底分離與並行開發<[1]。隨著雲計算和微服務架構的興起，前後端分離的實踐進一步深化，容器化（如Docker）和DevOps理念的普及使得前後端可以獨立構建、測試和部署<[1]。
前後端分離架構的核心特點包括職責分離、通過API進行通信、獨立部署、技術棧解耦以及支持並行開發<[1]。在該架構下，前端負責用戶界面和交互邏輯，後端負責業務邏輯和數據處理，二者通過API接口進行數據交換。前端與後端可以獨立部署和升級，並能夠自由選擇不同的技術棧，從而提升開發效率<[1]。
前端技術棧通常採用React、Vue、Angular等現代框架，並配套使用Redux、Vuex、Pinia等狀態管理工具，以及React Router、Vue Router等路由庫。構建過程則依賴Webpack、Vite、Rollup等工具<[1]。前端靜態資源通常部署於CDN或S3等靜態伺服器，以提升加載速度和用戶體驗<[1]。
後端技術棧涵蓋多種程式語言，如Java、Node.js、Python，並常使用Spring Boot、Express、Django、Flask等主流框架來實現業務邏輯和提供API服務<[1]。後端API服務則部署在應用伺服器或容器化環境（如Docker）中<[1]。
API作為前後端通信的橋梁，其設計至關重要。常見的風格包括RESTful API和GraphQL<[1]。數據交換通常採用JSON格式，並需定義統一的請求/響應格式、狀態碼及版本控制規範<[1]。安全性方面，常採用JWT、OAuth等機制進行身份驗證與授權<[1]。
典型開發流程始於接口契約的定義，前後端共同約定API接口的請求/響應格式與規範，並形成文檔<[1]。基於已定義的接口契約，前端可藉助Mock數據模擬後端接口獨立進行開發，後端則同步實現業務邏輯與接口<[1]。前後端完成各自開發後，進行接口對接與聯調，確保數據交互正確。測試團隊負責接口與功能測試，前後端可進行獨立測試並通過獨立的構建流水線進行部署<[1]。
該模式下的團隊協作強調職責的清晰劃分。前端團隊主要負責用戶界面與用戶體驗的實現及前端交互邏輯，並參與接口契約的設計；後端團隊專注於業務邏輯、數據處理與API接口的實現；測試團隊則負責制定和執行接口與功能測試用例，確保整體質量<[1]。
為支撐高效的分離開發與協作，常引入DevOps實踐。代碼管理上，前後端代碼倉庫分離；構建部署上，建立獨立的持續集成/持續部署流水線，實現獨立構建、測試與發布；交付物採用容器化技術作為標準，確保環境一致性；並通過自動化測試集成到流水線中保障交付質量<[1]。
該模式能提升開發與協作效率，前後端可獨立開發、測試與部署，減少相互依賴，實現並行開發，從而加快迭代速度<[1]。前後端分離增強了系統的可擴展性與靈活性，後端服務可以獨立擴展，且設計的API可同時服務於Web、移動App等多端產品<[1]。該模式有助於提高系統的可維護性與安全性，前後端代碼分離使結構更清晰，便於獨立維護<[1]。
實施前後端分離也面臨挑戰，包括溝通與協作成本可能增加，以及接口設計前期壓力大，在聯調階段易產生返工。同時，團隊人員配比需隨項目複雜度動態調整，實踐中可能出現相同組件模塊存在多種不同實現的一致性挑戰。該模式可能增加項目初始複雜度，並不一定適用於所有項目場景<[1]。
前後端分離本質上是技術的分離而非團隊的絕對分離。康威定律指出，設計系統的組織由於受到約束，這些設計往往是組織內部溝通結構的副本。因此，協作模式的選擇應基於業務實際、團隊能力和工程實踐成熟度，而非教條式地分離團隊<[1]。