前后端分離，即前端頁面脫離后端服務(wù)也可以單獨運(yùn)行。
我從開發(fā)和上線兩個部分簡單說一下。

• 開發(fā)

前端開發(fā)不再依賴后端服務(wù)，定義好數(shù)據(jù)結(jié)構(gòu)和接口名稱就可以了。
比如采用restful的模式：前端使用mock，后端使用swagger。
這樣就不會由一端而影響另一端的進(jìn)度。再者，后端可以同時支持web、移動以及第三方的系統(tǒng)。

• 上線

前后端可以獨立部署，不再將前端的文件放到后端的服務(wù)中。也可以更好的做負(fù)載等一些運(yùn)維的操作。

再說說SSR，也就是服務(wù)端渲然。目前要在需要支持SEO的情況下，才會做SSR。

這種面試題我覺的算是開放性的問題了，要仔細(xì)說，東西太多了，如果要是考察的話，可能就是為了考察下實際工作中是否遇到一些坑以及解決辦法吧，我就分享一些我遇到過的問題以及解決辦法：

• 首先第一點是先考慮項目需不需要前后端分離，如果是重前端類型的項目，比如網(wǎng)盤這種，那前后端分離確實可行，如果是博客這種內(nèi)容驅(qū)動式的項目，就不要前后端分離了，沒什么意義
• 接口返回數(shù)據(jù)格式經(jīng)常會遇到后端返回的數(shù)據(jù)不是前端所期望的，這種情況下不是后端改接口就是前端做數(shù)據(jù)處理，總之是經(jīng)常會發(fā)生口角的地方，解決方法有很多，比如提前溝通并設(shè)計大家都滿意的數(shù)據(jù)格式、做中間層服務(wù)（比較復(fù)雜的項目）、嘗試一些帶 schema 約束的接口規(guī)范，比如 json-restful 或者 GraphQL 等等
• 我理解的前后端分離僅僅是代碼邏輯上的分離，在實際工作中，還是要多和后端溝通，及時反饋一些項目實施過程中的問題，因為有些問題可能前端解決是可以的，有些問題后端解決可能更好，比如像一些權(quán)限方面的東西，最好不要在前端鑒權(quán)
• 緩存我認(rèn)為也是前后端分離中的一個大坑，這個就不展開說了，涉及東西太多
• 如果是 SPA 還想在 SEO 上取得一些優(yōu)化的話，還給整 SSR

具體 SSR 渲染的東西，我就不亂說了，因為真的是簡單接觸并做過一些小的 DEMO 項目，并沒有真實線上項目的實踐經(jīng)驗，坑也踩的少。

以上個人拙見，如有錯誤，還望指正。