摘要：對的請求，也是要有一個了解，比如協(xié)議，請求方式，請求過程，結(jié)果狀態(tài)碼等。教程協(xié)議詳解經(jīng)典面試題一個故事講完響應(yīng)狀態(tài)碼上面提到響應(yīng)狀態(tài)碼，在這里也簡單寫下。

勸了別人無數(shù)次，讓別人喝了雞湯，幫別人填坑，自己卻掉了坑

在前端學(xué)習(xí)里面，很多人都是注重學(xué)習(xí)代碼（html，css，js）。或者是一些框架，庫（jquery，vue，react）,或者是各種工具（webpack，gulp）。在以往的文章里面，或者自己和別人交談，都有建議過別人多練，不要悶頭就寫代碼，多深入了解當(dāng)中的原理，學(xué)習(xí)其中的思想。但是除了代碼方面的知識之外，還有哪一些是作為一個前端，應(yīng)該擴展學(xué)習(xí)的呢？下面簡單羅列和整理了一下最近學(xué)習(xí)的資源。如果大家還有其它的推薦，歡迎在評論區(qū)留言。

下面的知識，可能不需要太過于深入，詳細(xì)的掌握，但是必須要有所了解，這樣在開發(fā)上遇到問題，解決問題的時候即使不是如虎添翼，也是錦上添花。

前端而言，不可避免的要和接口打交道。除了和后臺對接口，請求數(shù)據(jù)，渲染頁面，之外。對http的請求，也是要有一個了解，比如http協(xié)議，請求方式，請求過程，結(jié)果狀態(tài)碼等。了解這些，對開發(fā)的時候可能遇到的問題，就可以大概知道問題是怎么產(chǎn)生的，更快的知道怎么解決，避免。

首先一個請求，包含有請求頭，請求行，請求正文。具體是怎樣境，看下面的代碼

axios({
  method: "post",
  url: "/user/12345",
  headers:{
    "Content-Type":"application/x-www-form-urlencoded"  
  },
  data: {
    firstName: "Fred",
    lastName: "Flintstone"
  }
});

如上所述

method和url就是這個請求的請求行（這里是請求行部分信息，其實請求行還包括http協(xié)議的版本等信息）。headers中的屬性就是請求頭，里面的屬性，全部包含在請求的header里面，是服務(wù)端獲取客戶端版本，緩存等信息的一個途徑。data對應(yīng)的就是請求正文，也就是平常所說的參數(shù)。

在請求發(fā)出去，并且響應(yīng)已經(jīng)回來的時候，就時候信息可分為響應(yīng)行，響應(yīng)頭，響應(yīng)正文。

響應(yīng)行

引用看云的一個請求作為實例，如下代碼就是這個請求的響應(yīng)行，返回請求的http協(xié)議及版本，狀態(tài)碼，請求狀態(tài)等描述信息。

Request URL:https://www.kancloud.cn/yunye/axios/comment?article_id=234845&page=1
Request Method:GET
Status Code:200 OK
Remote Address:117.23.61.221:443

響應(yīng)頭

響應(yīng)頭和請求頭格式一致，返回版本，緩存等信息。

響應(yīng)正文

平常接觸最多的就是響應(yīng)正文，也就是日常開發(fā)需要用到的數(shù)據(jù)。開發(fā)者拿到這些數(shù)據(jù)之后，再進行相應(yīng)的處理。

關(guān)于 https 。下面可以先了解下 http 的缺點，https就是http基礎(chǔ)上做的加密處理。

1.通信使用明文不加密，內(nèi)容可能被竊聽
2.不驗證通信方身份，可能遭到偽裝
3.無法驗證報文完整性，可能被篡改

關(guān)于http與https就簡單說到這里，詳細(xì)的推薦看下下面的資料。

HTTP教程

HTTP協(xié)議【詳解】——經(jīng)典面試題

一個故事講完https

上面提到響應(yīng)狀態(tài)碼，在這里也簡單寫下。在前端方面，請求接口可能會接觸到各種情況，常見的有下面幾個，應(yīng)該怎么解決，就是具體問題，具體分析。

詳細(xì)的狀態(tài)碼請參考下面內(nèi)容。

HTTP狀態(tài)碼

XSS(Cross Site Scripting)是跨站腳本攻擊，為了區(qū)分CSS，所以縮寫為XSS。XSS攻擊方式是往Web頁面插入惡意的 JavaScript 代碼，當(dāng)用戶瀏覽網(wǎng)頁的時候，插入的代碼就是被執(zhí)行，從而達(dá)到攻擊的目的。

其中應(yīng)用比較多的一個就是，在網(wǎng)頁一些公用的交互區(qū)域。比如搜索的文本框，除了可以輸入一些關(guān)鍵字，還可以輸入一些 JavaScript 代碼，一旦代碼點擊搜索，代碼就會被執(zhí)行，達(dá)到攻擊的目的。如下例子

在文本框中輸入以上代碼，然后點擊提交，就會把用戶的cookie彈出來。

XSS防范

1.將重要的cookies標(biāo)記為HTTP ONLY，讓JavaScript代碼無法調(diào)用，只有http能調(diào)用。或者將重要的信息保存在session里面。

2.只允許用戶輸入我們期望的數(shù)據(jù)。如消費金額框只能輸入數(shù)字和小數(shù)點。

3.對數(shù)據(jù)進行加密處理。

4.過濾或者移除特殊的HTML標(biāo)簽，過濾JavaScript代碼等。

CSRF（Cross-site request forgery）是跨站請求偽造。XSS利用站點內(nèi)的信任用戶，與XSS不同，CSRF是通過偽裝來自受信任用戶，在受信任的網(wǎng)站進行請求，盜取信息。其實就是攻擊者盜用了受害者的身份，以受害者的名義向網(wǎng)站發(fā)送惡意請求。

CSRF攻擊的思想

引用CSRF攻擊原理及防御的一張圖進行解釋。

圖片來自：CSRF攻擊原理及防御

根據(jù)步驟，看了圖，相信不難理解，就是在一個網(wǎng)站里面保留了cookie，然后訪問了一些危險網(wǎng)站，然后被危險網(wǎng)站盜用了用戶信息。

CSRF的防御

1.在表單里增加Hash值，以認(rèn)證這確實是用戶發(fā)送的請求，然后在服務(wù)器端進行Hash值驗證。

2.驗證碼：每次的用戶提交都需要用戶在表單中填寫一個圖片上的隨機字符串。

3.修改，增加重要信息，比如密碼，個人信息的操作，盡量使用post。避免使用get把信息暴露在url上面。

和之前的防護XSS和CSRF攻擊目的不一樣，反爬蟲是為了防止網(wǎng)站重要的數(shù)據(jù)被別人拿走，比如電商的交易額，電影網(wǎng)站的票房統(tǒng)計，音樂網(wǎng)站的評論等。

反擊爬蟲，前端工程師的腦洞可以有多大？

1.瀏覽器通過DNS對URL進行解析，找出對應(yīng)的IP地址；

2.向IP地址發(fā)起網(wǎng)絡(luò)請求，進行http協(xié)議會話：客戶端發(fā)送報頭（請求報頭），服務(wù)端回饋報頭（響應(yīng)報頭）

3.服務(wù)器根據(jù)請求，交給后臺處理，處理完成后返回文件數(shù)據(jù)，瀏覽器接收文件數(shù)據(jù)（HTML、JS、CSS、圖象等）；返回一個頁面（根據(jù)頁面上的外鏈的URL重新發(fā)送請求獲取）

4.瀏覽器接收文件完畢，對加載到的資源進行語法解析，以及相應(yīng)的內(nèi)部數(shù)據(jù)結(jié)構(gòu)（網(wǎng)頁渲染）

跨域這方面，平常接觸的不多，我們這邊遇到也是讓后臺允許跨域（跨域資源共享），但是這個跨域，也是一個繞不開的話題，受限于篇幅，下面簡單進行講解。

網(wǎng)上的針對跨域的解決方案有很多，大家參考著看就好。雖然羅列這么多，但是我只用過兩種。

1、 jsonp

2、 document.domain + iframe

3、 location.hash + iframe

4、 window.name + iframe

5、 postMessage

6、 跨域資源共享（CORS）

7、 nginx代理

8、 nodejs中間件代理

9、 WebSocket協(xié)議

前端常見跨域解決方案（全）

前端跨域知識總結(jié)

這里只講個大概，具體操作得靠自己自行問搜索引擎。

按需加載，非首屏圖片使用預(yù)加載或懶加載，DNS，壓縮代碼，合并圖片，減少請求等。

減少沉余的代碼，控制循環(huán)的次數(shù)，避免巨大函數(shù)等。

作為前端開發(fā)者，在SEO方面接觸得應(yīng)該不少。前端方面，注意SEO的點也不少。下面簡單寫下，在我開發(fā)的項目里面，也有幾個項目是需要做SEO的，個人的建議如下幾點：

8-1.meta標(biāo)簽

可定義關(guān)鍵詞、網(wǎng)站描述

< meta name="keywords" content="關(guān)鍵詞1，關(guān)鍵詞2" />

< meta name="description" content="描述詞1，描述詞2" />

8-2.語義化html標(biāo)簽

一方面是，利用html標(biāo)簽，達(dá)到語義化的目的，比如列表使用ul，ol。表格使用table等，不建議什么元素都使用div。

另一方面是盡可能使用html5提供的具有語義化的標(biāo)簽。

以前寫法

建議寫法

8-3.html嵌套級別不宜過多

這一點就是盡量使html做到扁平化，避免嵌套過多，但是這點相對而言，難度比較大。

8-4.img標(biāo)簽四大屬性不能省

alt屬性是為了讓圖片因網(wǎng)速慢、src引用錯誤、瀏覽器禁用圖像、用戶使用屏幕閱讀器等情況，未成功顯示時候，仍可以顯示文本，讓用戶可大概知道這張圖片大概是什么。

width和height是為了防止因為圖片無法顯示，造成頁面重新渲染，或者布局錯亂。

8-5.h1-h6標(biāo)簽的使用

1.一個頁面建議只出現(xiàn)一個h1標(biāo)簽，而且一般是放在網(wǎng)頁log上面使用。

2.h2標(biāo)簽一般用于詳情頁的主標(biāo)題。詳情頁沒有l(wèi)ogo，標(biāo)題使用h1。如有副標(biāo)題，使用h3。

3.h1-h6標(biāo)簽自帶權(quán)重，如果只為了設(shè)置字體大小，或者區(qū)分樣式，不適合使用h1-h6。

8-6.其它方面

關(guān)于SEO的其他方式，在網(wǎng)上看到有這樣的方法，但是我自己在開發(fā)上面沒嘗試過這樣做，這里就簡單羅列下，大家參考下。

避免 iframe 標(biāo)簽

重要內(nèi)容謹(jǐn)慎使用 display:none;

a標(biāo)簽盡量添加title屬性

利用布局，把重要內(nèi)容HTML代碼放在最前

使用”rel=nofollow”屬性，集中網(wǎng)站權(quán)重

最近一段時間很流行前后分離，以及單頁應(yīng)用。但關(guān)于前后分離和單頁應(yīng)用這個怎么做SEO現(xiàn)在不清楚（目前我了解的是沒法做）。我們現(xiàn)在的做法就是需要做SEO的項目，前端只負(fù)責(zé)切圖，然后后臺鋪數(shù)據(jù)，服務(wù)端渲染，不是前端渲染。

棧(stack)會自動分配內(nèi)存空間，會自動釋放。堆(heap)動態(tài)分配的內(nèi)存，大小不定也不會自動釋放。

基本類型：Undefined、Null、Boolean、Number 和 String，這5中基本數(shù)據(jù)類型可以直接訪問，他們是按照值進行分配的，存放在棧(stack)內(nèi)存中的簡單數(shù)據(jù)段，數(shù)據(jù)大小確定，內(nèi)存空間大小可以分配。

如下例子

let a=1;
let b=a;

如果修改了b

b=2;

雖然b一開始是通過a賦值，但是a和b是獨立的儲存在棧內(nèi)存里面，修改其中一個，不會對另一個有任何影響。

引用類型：即存放在堆(heap)內(nèi)存中的對象，變量實際保存的是一個指針，這個指針指向另一個位置。

如下例子

let a={name:"守候"};
let b=a;

如果修改了b

b.name="sh";

b通過a賦值，a和b就共用了一個堆內(nèi)存，修改了a或者b，都直接修改了堆內(nèi)存的值，就會對另一個產(chǎn)生影響。

關(guān)于這兩個的概念，現(xiàn)在沒怎么聽說了。可能是因為現(xiàn)在主流的就是PC和手機是分開兩個項目的原因，也可能是因為這兩個概念更應(yīng)該是設(shè)計圖的工作。上一次和別人談?wù)撨@個問題，還是在一年前，那個時候我還是切圖仔。

但是關(guān)于這兩個概念的區(qū)別，大家知道一下就好，下面看兩張圖片估計就差不多懂了。

圖片來自：響應(yīng)式和自適應(yīng)有什么區(qū)別?（這篇文章估計也是抄襲的，但是由于圖片我也找不到出處了，就聲明這個了）

簡單來說：

自適應(yīng)：一個網(wǎng)頁，根據(jù)屏幕寬度的改變而改變。代碼只有一套。在個別的屏幕上，排版這個比較丑，但是設(shè)計，開發(fā)成本低。

響應(yīng)式：一個網(wǎng)頁，根據(jù)屏幕的寬度的改變而展示不同的效果，代碼基本是兩套以上。在所有屏幕上都展示很好的效果，但是設(shè)計，開發(fā)成本高。

自適應(yīng)實例：攜程

響應(yīng)式實例：segmentfault

之所以要發(fā)這么一片，總結(jié)這一些概念，是因為我和別人交談的時候，遇到這些總是有一個是是而非的概念。所以最近就抽空看了下這些概念，也和大家分享下這一些知識。這些概念知識，可能只是了解一下，大概知道就好，有些可能要深入了解下，這個就看個人所需了。最后，如果大家還有什么要推薦的概念知識是比較重要，需要了解的，歡迎在評論區(qū)留言。

-------------------------華麗的分割線--------------------

想了解更多，關(guān)注關(guān)注我的微信公眾號：守候書閣