㈠ JSP如何做到前端後分離開發
可以設置一個前端項目，跟後台用Ajax/json來交互信息.
不過注意跨域的問題，可以搜索一下前端跨域學習
㈡ 前後端分離方案以及技術選型
作者：關開發
一.什麼是前後端分離？
理解前後端分離大概可以從3個方面理解：
1. 交互形式
2. 代碼組織形式
3. 開發模式與流程
1.1 交互形式
前後端不分離
後端將數據和頁面組裝、渲染好了之後，向瀏覽器輸出最終的html；瀏覽器接收到後會解析html，解析引入的css、執行js腳本，完成最終的頁面展示。
前後端分離
後端只需要和前端約定好接收以及返回的數據格式（一般用JSON格式），向前端提供API介面。前端就可以通過HTTP請求調用API的方式進行交互。前端獲取到數據後，進行頁面組裝、渲染，最終在瀏覽器呈現。
1.2 代碼組織形式
前後端不分離
在web應用早期的時候，前端頁面以及後台業務數據處理的代碼都放在一個工程下，甚至放在同一目錄下，前端頁面夾雜著後端代碼。前、後端開發工程師都需要把整套代碼導入開發工具才能開發。此階段下前後端代碼以及工作耦合度太高，前端不能獨立開發和測試，後端人員也要依賴前端完成頁面後才能完成開發。最糟糕的情況是前端工程師需要會後端模板技術（jsp），後端工程師還要會點前端技術，需要口頭說明頁面數據介面，才能配合完成開發。否則前端只能當一個「切圖仔」，只輸出HTML、CSS、以及很少量與業務邏輯無關的js；然後由後端轉化為後端jsp，並且還要寫業務的js代碼。
前後端分離
前後端代碼放在不同的工程下，前端代碼可以獨立開發，通過mock/easy-mock技術模擬後端API服務可以獨立運行、測試；後端代碼也可以獨立開發，運行、測試，通過swagger技術能自動生成API文檔供前端閱讀，還可以進行自動化介面測試，保證API的可用性，降低集成風險。
1.3 開發模式與流程
前後端不分離
在項目開發階段，前端根據原型和UI設計稿，編寫HTML、CSS以及少量與業務無關的js（純效果那些），完成後交給後台人員，後台人員將HTML轉為jsp，並通過JSP的模板語法進行數據綁定以及一些邏輯操作。後台完成後，將全部代碼打包，包含前端代碼、後端代碼打成一個war，然後部署到同一台伺服器運行。頂多做一下動靜分離，也就是把圖片、css、js分開部署到nginx。
具體開發流程如下：圖略
前後端分離
實現前後端分離之後，前端根據原型和UI設計稿編寫HTML、CSS以及少量與業務無關的js（純效果那些），後端也同時根據原型進行API設計，並與前端協定API數據規范。等到後台API完成，或僅僅是API數據規范設定完成之後。前端即可通過HTTP調用API，或通過mock數據完成數據組裝以及業務邏輯編寫。前後端可以並行，或者前端先行於後端開發了。
具體開發流程如下：圖略
二、前後端分離的好處與壞處。
從上面3個方面對比了之後，前後端分離架構和傳統的web架構相比，有很大的變化，看起來好處多多。到底是分還是不分，我們還是要理性分析是否值得才去做。
從目前應用軟體開發的發展趨勢來看，主要有兩方面需要注意：
· 越來越注重用戶體驗，隨著互聯網的發展，開始多終端化。
· 大型應用架構模式正在向雲化、微服務化發展。
我們主要通過前後端分離架構，為我們帶來以下四個方面的提升：
· 為優質產品打造精益團隊
通過將開發團隊前後端分離化，讓前後端工程師只需要專注於前端或後端的開發工作，是的前後端工程師實現自治，培養其獨特的技術特性，然後構建出一個全棧式的精益開發團隊。
· 提升開發效率
前後端分離以後，可以實現前後端代碼的解耦，只要前後端溝通約定好應用所需介面以及介面參數，便可以開始並行開發，無需等待對方的開發工作結束。與此同時，即使需求發生變更，只要介面與數據格式不變，後端開發人員就不需要修改代碼，只要前端進行變動即可。如此一來整個應用的開發效率必然會有質的提升。
· 完美應對復雜多變的前端需求
如果開發團隊能完成前後端分離的轉型，打造優秀的前後端團隊，開發獨立化，讓開發人員做到專注專精，開發能力必然會有所提升，能夠完美應對各種復雜多變的前端需求。
· 增強代碼可維護性
前後端分離後，應用的代碼不再是前後端混合，只有在運行期才會有調用依賴關系。應用代碼將會變得整潔清晰，不論是代碼閱讀還是代碼維護都會比以前輕松。
那麼前後端分離有什麼不好的地方嗎？我目前是沒有想到，除非你說會增加前端團隊的配備，後端工程師會變的不全能。。。
二、前後端分離架構方案。
實現前後端分離，主要是前端的技術架構變化較大，後端主要變為restfull 風格API，然後加上Swagger技術自動生成在線介面文檔就差不多了。
對於目前用於前後端分離方案的前端技術架構主要有兩種：
· 傳統SPA
· 服務端渲染SSR
2.1 傳統SPA
傳統SPA指的是單頁面應用，也就是整個網站只有一個頁面，所有功能都通過這一個頁面來呈現。因為一個人的肉眼，某一個時間點看一個頁面，既然如此何必要不同功能做多個頁面呢？只保留一個頁面作為模板，然後通過路由跳轉來更新這個模板頁面的內容不就可以了嗎？確實如此，現在通過reac全家桶、tvue全家桶，模塊化、路由、wabpack等技術輕而易舉就能實現一個單頁面應用。
單頁面應用的運行流程
1.用戶通過瀏覽器訪問網站url
2.單頁面的html文件（index.html）被下載到瀏覽器，接著下載html裡面引用的css，js。
3.css，js下載到瀏覽器完成之後，瀏覽器開始解析執行js向後端服務非同步請求數據。
4.請求數據完成後，進行數據綁定、渲染，最終在用戶瀏覽器呈現完整的頁面。
2.2 服務端渲染
服務端渲染的方案指的是數據綁定，渲染等工作都放在服務端完成，服務端向瀏覽器輸出最終的html。大家看完這個是不是有個疑問，這不是又回到了前後端不分離的時代了嗎？答案是否定的，因為這里的服務端是用來執行前端數據綁定、渲染的，也就是把瀏覽器的一部分工作分擔到了服務端。而目前具備這只種能力的服務端是NodeJs服務端。
它的原理其實就是在瀏覽器與前端代碼中間插入了一個NodeJs服務端。瀏覽器請求前端頁面時，會先經過NodeJS服務端，由NodeJs去讀取前端頁面，並執行非同步後端API，獲取到數據後進行頁面數據綁定，渲染等工作，完成一個最終的html然後返回瀏覽器，最後瀏覽器進行展示。
服務端渲染應用的運行流程：
1.用戶通過瀏覽器訪問網站url
2.NodeJS服務端接收到請求，讀取到對應的前端html，css，js。
3.NodeJS解析執行js向後端API非同步請求數據。
4.NodeJs請求數據完成之後，進行數據綁定、渲染，得到一個最終的html。
5.NodeJs向瀏覽器輸出html，瀏覽器進行展示。
PS：其實本質就是把前端編寫成一個nodeJs的服務端web應用。實施服務端渲染後，我們最終運行的是一個Nodejs服務端應用。而單頁面應用是把靜態頁面部署到靜態資源伺服器進行運行。
看到這里，你是否又有疑問，為什麼要這么麻煩搞服務端渲染呢？
2.3 SPA與服務端渲染方案對比
SPA的優點是開發簡單，部署簡單；缺點是首次載入較慢，需要較好的網路，不友好的SEO。
so，以下就是使用服務端渲染的理由了（摘取vue官方說法）：
與傳統 SPA (單頁應用程序 (Single-Page Application)) 相比，伺服器端渲染 (SSR) 的優勢主要在於：
· 更好的 SEO，由於搜索引擎爬蟲抓取工具可以直接查看完全渲染的頁面。
請注意，截至目前，Google 和 Bing 可以很好對同步 JavaScript 應用程序進行索引。在這里，同步是關鍵。如果你的應用程序初始展示 loading 菊花圖，然後通過 Ajax 獲取內容，抓取工具並不會等待非同步完成後再行抓取頁面內容。也就是說，如果 SEO 對你的站點至關重要，而你的頁面又是非同步獲取內容，則你可能需要伺服器端渲染(SSR)解決此問題。
· 更快的內容到達時間 (time-to-content)，特別是對於緩慢的網路情況或運行緩慢的設備。
無需等待所有的 JavaScript 都完成下載並執行，才顯示伺服器渲染的標記，所以你的用戶將會更快速地看到完整渲染的頁面。通常可以產生更好的用戶體驗，並且對於那些「內容到達時間(time-to-content) 與轉化率直接相關」的應用程序而言，伺服器端渲染 (SSR) 至關重要。
使用伺服器端渲染 (SSR) 時還需要有一些權衡之處：
· 開發條件所限。瀏覽器特定的代碼，只能在某些生命周期鉤子函數 (lifecycle hook) 中使用；一些外部擴展庫 (external library) 可能需要特殊處理，才能在伺服器渲染應用程序中運行。
· 涉及構建設置和部署的更多要求。與可以部署在任何靜態文件伺服器上的完全靜態單頁面應用程序 (SPA) 不同，伺服器渲染應用程序，需要處於 Node.js server 運行環境。
· 更多的伺服器端負載。在 Node.js 中渲染完整的應用程序，顯然會比僅僅提供靜態文件的 server 更加大量佔用 CPU 資源 (CPU-intensive - CPU 密集)，因此如果你預料在高流量環境 (high traffic) 下使用，請准備相應的伺服器負載，並明智地採用緩存策略。
以vue為例，實施服務端渲染可以查看官方指南： https://ssr.vuejs.org ，或選擇Nuxt.js
2.4 預渲染技術
如果你調研伺服器端渲染 (SSR) 只是用來改善少數營銷頁面（例如 /, /about, /contact 等）的 SEO，那麼你可能需要預渲染。無需使用 web 伺服器實時動態編譯 HTML，而是使用預渲染方式，在構建時 (build time) 簡單地生成針對特定路由的靜態 HTML 文件。優點是設置預渲染更簡單，並可以將你的前端作為一個完全靜態的站點。
如果你使用 webpack，你可以使用 prerender-spa-plugin 輕松地添加預渲染。它已經被 Vue 應用程序廣泛測試 - 事實上，作者是 Vue 核心團隊的成員。
prerender-spa-plugin: https://github.com/chrisvfritz/prerender-spa-plugin
三、前後端分離技術選型
- artTemplate + bootstrap（不推薦， 不算完全前後端分離）
- vue全家桶（推薦）
- react全家桶 （推薦，生態全）
㈢ 前端和後端分離開發測試怎麼整合
既然是分離開發了，那應該不好整合測試。
前端也有用到後端介面，測試前端的時候其實也是在測試後端了。
㈣ Web項目開發為何要走前後端分離模式
把前端與後端獨立起來去開發，放在兩個不同的伺服器，需要獨立部署，兩個不同的工程，兩個不同的代碼庫，不同的開發人員，前後端工程師需要約定交互介面，實現同步開發，開發結束後需要進行獨立部署，前端通過介面來調用調用後端的API，前端只需要關注頁面的樣式與動態數據的解析和渲染，而後端專注於具體業務邏輯。具體好處有以下幾點：
1.徹底解放前端
前端不再需要向後台提供模板或是後台在前端html中嵌入後台代
2.提高工作效率，分工更加明確
前後端分離的工作流程可以使前端只關注前端的事，後台只關心後台的活，兩者開發可以同時進行，在後台還沒有時間提供介面的時候，前端可以先將數據寫死或者調用本地的json文件即可，頁面的增加和路由的修改也不必再去麻煩後台，開發更加靈活。
3.局部性能提升
通過前端路由的配置，我們可以實現頁面的按需載入，無需一開始載入首頁便載入網站的所有的資源，伺服器也不再需要解析前端頁面，在頁面交互及用戶體驗上有所提升。
4.降低維護成本
通過目前主流的前端MVC框架，我們可以非常快速的定位及發現問題的所在，客戶端的問題不再需要後台人員參與及調試，代碼重構及可維護性增強。
5.實現高內聚低耦合，減少後端（應用）伺服器的並發/負載壓力。
6.即使後端服務暫時超時或者宕機了，前端頁面也會正常訪問，但無法提供數據。
7.可以使後台能更好的追求高並發，高可用，高性能；使前端能更好的追求頁面表現、速度流暢、兼容性、用戶體驗等。
我理解的前後端分離，前端是需要起伺服器的，減少學習成本，可以用node，前端也要有域名的
如果是半分離， 那麼前端提供js文件（css等）這個我也做過，前後端都用node就不說了，如果是兩種語言，
如果一個工程文件下開發，webpack下直接打包進後台語言的靜態目錄下。
如果是兩個工程，那麼前端只提供生成的js（css）文件，git pull後台項目，扔進靜態目錄，這樣又涉及到版本控制的問題，一般我會生成一個配置文件，直接讀取的，內容是xxx.hash.js這種文件名，然後document.wirte動態寫入js/css
前端起伺服器就不需要動態引入了，直接html插件生成文件，更好的控製版本
半分離 還有一個問題，例如首頁同構，如果更改xxx.blade.php文件，這就又動了php文件，甚至包括nginx反向代理啊，ssl這種緩存啊，都比較麻煩，你要是改了點啥，自己的ok了，後台的崩了，那就挺操蛋了，大公司有專門的運維還好，小公司真的是一團糟
後台我們採取全分離，nginx前端管理，至於升級nginx版本，http2，反向代理，https證書，都是前端自己弄，畢竟小公司，每個人水平都不一致，自己負責自己的比較好
但是這個跨域又要稍微處理一下，至今我這邊後台還是*，我也沒法說什麼
阿里雲這么便宜，如果把成本浪費在人力上，會變得很貴
一個人的精力有限，前後端分離有助於我們更專注我們所要注重的技術點，俗話說：「術業有專攻」。
比如我們後端，前後端分離有助於我們把注意力放在java基礎，設計模式，jvm原理，spring+springmvc原理及源碼，linux，mysql事務隔離與鎖機制，mongodb，http/tcp，多線程，分布式架構（bbo，bbox，spring cloud），彈性計算架構，微服務架構（springboot+zookeeper+docker+jenkins），java性能優化，以及相關的項目管理等等。
而前端也可以集中精力在前端的展示上。
總的來說，前後端分離利大於弊。這也是越來越少用jsp的原因。
補充兩點
1.每次請求的數據量變小，也意味著更少的響應時間。
2.也不是每個應用用前後端分離都是最合適的，要根據應用規模，工期綜合判斷。
㈤ web前端開發，前後端分離具體是怎麼樣的工作模式
前後端分離，顧名思義就是前端只負責前端的開發，後端只只負責後端的開發，如何通過介面來進行數據交互。
這樣做的好處就是：開發可以同時進行，代碼維護更加方便，前端只需要拿到後端提供的介面，傳遞對應的數據就可以了，然後再把後端返回的數據渲染到前端頁面上。
至於跨域問題是可以解決的，一般讓後端解決就行了。最後上傳到伺服器的也很簡單，你前端的就上傳你開發的前端代碼，後端的就上傳他後端的代碼就搞定了
㈥ VB.Net 前後端分離怎麼實現的
1.一般來說，要實現前後端分離，前端就需要開啟一個本地的伺服器來運行自己的前端代碼，以此來模擬真實的線上環境，並且，也是為了更好的開發。因為你在實際開發中，你不可能要求每一個前端都去搭建一個java(php)環境，並且在java環境下開發，這對於前端來說，學習成本太高了。
?2.但如果本地沒有開啟伺服器的話，不僅無法模擬線上的環境，而且還面臨到了跨域的問題，因為你如果寫靜態的html頁面，直接在文件目錄下打開的話，你是無法發出ajax請求的(瀏覽器跨域的限制),因此，你需要在本地運行一個伺服器，可是又不想搭建陌生而龐大的java環境，怎麼辦法呢？nodejs正好解決了這個問題。在我們項目中，我們利用nodejs的express框架來開啟一個本地的伺服器，然後利用nodejs的一個http-proxy-middleware插件將客戶端發往nodejs的請求轉發給真正的伺服器，讓nodejs作為一個中間層。這樣，前端就可以無憂無慮的開發了
?3.由於前後端分離後，前端和後台同時開發時，就可能遇到前端已經開發好一個頁面了，可是卻等待後台API介面的情況。比如說A是負責前端，B是負責後台，A可能用了一周做好了基本的結構，並且需要API介面聯調後，才能繼續開發，
?4.而此時B卻還沒有實現好所需要的介面，這種情況，怎麼辦呢？在我們這個項目里，我們是通過了mock來提供一些假數據，我們先規定好了API介面，設計出了一套API文檔，然後我們就可以通過API文檔，利用mock來返回一些假數據，這樣就可以模擬發送API到接受響應的整一個過程，
?5.因此前端也不需要依賴於後端開發了，可以獨立開發，等到後台的API全部設計完之後，就可以比較快速的聯調。
㈦ 微服務架構下，進行前後端分離，前端怎麼寫
分離後的前端，不再是一個簡單的HTML文件，已經是一個獨立的應用系統。除了要考慮頁面的數據渲染展示，還要用工程化的思想來考慮前端的架構，前後端的交互和數據安全等事情。
RESTful介面交互
前後端分離之後，更多的是採用RESTful風格的介面與後端進行數據交互。
REST是「呈現狀態轉移（REpresentational State Transfer）」的縮寫，一種API的架構風格，在客戶端和服務端之間通過呈現狀態的轉移來驅動應用狀態的演進。
在 REST 樣式的 Web 服務中，每個資源都有一個地址。資源本身都是方法調用的目標，方法列表對所有資源都是一樣的。這些方法都是標准方法，包括 HTTP GET、POST、PUT、DELETE，還可能包括 HEADER 和 OPTIONS。
RESTful的API設計，使得後端通過介面向前端傳遞數據，數據的格式通常是JSON這種通用的格式。對前端來說，只要後端返回過來的是RESTful的數據就行，不管後端是用Java寫，還是用python或PHP，拜託對後端的依賴，做到前端系統的獨立。
工程化構建
Nodejs不止可以用來做前端伺服器，在開發階段，它也能發揮很大的作用。
前端生態的發展，是圍繞著Nodejs進行的。用npm來管理項目依賴，可以很好的維護和運行在Nodejs環境上。
打包工具grunt、gulp、webpack和rollup等，都是運行在nodejs上，再結合語法編譯、打包部署等插件，將應用輸入成一個完整的應用。
如果你使用了Angular、React或Vue框架，或者你使用瀏覽器暫時還不兼容的ES6語法，還需要在應用打包前用babel將語法編譯成瀏覽器可識別的ES5的語法。
SPA
SPA是單頁Web應用（single page web application，SPA）的簡寫，就是只有一張Web頁面的應用，是載入單個HTML 頁面並在用戶與應用程序交互時動態更新該頁面的Web應用程序。
像Angular、React或Vue就是為了SPA而設計的，結合前端路由庫（react-router、vue-router）和狀態熱存儲（rex、vuex）等，可以開發出一個媲美Native APP的Web APP，用戶體驗得到了很大的提升。
當然，SPA也不是完美的，也不是適合所有的web應用，需要結合項目和場景來選擇。
SPA有如下缺點：
初次載入耗時增加。可以通過代碼拆分、懶載入來提升性能，減少初次載入耗時。
SEO不友好，現在可以通過Prerender或Server render來解決一部分。
頁面的前進和後端需要開發者自己寫，不過現在一些路由庫已經幫助我們基本解決了。
對開發者要求高，由於做SPA需要了解一整套技術棧，所以，要考慮後期是否有合適的人選進行維護。
㈧ Web前端該如何與後端合作
今天小編要跟大家分享的文章是關於web前端該如何與後端合作?為了幫助web前端工程師更好的從事工作，提高工作效率，下面來和小編一起看一看吧！
1、前後端分離
前端與後端的分離，能使前端的開發脫離後端的開發模式，擁有更大的自由度，以此便可做前端工程化、組件化、單頁面應用等。
2、盡量避免後端模板渲染
web應用的渲染方式分為伺服器端渲染和客戶端渲染，當下比較推薦的方式是客戶端渲染，數據使用全ajax的方式進行交互。
除非在一些不得不使用伺服器端渲染的情況下(如門戶、電商等)，應當盡量使用客戶端渲染，因為客戶端渲染更能使前後端分離(項目分離、代碼解耦、協作分離、職責分離等)，也能更好的做本地介面模擬開發，提升開發效率。
即使用伺服器端渲染，在技術支持的條件下，可以使用node
中間層(由前端人員開發)，代替傳統的後端模板渲染，這樣可以使後端與前端完全解耦，後端與前端只有數據上的往來。
3、盡量避免大量的線上調試
做好本地介面模擬開發(包括後端模板渲染)，避免大量的線上調試，因為線上調試很不方便，也很費事，並且每次更新代碼，都需要重新構建，然後同步到伺服器。
所以做好本地介面模擬開發，只要程序在本地運行是沒問題的，一般線上就不會有太大的問題，這樣就能大幅降低調試工作量，提升開發效率。
4、本地介面模擬開發
本地介面模擬就是在本地模擬一個與伺服器差不多的環境，能夠提供數據所需的介面，進行錯誤模擬處理等等。
本地介面模擬開發的意義就在於能夠在本地完成幾乎所有的開發與調試，盡量減少線上的調試，提高開發效率。
一些常用庫：
§browser-sync：能讓瀏覽器實時、快速響應文件更改(html、js、css、sass、less
等)並自動刷新頁面，並且可以同時在PC、平板、手機等設備下進行調試。
§webpack-dev-middleware：。
§webpack-hot-middleware：熱更新本地開發瀏覽器服務。
另外，本地介面模擬開發需要後端開發人員有規范的介面文檔。
5、規范的介面文檔
前端與後端協作提升開發效率的一個很重要的方法就是減少溝通：能夠形成紙質的文檔就不要口頭溝通、能夠把介面文檔寫清楚也不要口頭溝通(參數、數據結構、欄位含義等)，特別是線上協作的時候，面對面交流是很困難的。
一個良好的介面文檔應當有以下的幾點要求與信息：
1.格式簡潔清晰：推薦用APIBlueprint
2.分組：當介面很多的時候，分組就很必要了
3.介面名、介面描述、介面地址
4.http方法、參數、headers、是否序列化
5.http狀態碼、響應數據
介面文檔可以用一些文檔服務(如leanote)來管理文檔，也可以用git來管理;書寫方式可以用markdown，也可以YAML、JSON
等。
推薦使用markdown方式寫文檔，用git管理文檔。
6、去緩存
前端需要做好去客戶端緩存的功能，保證用戶始終都是使用的最新資源，不會因為因為緩存的問題而出現bug。
傳統的去緩存是在靜態資源url
上加上版本號或者時間戳，不過因為構建工具的出現以及一些瀏覽器已經不支持這種方式了的緣故，這種方式已經是過去時了。
現在去緩存是將文件hash化命名，只要文件變動，文件名就會不一樣，以此才能徹底的去緩存。如果使用webpack進行打包，會自動將所有文件進行
hash化命名。
7、做好錯誤處理
前端與後端都需要各自做好錯誤處理，以便發生錯誤能夠有友好的提示，也能在用戶反饋時快速准確定位錯誤來源和原因。
一般前端的錯誤分為：
§腳本運行錯誤：js腳本錯誤，找到堆棧信息，然後解決
§介面錯誤：伺服器報錯、數據返回不對、沒有響應數據、超時等
而介面錯誤分為：
§狀態碼錯誤(狀態碼非2XX)：伺服器報錯、超時等
§數據錯誤：沒有響應數據、數據格式不對、數據內容不對
8、運行時捕捉js腳本錯誤
當用戶在用線上的程序時，怎麼知道有沒有出bug;如果出bug了，報的是什麼錯;如果是js報錯，怎麼知道是那一行運行出了錯?
所以，在程序運行時捕捉js腳本錯誤，並上報到伺服器，是非常有必要的。
這里就要用到window.onerror了：
1.window.onerror=(errorMessage,scriptURI,lineNumber,columnNumber,
errorObj)=>{
2.constdata={
3.title:document.getElementsByTagName('title')[0].innerText,
4.errorMessage,
5.scriptURI,
6.lineNumber,
7.columnNumber,
8.detailMessage:(errorObj&&errorObj.message)||'',
9.stack:(errorObj&&errorObj.stack)||'',
10.userAgent:window.navigator.userAgent,
11.locationHref:window.location.href,
12.cookie:window.document.cookie,
13.};
14.
15.post('url',data);//上報到伺服器
16.};
線上的js腳本都是壓縮過的，需要用sourcemap文件與source-map查看原始的報錯堆棧信息。
9、移動端遠程調試、vConsole、TBSStudio
因為移動端的開發無法像pc端開發一樣使用Chrome的開發者調試工具，所以調試移動端需要一些額外的技巧。
移動端應用一般都運行在微信瀏覽器中、webview中、手機瀏覽器中。
遠程調試(RemoteDebugging)
遠程調試就是通過USB連接、埠轉發、搭建代理等方式，將一個設備的web頁面映射到另一個設備上，比如將手機的webview映射到pc
上，達到調試的目的。
移動端web應用調試難題從一開始就有，不過後來瀏覽器廠商基本都推出自己的遠程調試工具來解決這個問題，包括OperaMobile、
iOSSafari、ChromeforAndroid、UC瀏覽器等，另外還有一些第三方開發的遠程調試工具，比如weinre等。
以Android為例，可以將webview、ChromeforAndroid中的頁面映射到pc
端的ChromeDevTools，然後就可以在pc端調試移動端的頁面了。
vConsole
一個輕量、可拓展、針對手機網頁的前端開發者調試面板(chrome開發者工具的便利實現)。
TBSStudio
因為微信瀏覽器是定製的瀏覽器，一般的遠程調試方式都不可用，需要配合特定的工具，如微信開發者工具。
TBSStudio是另一個可以像Chrome一樣調試遠程微信瀏覽器頁面的強大工具。
10、前後端並行開發
正常情況下，前端的開發在完成UI或者組件開發之後，就需要等後端給出介面文檔才能繼續進行，如果能做到前後端並行開發，也能提升開發效率。
前後端並行開發，就是說前端的開發不需要等後端給出介面文檔就可以進行開發，等後端給出介面之後，再對接好後就基本上可以上線了。
在本地化介面模擬的實現下，就可以做到前後端並行開發，只是在代碼層面需要對ajax進行封裝。
11、友好的溝通
不管工具多麼厲害，很多時候都免不了要當面溝通，友好、心平氣和的溝通也是很重要的!
以上就是小編今天為大家分享的關於web前端該如何與後端合作的文章，希望本篇文章能夠對正在從事web前端工作的小夥伴們有所幫助。想要了解更多web前端知識記得關注北大青鳥web培訓官網。最後祝願小夥伴們工作順利！
作者：深予之(@senntyou)
#/a/1190000016852780
㈨ 一個web項目前後端分離，前端工程師需要掌握哪些
首先你要知道什麼是web前端工程師：
Web前端開發工程師，其工作崗位主要職責是利用(X)HTML/CSS/JavaScript/DOM等各種Web技術進行產品的界面開發。製作標准優化的代碼，並增加交互動態功能，同時結合後台開發技術模擬整體效果，進行豐富互聯網的Web開發，致力於通過技術改善用戶體驗，使得web界面可以更加友好的與用戶交互。
Web前端工程師需要的技能：
為網站上提供的產品和服務實現一流的Web界面，優化代碼並保持良好兼容性
Web前端表現層及與前後端交互的架構設計和開發
JavaScript程序模塊開發，通用類庫、框架編寫
利用各種Web技術模擬開發產品原型
配合後台開發人員實現產品界面和功能
Web新技術調研和資訊整理
精通HTML/XHTML、CSS，熟悉頁面架構和布局，精通Ajax、JavaScript、DOM等前端技術，掌握面向對象編程思想