大家好，關于php前后端分離很多朋友都還不太明白，今天小編就來為大家分享關于php前后端分離框架有哪些的知識，希望對各位有所幫助！
前后端分離是否會影響首屏加載時間
如今很多公司為了提高開發效率采用前后端分離的開發模式，這是架構上的分離解耦，前后端各司其職，通過RESTfulAPI來調用數據。這樣做的好處也有不少，如：
邏輯分離：業務邏輯放在后端，前端邏輯放在前端，這樣一來，數據及邏輯上都很清晰；
前后端分離部署：減輕了后端服務器的壓力，后端服務器不需要負責前端頁面的渲染，只負責數據處理，性能上會有所提高；
復用性較高：前后端分離本質上也是系統分離，可以做到同一個后端系統提供數據給多個前端系統，擴展性更高；
并行開發，提高效率：前后端并行開發，提前約定好數據格式即可（mock），提升了項目開發效率。
但是，前后端分離也帶來了一些問題，比如大家比較關注的首屏加載渲染時間的問題。
對于前后端分離會不會影響首屏加載，我想說的是，多少都是有的，但影響程度要看代碼的質量了，只要優化得好，首屏加載時間不會太慢。
我們在進行前后端分離時有一些技巧來縮短首屏加載時間的，分享給大家：
前端與后端分別部署，都走CDN加速；
前端盡可能少的調用多個API，建議調用一個API網關來實現多個API的請求合并；
后端API域名使用單獨域名，禁止cookies傳輸；
部分數據本地緩存處理；
不重要的數據惰性請求加載。
綜上，前后端分離在一定程度上是會影響首屏加載時間的，但是也有調優方案，總體上時間不會相差太多。
以上回答希望對大家有所幫助，如果其它網友有不同見解，也歡迎在下方評論交流~
Web項目開發為何要走前后端分離模式
把前端與后端獨立起來去開發，放在兩個不同的服務器，需要獨立部署，兩個不同的工程，兩個不同的代碼庫，不同的開發人員，前后端工程師需要約定交互接口，實現同步開發，開發結束后需要進行獨立部署，前端通過接口來調用調用后端的API，前端只需要關注頁面的樣式與動態數據的解析和渲染，而后端專注于具體業務邏輯。具體好處有以下幾點：
1.徹底解放前端
前端不再需要向后臺提供模板或是后臺在前端html中嵌入后臺代
2.提高工作效率，分工更加明確
前后端分離的工作流程可以使前端只關注前端的事，后臺只關心后臺的活，兩者開發可以同時進行，在后臺還沒有時間提供接口的時候，前端可以先將數據寫死或者調用本地的json文件即可，頁面的增加和路由的修改也不必再去麻煩后臺，開發更加靈活。
3.局部性能提升
通過前端路由的配置，我們可以實現頁面的按需加載，無需一開始加載首頁便加載網站的所有的資源，服務器也不再需要解析前端頁面，在頁面交互及用戶體驗上有所提升。
4.降低維護成本
通過目前主流的前端MVC框架，我們可以非常快速的定位及發現問題的所在，客戶端的問題不再需要后臺人員參與及調試，代碼重構及可維護性增強。
5.實現高內聚低耦合，減少后端（應用）服務器的并發/負載壓力。
6.即使后端服務暫時超時或者宕機了，前端頁面也會正常訪問，但無法提供數據。
7.可以使后臺能更好的追求高并發，高可用，高性能；使前端能更好的追求頁面表現、速度流暢、兼容性、用戶體驗等。
HTML和php有什么不同
HTML和php的區別還是比較大的。
HTML屬于超文本標記語言，主要作用在前端，配合css/js用來開發網站，webapp等各種前端。
php屬于服務端腳本語言，可用于服務端的接口開發。
兩者結合可用于開發一個包括前后端的完整的網站。
php落伍了嗎
php沒有落伍。
只不過php的地位確實很尷尬，目前都是流行前后端分離，php也基本上就是寫API接口了，但寫后端的話，JAVA，PYTHOH，Node等都可以寫呀，而且在某些場景下比php更適合，PHP+SWOOLE倒還能在一些需要高性能，高并發，多進程等場景下發揮一些用處，但說實話，要是我自已來選型的話，我寧愿去用Go去寫一些服務端，相比去學swoole，學go的成本并不高，而且go的各種框架和社區也成熟，php也就寫些簡單的業務邏輯了。
php一般在小公司用的多，弄點框架快速開發就行，稍微有點規模的公司，php一般都不是主力語言，而且更多的是做一些簡單邊緣的業務，也就是大家說的事情感覺做了好多，但其實可能對公司來說并無太大價值，你自身也感覺技術無太大提升，因為他們認為php就是做這么簡單的事，就是顯示下數據，高級的都是Java或其它的做了。
php也不是做不了大項目，只是由于它的規范不像Java那樣，真要拿php去做大項目，需要考慮和設計的問題太多了，與其那樣，干嘛不用Java這種呢.
前后端分離項目，如何解決跨域問題
前后端分離項目跨域問題是不可避免的。通常情況下前端由React、Vue等框架編寫，通過ajax請求服務端API，傳輸數據用json格式。
那么為什么有跨域的問題呢？解決跨域問題有哪些方式？搞清楚這兩個問題我們需要了解一下什么是同源策略。
瀏覽器的同源策略同源策略（Sameoriginpolicy）是一種安全約定，是所有主流瀏覽器最核心也是最基本的安全功能之一。同源策略規定：不同域的客戶端腳本在沒有明確授權的情況下，不能請求對方的資源。同源指的是：域名、協議、端口均相同。
比如我們訪問一個網站
http://www.test.com/index.html,
那么這個頁面請求如下地址得情況是這樣的：另外，同源策略又分如下兩種情況：
DOM同源策略：禁止對不同源的頁面DOM進行操作，主要防止iframe的情況。比如iframe標簽里放一個支付寶付款的頁面，如果沒有同源策略，那么釣魚網站除了域名不同，其他的則可以和支付寶的網站一模一樣。
XMLHttpRequest同源策略：禁止使用XHR對象向不同源的服務器發起http請求。比如網站記錄了銀行的cookie，這個時候你訪問了惡意網站，黑客拿到你的cookie，再通過ajax請求之前的銀行網站，便可以輕易的拿到你的銀行信息。
所以，正是因為有了同源策略，大家的網絡環境才相對的安全一些。
跨域問題的解決辦法了解了同源策略，就知道為什么會有跨域問題的產生了，都是為了安全。但是實際研發中，大家還是需要跨域去訪問資源。典型的應用場景就是前后端分離的項目了。那么我們如何去解決跨域問題呢？
CORS-跨域資源共享CORS是一種W3C標準，定義了當產生跨域問題的時候，客戶端與服務端如何通信解決跨域問題。實際上就是前后端約定好定義一些自定義的http請求頭，讓客戶端發起請求的時候能夠讓服務端識別出來該請求是過還是不過。
瀏覽器將CORS請求分為簡單請求和非簡單請求：
簡單請求簡單請求必須滿足以下兩個條件：
請求方式必須是HEAD、GET、POST三種方法之一。
Http請求頭必須只能是：Accept、Accept-Lanuage、Content-Lanuage、Last-Event-ID、Content-Type，其中Content-Type只限于三個值application/x-www-form-urlencoded、multipart/form-data、text/plain。
非簡單請求不滿足簡單請求條件的就是非簡單請求。針對非簡單請求，瀏覽器會發起預檢請求。預檢請求的意思是當瀏覽器檢查到你的頁面含有跨域請求的時候，會發送一個OPTIONS請求給對應的服務器，以檢測服務器是否允許當前域名的跨域請求。如果服務端允許該域名請求，則返回204或200狀態碼，瀏覽器接收到允許請求時候再繼續發送對應的GET/POST/PUT/DELETE請求。同時服務器端也會告知瀏覽器預檢請求的緩存時長是多少，在這個時間范圍內，瀏覽器不會再次發起預檢請求。
原理基本上就是上面說的這些，實際業務中我們如何通過配置來解決跨域問題呢？基本上常見的就是三種方式：
nginx配置通常我們在nginx增加如下配置即可解決跨域問題：
用nginx這種方式是最舒服的，不需要客戶端和服務端多做其他工作，對代碼無入侵。
jsonp因為script標簽是不受瀏覽器同源策略的影響，允許跨域請求資源（我們的每一個頁面都引用了大量第三方js文件）。所以可以利用動態創建script標簽，通過src屬性發起跨域請求，這就是jsonp的原理。但是jsonp只支持GET請求，所以并不是一種好的方式。
服務端代碼控制可以在服務端增加對跨域請求的支持：
這種方式相當于全局過濾器，對所有請求都過濾一遍。
以上三種方式都可以一定程度上解決跨域問題，但是nginx配置和服務端控制不能同時存在，否則會報“Access-Control-Allow-OriginNotAllowMultiplevalue”的錯誤。個人比較推薦nginx配置的方式，一勞永逸，不需要每個web項目都去編寫跨域的代碼。
大家在工作中有沒有遇到過跨域問題呢？都是怎么解決的？歡迎評論區交流討論，共同學習~
php前后端分離的介紹就聊到這里吧，感謝你花時間閱讀本站內容，更多關于php前后端分離框架有哪些、php前后端分離的信息別忘了在本站進行查找哦。
