前言

前后端分離一直是laravel學(xué)習(xí)繞不開的話題。前期我們可以通過基于laravel優(yōu)秀的框架（比如laravel-admin,dcat-admin），快速構(gòu)建一個不需要太多前端代碼的后臺管理系統(tǒng)。但是到了后期，隨著項目量級的增加，我們還需要諸如中臺（可以簡單理解為面向用戶的管理后臺）、前端網(wǎng)站等業(yè)務(wù),如果還使用上述的框架，可能就顯得力不從心。并且在實際開發(fā)中會遇到這樣的問題：

• 公司有前端和后端工程師，前端工程師采用vue開發(fā)，而作為phper的我們采用laravel去開發(fā)。那么問題就來了，我們不可能讓前端工程師也采用laravel-mix，在laravel框架下開發(fā)，這樣很不友好。

• 原來的模式耦合度很高，不管是維護(hù)還是擴(kuò)展都相當(dāng)困難，所以減少模塊間的耦合度，對于后續(xù)的維護(hù)和擴(kuò)展都是相當(dāng)有幫助的。

概念明晰

那么這個時候，我們都會想到前后端分離。
那么什么是前后端分離呢？具體的定義今天我們不討論，有興趣可以查看這些文章：到底什么是前后端分離？，前后端分離實踐有感
明白了基本概念和思路后，我們就應(yīng)該開始干事情了。但是在開始之前，就要思考當(dāng)前項目適不適合前后端分離？什么樣的項目適合前后端分離？因為如果項目不適合的話，那么前后端分離無疑是會加重工作量，例如只是純后臺管理系統(tǒng)開發(fā)，加上接口訪問，項目訪問量也不大，那么laravel-admin這樣的模式完全能夠勝任。
到這里會有一個誤區(qū)，那就是前端代碼和后端代碼分開開發(fā)就是前后端分離（這里貌似和上面說的有點矛盾）。所謂的前后端分離不僅是為了解耦，為了方便后續(xù)維護(hù)和擴(kuò)展，本質(zhì)上是：前端項目與后端項目是兩個項目，需要獨(dú)立部署。兩個不同的工程，兩個不同的代碼庫，不同的開發(fā)人員。前后端工程師需要約定交互接口，實現(xiàn)并行開發(fā)，開發(fā)結(jié)束后需要進(jìn)行獨(dú)立部署，前端通過http請求調(diào)用后端的restful api。前端只需要關(guān)注頁面的樣式與動態(tài)數(shù)據(jù)的解析&渲染，而后端專注于具體業(yè)務(wù)邏輯（來源：為什么要前后端分離？前后端分離的好處和壞處是什么？）。
所以假設(shè)，我們的前后端本地開發(fā)已經(jīng)完成，我們需要放到線上環(huán)境去測試，那么我們?nèi)绾稳シ?wù)器進(jìn)行部署和配置呢？

相關(guān)教程推薦：《laravel教程》

開始

例如我們完成的項目是這樣的：
前端使用vue，后端使用laravel+jwt+dingo構(gòu)建了api接口，以及使用了laravel-admin作為后端管理系統(tǒng)。
按照傳統(tǒng)配置后端的方法，只配置后臺管理系統(tǒng)，我們一鍵安裝lnmp后，nginx配置一下，root直接指向項目的public目錄，或者干脆用寶塔面板，幾分鐘以后就好了。這個對于我們講武德的程序員來說叫做“點到為止”。后端直接用域名+/admin就可以使用了。
可是現(xiàn)在有了vue，需要把主域名shop.test 給前端用，我們會說尤老師，牛老師，劉老師你不講武德，尤老師說對不起，我就要用。
于是就有兩種方法可以達(dá)到使用的效果：

嘗試

1、分別部署，采用不同域名

前端域名是：vue.shop.test
后端域名是shop.test/admin
接口域名是shop.test/api
我只要在前端項目的nginx下，根目錄指向目標(biāo)文件夾就行，例如：

server{     listen 80;     server_name vue.shop.test;#域名     index index.php index.html index.htm default.php default.htm default.html;     root /www/wwwroot/vue.shop.test/dist;#根目錄    ...}

反向代理到接口地址：

#意思就是只要含有"api"的請求，都轉(zhuǎn)發(fā)到接口地址去請求 location /api    {         add_header 'Access-Control-Allow-Origin' '*';         proxy_pass http://shop.test/api;     }

后端項目配置跨域：

location / {       add_header Access-Control-Allow-Origin *;     add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';     add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';}

保存訪問前端：vue.shop.test, 可以正常訪問。

2、分別部署，采用相同域名、不同端口

這個就相對簡單很多，不需要第二個域名，效率也高的多。
例如，我的后端項目位于/www/wwwroot/test_adimin，前端項目是/www/wwwroot/test_vue，我們只需要在nginx配置里再配置監(jiān)聽另外一個端口就可以：

server{     listen 80;     server_name shop.test;     index index.php index.html index.htm default.php default.htm default.html;     root /www/wwwroot/test_adimin/public;     ...}server{     listen 8080;     server_name shop.test:8080;     index index.php index.html index.htm default.php default.htm default.html;     root /www/wwwroot/test_vue/dist;     location / {         try_files $uri $uri/ @router;#需要指向下面的@router否則會出現(xiàn)vue的路由在nginx中刷新出現(xiàn)404         index  index.html index.htm;         # try_files $uri $uri/ /index.html;     }     #這里要寫，不然會報：     #We’re sorry but XXX doesn’t work properly without JavaScript enabled     #網(wǎng)上說的把history改為hash就可以，那個不行，不適用于現(xiàn)在的情況。     location /api    {         add_header 'Access-Control-Allow-Origin' '*';         proxy_pass http://shop.test/api;     }     ...}

配置成功保存，訪問shop.test:8080 速度杠杠的。

總結(jié)

優(yōu)點

1.前后端開發(fā)人員各司其職，各自部署，相互不干涉，提高開發(fā)效率。
2.能夠?qū)崿F(xiàn)解耦，使得業(yè)務(wù)更加清晰，減少業(yè)務(wù)復(fù)雜程度。

缺點

1.增加開發(fā)、部署難度；
2.提高了對接和溝通成本；
3.不是所有的項目都適合前后端分離，需要框架設(shè)計者、開發(fā)者自己去判斷