把流程從由此可見，前後端分離的主要概念就是：後台只需提供api介面，前端呼叫ajax實現資料呈現。 作為一名前端開發人員，我們應該嘗試一些新穎的技術，完善每乙個細節性的問題，不斷突破自我。雖然前後端分離已經算不上什麼新穎的技術或思路，但是目前很多後台開發人員甚至前端開發人員都沒有接觸過。pm：「我要這個功能」
後端：「這個先找前端做個模板」
前端：「模板做完了」
後端：「我來對接一下，這裡樣式不對」
前端：「我改完了」
後端：「功能交付」
pm：「春節要加這個活動」
後端：「這個先找前端改個模板」
前端：「模板做完了」
後端：「我來對接一下，這裡樣式不對」
前端：「我改完了」
後端：「功能交付」
變成 pm：「我要這個功能」
前端：「我要介面」
後端：「介面完成了」
前端：「我來對接一下，功能交付」
pm：「春節要加這個活動」
前端：「需要增加介面」
後端：「介面完成了」
前端：「我來對接一下，功能交付」
據我個人的了解，如果在乙個部門裡，部門人員全是後台開發人員，前端的一些頁面也是由後台人員完成的，那麼前後端分離對於他們而言可能是一片未知的領域，專案大多是前後端強耦合的，甚至不存在前端的概念。
在不重視前端的公司或部門，不了解前後端分離這也無可厚非。在我剛進入乙個全是後台開發人員的部門的時候，整個部門就我乙個前端，我剛開始的主要職責就是負責專案前端頁面的製作和js功能的實現，雖然部門有前後端分離的意識，但都不知該如何去實踐。在那時，部門的後台人員認為前後端分離就是後台不再需要寫html和js了，可以交給前端來做了，然而這只能叫做前後端分工。
以上講述的是一種情況: 不了解前後端分離，也不知如何去實踐的。下面還有一種情況：了解前後端分離，但不想去嘗試的。
針對第二種情況，很多人也做過相應的解釋，其實這就涉及到「前後端分離的利弊」問題。很多後台人員會認為自己所做的那一套沒有問題，即便後台套用前端html也是司空見慣，一直是大勢所趨，後台mvc框架也是這麼推薦使用的，很合理。這時候前端開發人員在部門中的話語權往往是不夠的，或者認為後台開發人員的意見永遠是對的，沒有主觀性。
相反，也有可能是後台開發人員非常推薦前後端分離，而前端開發人員不想去實踐的。這時候前端會認為後台開發人員在瞎折騰，之前前後端不分離專案做起來都很順利，分離了反而會給自己帶來額外的工作量和學習成本，而這就取決於前端的技術能力和見識了。
當然，這也是我個人認為的前後端分離所存在的一些現狀和分歧所在。
對於前後端分離的應用場景，不是所有的場景都適合，但是大多數專案都能夠通過前後端分離來實現。由於我主要從事企業級後台應用的前端開發工作，個人認為對於後台應用的開發來說，前後端分離帶來的利是遠大於弊的。
大多數後台應用我們都可以做成spa應用（單頁應用），而單頁應用最主要的特點就是區域性重新整理，這通過前端控制路由呼叫ajax，後台提供介面便可以實現，而且這樣的方式使用者體驗更加友好，網頁載入更加快速，開發和維護成本也降低了不少，效率明顯提公升。
隨著前端技術的發展和迭代，前端mvc框架應運而生，利用目前主流的前端框架，如react、vue、angular等我們可以輕鬆的構建起乙個無需伺服器端渲染就可以展示的**，同時這類框架都提供了前端路由功能，後台可以不再控制路由的跳轉，將原本屬於前端的業務邏輯全部丟給前端，這樣前後端分離可以說是最為徹底。下面是一段前端控制路由的**：
'use strict'
export default
function
(router)
},'/m/:params':
},'/p': ,
subroutes: }}
}})
}
1.徹底解放前端前端不再需要向後台提供模板或是後台在前端html中嵌入後台**，如：
value=''>--請選擇所屬業務--option>
value="
}">
}option>
select>
id="rander">
value=''>--請選擇所屬業務--option>
v-for="list in lists"
:value="list"
v-text="list">
option>
select>
template>
export default
}，ready: function
() )
.then(function
(response) )
}}script>
2.提高工作效率，分工更加明確前後端分離的工作流程可以使前端只關注前端的事，後台只關心後台的活，兩者開發可以同時進行，在後台還沒有時間提供介面的時候，前端可以先將資料寫死或者呼叫本地的json檔案即可，頁面的增加和路由的修改也不必再去麻煩後台，開發更加靈活。
3.區域性效能提公升通過前端路由的配置，我們可以實現頁面的按需載入，無需一開始載入首頁便載入**的所有的資源，伺服器也不再需要解析前端頁面，在頁面互動及使用者體驗上有所提公升。
4.降低維護成本通過目前主流的前端mvc框架，我們可以非常快速的定位及發現問題的所在，客戶端的問題不再需要後台人員參與及除錯，**重構及可維護性增強。 一路走來，專案乙個接著乙個，從一開始的後台控制路由、後台渲染頁面到現在的前端控制路由、前端渲染資料，工作流程和方式都發生了很大的變化。每當遇到下面情形的時候，我都會為前後端分離帶來的優勢而感慨一番：
專案一開始製作前端頁面的時候，我不再需要後台給我配置伺服器環境了
專案的前端檔案可以在需要呼叫後台介面的時候丟進伺服器就好了，完全不需要事先放進去
增加乙個專案頁面需要配置路由的時候不再需要讓後台同事給我加了，自己前端搞定
前端檔案裡不再摻雜後台的**邏輯了，看起來舒服多了
頁面跳轉比之前更加流暢了，區域性渲染區域性載入非常快速
頁面模板可以重複使用了，前端元件化開發提高了開發效率
等等。面對快速發展的前端，我們應該去適應其帶來的工作方式和流程的改變，目前的前後端分離的工作方式必然是今後的趨勢所在，作為乙個前端開發人員，我們應當承擔這個普及前端新知識和改變現狀的職責。
我們為什麼要嘗試前後端分離
如果你沒有嘗試過前後端分離的工作流程，那麼可以先試想一下這樣的流程改變 把流程從 pm 我要這個功能 後端 這個先找前端做個模板 前端 模板做完了 後端 我來對接一下，這裡樣式不對 前端 我改完了 後端 功能交付 pm 春節要加這個活動 後端 這個先找前端改個模板 前端 模板做完了 後端 我來對接一...
我們為什麼要嘗試前後端分離
來自乙個蘿蔔乙個坑 如果你沒有嘗試過前後端分離的工作流程，那麼可以先試想一下這樣的流程改變 把流程從 pm 我要這個功能 後端 這個先找前端做個模板 前端 模板做完了 後端 我來對接一下，這裡樣式不對 前端 我改完了 後端 功能交付 pm 春節要加這個活動 後端 這個先找前端改個模板 前端 模板做完...
前後端分離的好處 談談我們為什麼要前後端分離
隨著不同終端的興起，對開發人員的要求越來越高，純瀏覽器端的響應式已經不能滿足使用者體驗的高要求，我們往往需要針對不同的終端開發定製的版本，為了提公升開發效率，前後端分離的需求越來越被重視，前端主要負責頁面的展現和互動邏輯，後端主要負責業務和資料介面，同乙份資料介面，我們可以定製開發多個版本。前後端不...