全棧開發經驗

1、請列舉網站開發的多種模式

WebFrom、MVC、前后端分離（后端 Restful API，前端使用前端框架，例如Angular、React、Vue）。

2、列舉前后端分離和非前后端分離的區別以及各自的優勢

1、前后端不分離 

在前后端不分離的開發模式中，前端頁面看到的效果都是由后端控制，由后端渲染頁面或重定向，也就是后端需要控制前端的展示，前端與后端的耦合度很高。

這種開發模式比較適合純網頁應用，但是當后端對接App時，App可能並不需要后端返回一個HTML網頁，而僅僅是數據本身，所以后端原本返回網頁的接口不在適用於前端App應用，為了對接App，后端還需要在開發一套接口。

2、前后端分離

術業有專攻，前端做前端的，后端做后端的。

服務器一分為二，前后端分別部署，靜態資源放在前端服務器，業務代碼放在后端服務器。前端服務器需要接收HTTP請求。前端服務器需要進行視圖解析（可以使用Vue.js、Angular）。前端服務器需要處理路由（也就是頁面之間的跳轉）。后端服務器只負責返回數據給前端。

3、談談為什么現在大部分企業都選擇前后端分離模式開發項目

其實這還是由前后端分離后的優勢決定的：術業有專攻，前端做前端的，后端做后端的。服務器一分為二，前后端分別部署，靜態資源放在前端服務器，業務代碼放在后端服務器。前端服務器需要接收HTTP請求。前端服務器需要進行視圖解析（可以使用Vue.js、Angular）。前端服務器需要處理路由（也就是頁面之間的跳轉）。后端服務器只負責返回數據給前端。

4、請列舉前后端分離項目中為什么會出現跨域問題

因為同源策略。跨域問題來源於JavaScript的同源策略，即只有協議+主機名+端口號（如存在）相同，則允許相互訪問。也就是說，JavaScript只能訪問和操作自己域下的資源，不能訪問和操作其它與下面的資源。跨域問題是針對JS和Ajax的，HTML本身沒有跨域問題，比如a標簽，script標簽，甚至form標簽（可以直接跨域發送數據並接收數據）等。

5、請列舉跨域問題的多種解決方案。以及各自的特點

第一種：服務器執行請求過來以后，允許你跨域；其實服務器設置響應頭：response.setHeader("Access-Control-Allow-Origin", "*")。

第二種：jsonp的方式。注意：這種方式只能發送get請求。就算指定為post，最后發送的還是get，且跟上面方式一樣，也需要服務器的配合支持。jsonp發送的並不是ajax請求；利用動態創建一個script標簽，因為script標簽是沒有同源策略限制的，是可以跨域的； 把這個script標簽的src指向我們請求的服務端地址，這個地址會攜帶一個參數：callback ,一個回調函數，服務端會把數據通過這個回調函數返回給客戶端，但是客戶端沒有這個函數怎么接收呢？所以在發送請求之前，要在全局（window）注冊這樣一個方法，利用這個方法，來獲得數據； 這個回調函數名需要跟服務端約定好，是一致的。例如：

<script>
         //指定的回調函數
         function showData (result) {
             var data = JSON.stringify(result); //json對象轉成字符串
             $("#text").val(data);
         }
 
         $(document).ready(function () {
 
             $("#btn").click(function () {
                 //向頭部輸入一個腳本，該腳本發起一個跨域請求
                 $("head").append("<script src='http://localhost:9090/student?callback=showData'><\/script>");
             });
 
         });
</script>

第三種：代理服務器，跨域問題是瀏覽器的同源策略限制，服務器之間是沒有的，那我們先把請求給我們的代理服務器，再讓我們的代理服務器去調用這個接口，在發送給前端就可以了。

第四種：在后端代碼里面設置。比如ASP.NET Web API或者ASP.NET Core Web API里面都可以設置。

6、請列舉前后端分離項目中，有哪些權限驗證方法，就你了解的方式中選擇兩種加以介紹

現在常用的是請求加上用戶名和密碼實時驗證、Token驗證；

用戶名和密碼實時驗證：client發生username和password到server。server驗證成功以后。寫cookie到client，然后返回OK的JSON，其中cookie的key要存儲在Redis中，value就是用戶信息。並且要設置key的超時時間，例如10分鍾。client收到ok后, 進行相應的業務操作, 以后每次請求server都會自動帶上cookie, 不用你寫代碼；server端的filter(你肯定用filter來實現)中會每次驗證傳過來的cookie的key在redis中是否存在, 有就代表登錄成功過可以操作, 沒有就返回錯誤標識。

注意: 在登錄成功后, 每次調用服務器接口時候, 都要為redis的key進行續期,如60分鍾。

當redis的key超過60分鍾, 自己會刪除這個key, 那么再次請求server時, 就會收到需要登錄的返回值。當用戶主動退出系統的時候, 也要在server中刪除redis的key。

Token方式。

token一般用來做顯示的身份驗證, 比如手機驗證碼之類的, 這些都需要手動傳遞token到后台。在client點擊驗證碼，server發送驗證碼,返回給client一個token，在client對驗證碼進行驗證,傳遞token + 驗證碼到server，

server對token+驗證碼進行驗證。

7、在前后端分離項目中，請求方式一般為ajax 請求，請解讀ajax 請求的特點

Ajax優勢：

1. 最大的一點是頁面無刷新，在頁面內與服務器通信，給用戶的體驗非常好。

2. 使用異步方式與服務器通信，不需要打斷用戶的操作，具有更加迅速的響應能力。

3. 可以把以前一些服務器負擔的工作轉嫁到客戶端，利用客戶端閑置的能力來處理，減輕服務器和帶寬的負擔，節約空間和寬帶租用成本。並且減輕服務器的負擔，ajax的原則是“按需取數據”，可以最大程度的減少冗余請求，和響應對服務器造成的負擔。

4. 基於標准化的並被廣泛支持的技術，不需要下載插件或者小程序。

Ajax局限：

1. ajax干掉了back按鈕，即對瀏覽器后退機制的破壞。后退按鈕是一個標准的web站點的重要功能，但是它沒法和js進行很好的合作。這是ajax所帶來的一個比較嚴重的問題，因為用戶往往是希望能夠通過后退來取消前一次操作的。那么對於這個問題有沒有辦法？答案是肯定的，用過Gmail的知道，Gmail下面采用的ajax技術解決了這個問題，在Gmail下面是可以后退的，但是，它也並不能改變ajax的機制，它只是采用的一個比較笨但是有效的辦法，即用戶單擊后退按鈕訪問歷史記錄時，通過創建或使用一個隱藏的IFRAME來重現頁面上的變更。（例如，當用戶在Google Maps中單擊后退時，它在一個隱藏的IFRAME中進行搜索，然后將搜索結果反映到Ajax元素上，以便將應用程序狀態恢復到當時的狀態。）。但是，雖然說這個問題是可以解決的，但是它所帶來的開發成本是非常高的，和ajax框架所要求的快速開發是相背離的。這是ajax所帶來的一個非常嚴重的問題。

2. 安全問題。技術同時也對IT企業帶來了新的安全威脅，ajax技術就如同對企業數據建立了一個直接通道。這使得開發者在不經意間會暴露比以前更多的數據和服務器邏輯。ajax的邏輯可以對客戶端的安全掃描技術隱藏起來，允許黑客從遠端服務器上建立新的攻擊。還有ajax也難以避免一些已知的安全弱點，諸如跨站點腳步攻擊、SQL注入攻擊和基於credentials的安全漏洞等。

3. 對搜索引擎的支持比較弱。

4. 破壞了程序的異常機制。至少從目前看來，像ajax.dll，ajaxpro.dll這些ajax框架是會破壞程序的異常機制的。關於這個問題，我曾經在開發過程中遇到過，但是查了一下網上幾乎沒有相關的介紹。后來我自己做了一次試驗，分別采用ajax和傳統的form提交的模式來刪除一條數據……給我們的調試帶來了很大的困難。

5. 另外，像其他方面的一些問題，比如說違背了url和資源定位的初衷。例如，我給你一個url地址，如果采用了ajax技術，也許你在該url地址下面看到的和我在這個url地址下看到的內容是不同的。這個和資源定位的初衷是相背離的。

6. 一些手持設備（如手機、PDA等）現在還不能很好的支持ajax，比如說我們在手機的瀏覽器上打開采用ajax技術的網站時，它目前是不支持的，當然，這個問題和我們沒太多關系。

8、淺談Ajax和axios的區別

區別：axios是通過promise實現對ajax技術的一種封裝，就像jQuery實現ajax封裝一樣。簡單來說： ajax技術實現了網頁的局部數據刷新，axios實現了對ajax的封裝。axios是ajax ajax不止axios。

Ajax：本身是針對MVC的編程,不符合現在前端MVVM的浪潮。基於原生的XHR開發，XHR本身的架構不清晰，已經有了fetch的替代方案。JQuery整個項目太大，單純使用ajax卻要引入整個JQuery非常的不合理（采取個性化打包的方案又不能享受CDN服務）。

axios：從 node.js 創建 http 請求。支持 Promise API。客戶端支持防止CSRF。提供了一些並發請求的接口（重要，方便了很多的操作）。

9、如果一個前后端分離項目在運行的時候發生異常，請談談你的排錯步驟

建議在開發的時候使用谷歌瀏覽器，調試測試方便！可以直接查看瀏覽器network，確定是某一個接口報錯！根據報錯的狀態碼；查看異常事件，如果接口方有日志、直接查看日志；選擇性調整；

10、列舉你了解到的調試請求接口的工具

1. webService接口：是走soap協議通過http傳輸，請求報文和返回報文都是xml格式的，我們在測試的時候都用通過工具才能進行調用，測試。可以使用的工具有SoapUI、jmeter、loadrunner等；
2. http api接口：是走http協議，通過路徑來區分調用的方法，請求報文都是key-value形式的，返回報文一般都是json串，有get和post等方法，這也是最常用的兩種請求方式。可以使用的工具有postman、RESTClient、jmeter、loadrunner等；

11、一個前后端項目如果在運行的時候,某一個功能在使用的時候，很卡頓，讓你定位問題，你會如何做？

可以直接通過瀏覽器Network查看到是那個接口在請求的時候耗時間，然后有針對性的優化接口；

12、請談談Vue和Jquery的區別

vue和jquey對比 jQuery是使用選擇器（）選取DOM對象，對其進行賦值、取值、事件綁定等操作，其實和原生的HTML的區別只在於可以更方便的選取和操作DOM對象，而數據和界面是在一起的。比如需要獲取label標簽的內容：(“lable”).val();,它還是依賴DOM元素的值。 Vue則是通過Vue對象將數據和View完全分離開來了。對數據進行操作不再需要引用相應的DOM對象，可以說數據和View是分離的，他們通過Vue對象這個vm實現相互的綁定。這就是傳說中的MVVM。

13、談談對Post 請求和Get 請求的理解；二者如何選取應用！

GET傳遞的參數只能帶URL后面，文本格式QueryString，各瀏覽器一般有長度限制，一般認為是2083，如果有中文字符更短。提交到服務器端的數據量小。

POST可以傳遞application/x-www-form-urlencoded的類似QueryString、multipart/form-data的二進制報文格式（支持文件信息嵌入報文傳輸）、純文本或二進制的body參數。提交到服務器端的數據量大。

14、談談WebApi/WebService/WCF三者的特點。

Web Service：

1. 它是基於SOAP協議的，數據格式是XML　　
2. 只支持HTTP協議　　
3. 它不是開源的，但可以被任意一個了解XML的人使用　　
4. 它只能部署在IIS上　

WCF　　

1. 這個也是基於SOAP的，數據格式是XML　　
2. 這個是Web Service（ASMX）的進化版，可以支持各種各樣的協議，像TCP，HTTP，HTTPS，Named Pipes, MSMQ.　　
3. WCF的主要問題是，它配置起來特別的繁瑣　　
4. 它不是開源的，但可以被任意一個了解XML的人使用　　
5. 它可以部署應用程序中或者IIS上或者Windows服務中　

Web API：　

1. 這是一個簡單的構建HTTP服務的新框架　　
2. 在.net平台上Web API 是一個開源的、理想的、構建REST-ful 服務的技術　　
3. 不像WCF REST Service.它可以使用HTTP的全部特點（比如URIs、request/response頭，緩存，版本控制，多種內容格式）　　
4. 它也支持MVC的特征，像路由、控制器、action、filter、模型綁定、控制反轉（IOC）或依賴注入（DI），單元測試。這些可以使程序更簡單、更健壯　　
5. 它可以部署在應用程序和IIS上　　
6. 這是一個輕量級的框架，並且對限制帶寬的設備，比如智能手機等支持的很好　　
7. Response可以被Web API的MediaTypeFormatter轉換成Json、XML 或者任何你想轉換的格式。

15、前后端項目中，在請求服務器時候，發現請求的數據量比較大，如何優化？

可以選擇數據壓縮；常見的數據壓縮像gzip;