前後端分離不是信仰，是工程決策。但很多團隊搞不清楚自己為什麼要分離，只因為「大家都在做」就跟著做——結果分離完更痛苦。
先講結論
前後端分離的本質是職責分工。當你的專案複雜到一個人顧不了前後端、或者前端需求變化速度遠超後端的時候，分離才有意義。如果你的團隊只有兩個人、專案只有五個頁面，硬要分離反而是自找麻煩。
沒有前後端分離的世界
2015 年以前，大部分專案就是後端一個人包辦。PHP 的 echo '<div>' 、Rails 的 ERB、Java 的 JSP——後端把資料塞進 HTML 模板，瀏覽器收到的是一整頁渲染好的頁面。
這樣做的好處？人力少、環境單純、SEO 天然沒問題。
壞處？當其他人要接手的時候，打開檔案一看——HTML 裡面夾著 PHP，PHP 裡面拼著 SQL，SQL 結果直接塞進 JavaScript。你根本不知道從哪裡開始讀起。這不是程式碼，這是考古現場。
那為什麼要分離？
大概 2015 年左右開始，前端框架大爆發。頁面不再只是「顯示資料」，而是要做拖放、即時預覽、複雜表單、動畫互動。這些東西你叫後端工程師來搞，他會看著 webpack 設定檔露出跟你看到 K8s YAML 一樣的表情。
反過來也一樣——你不會叫前端去幫你調 SQL 查詢效能吧？
前後端分離想解決的核心問題就是：讓專業的人做專業的事。
分離之後，前端用自己的框架（React、Vue）、自己的打包工具、自己的部署流程。後端專心處理商業邏輯、資料庫、API 設計。兩邊透過 API 文件溝通，各做各的，互不干擾。
但分離不是沒代價
你有沒有遇過這種情況：前端說「API 回傳的格式不對」，後端說「我照文件做的啊」，結果兩邊拿出來的文件版本不一樣？
分離帶來的最大痛點就是溝通成本。以前一個人寫完就好，現在要開會對 API、寫文件、處理 CORS、搞 token 認證。SEO 也變成大問題——SPA 吐出來的 HTML 只有一個空的 <div id="root">，搜尋引擎看到直接翻白眼。
而且 debug 變更難了。以前出 bug 就看自己的 code，現在得先搞清楚問題在前端還是後端，有時候還卡在中間那層 API gateway。
轉型需要什麼條件？
沒有說一定要上分離架構比較好，但反過來講，當分離的利大於弊時，是什麼原因讓你不想採用？
如果你決定要從全端轉向前後端分離，至少需要：
- 懂前後端介接的人（不一定要全端，但要能看懂兩邊的 code）
- 一份像樣的 API 文件（不是口頭約定，是能跑的 Swagger 文件）
- 專案架構已經把耦合性處理得差不多了
- 團隊願意承受轉型期的陣痛
真的前後端分離了嗎？
很多團隊以為用了 React 就叫前後端分離。但如果你的 React 跑在後端的 template engine 裡面、或者前後端部署在同一台機器、共用同一個 Git repo——那只是「寫法分離」，不是「架構分離」。
真正的前後端分離，是前後端可以獨立部署、獨立開發、獨立測試。Next.js / Nuxt.js 這類 SSR 框架是目前比較完整的方案，但願意花時間搞 Node.js 的前端工程師……嗯，你知道的。
前後端分離就像離婚——不是離了就會更好，但如果真的過不下去，早分早解脫。