ECMAscript開發(fā)的兩種模式：

1.面向過程: 就是分析出解決問題所需要的步驟，然后用函數(shù)把這些步驟一步一步實現(xiàn)，使用的時候一個一個依次調(diào)用就可以了
2.面向?qū)ο?OOP): 面向?qū)ο笫且怨δ軄韯澐謫栴}，而不是步驟

面向?qū)ο蟮恼Z言有一個標志，那就是類的概念，而通過類可以創(chuàng)建任意多個具有相同屬性的方法的對象。

但是ECMAscript中沒有類的概念！prototype是javascript實現(xiàn)與管理繼承的一種機制，也是面向?qū)ο蟮脑O計思想,可以借助prototype屬性，可以訪問原型內(nèi)部的屬性和方法。

通常使用構(gòu)造函數(shù)，當構(gòu)造函數(shù)被實列化后，所有的實例對象都可以訪問構(gòu)造函數(shù)的原型（prototype）成員，如果在原型中聲明一個成員，所有的實列方法都可以共享它

面向?qū)ο缶幊痰幕舅枷胧鞘褂脤ο螅悾^承，封裝等基本概念來進行程序設計，達到數(shù)據(jù)結(jié)構(gòu)化，簡單抽象的目的（為什么面向?qū)ο螅?/p>

優(yōu)點

易維護

采用面向?qū)ο笏枷朐O計的結(jié)構(gòu)，可讀性高，由于繼承的存在，即使改變需求，那么維護也只是在局部模塊，所以維護起來是非常方便和較低成本的

- 易擴展
開發(fā)工作的重用性、繼承性高，降低重復工作量。
縮短了開發(fā)周期

面向?qū)ο蟮娜筇匦裕豪^承（子類繼承父類，提高復用減少冗余），封裝（數(shù)據(jù)的權(quán)限和保密），多態(tài)（同一接口的不同實現(xiàn)）
面向?qū)ο箅x不開 類 和 實例 兩個概念

響應式網(wǎng)站設計(Responsive Web design)是一個網(wǎng)站能夠兼容多個終端，而不是為每一個終端做一個特定的版本。
基本原理:是通過媒體查詢檢測不同的設備屏幕尺寸做處理。

頁面頭部必須有meta聲明的viewport。

函數(shù)可以作為參數(shù)傳遞

函數(shù)可以作為返回值輸出

是指通過復合純函數(shù)來構(gòu)建軟件的過程，它避免了共享的狀態(tài)、易變的數(shù)據(jù)、以及副作用。函數(shù)式編程是聲明式而不是命令式，并且應用程序狀態(tài)通過純函數(shù)流轉(zhuǎn)。

簡單說，"函數(shù)式編程"是一種"編程范式"（programming paradigm），也就是如何編寫程序的方法論

它具有以下特性：閉包和高階函數(shù)、惰性計算、遞歸、函數(shù)是"第一等公民"、只用"表達式"

進一步了解

盒模型 : margin、padding、border、content

標準盒模型

width = content
對應css屬性 box-sizing:content-box

怪異盒模型

width = content + padding + border
對應css屬性 box-sizing:border-box

關于跨域，有兩個誤區(qū)：

? 動態(tài)請求就會有跨域的問題

? 跨域只存在于瀏覽器端，不存在于安卓/ios/Node.js/python/ java等其它環(huán)境

? 跨域就是請求發(fā)不出去了

? 跨域請求能發(fā)出去，服務端能收到請求并正常返回結(jié)果，只是結(jié)果被瀏覽器攔截了之所以會跨域，是因為受到了同源策略的限制，同源策略要求源相同才能正常進行通信，即協(xié)議、域名、端口號都完全一致。

不能向工作在不同源的的服務請求數(shù)據(jù)（client to server）

但是script標簽能夠加載非同源的資源，不受同源策略的影響。

無法獲取不同源的document/cookie等BOM和DOM，可以說任何有關另外一個源的信息都無法得到 （client to client）

如下圖所示：

只要瀏覽器檢測到響應頭帶上了CORS，并且允許的源包括了本網(wǎng)站，那么就不會攔截請求響應。

CORS把請求分為兩種，一種是簡單請求，另一種是需要觸發(fā)預檢請求，這兩者是相對的，怎樣才算“不簡單”？只要屬于下面的其中一種就不是簡單請求：
（1）使用了除GET/POST/HEAD之外的請求方式，如PUT/DELETE
（2）使用了除Content-Type/Accept等幾個常用的http頭這個時候就認為需要先發(fā)個預檢請求，預檢請求使用OPTIONS方式去檢查當前請求是否安全

代碼里面只發(fā)了一個請求，但在控制臺看到了兩個請求，第一個是OPTIONS，服務端返回：

詳見阮一峰的跨域資源共享CORS詳解

JSONP是利用了script標簽能夠跨域，如下代碼所示：

function updateList (data) {
    console.log(data);
}

$body.append(‘");

代碼先定義一個全局函數(shù)，然后把這個函數(shù)名通過callback參數(shù)添加到script標簽的src，script的src就是需要跨域的請求，然后這個請求返回可執(zhí)行的JS文本：// script響應返回的js內(nèi)容為

updateList([{
    name: "hello"
}]);

由于它是一個js，并且已經(jīng)定義了upldateList函數(shù)，所以能正常執(zhí)行，并且跨域的數(shù)據(jù)通過傳參得到。這就是JSONP的原理。

跨域分為兩種，一種是跨域請求，另一種訪問跨域的頁面，跨域請求可以通過CORS/JSONP等方法進行訪問，跨域的頁面主要通過postMesssage的方式。由于跨域請求不但能發(fā)出去還能帶上cookie，所以要規(guī)避跨站請求偽造攻擊的風險，特別是涉及到錢的那種請求。

本節(jié)參考文章：我知道的跨域與安全

超文本傳輸??協(xié)議（HTTP）是用于傳輸諸如HTML的超媒體文檔的應用層協(xié)議。它被設計用于Web瀏覽器和Web服務器之間的通信，但它也可以用于其他目的。 HTTP遵循經(jīng)典的客戶端-服務端模型，客戶端打開一個連接以發(fā)出請求，然后等待它收到服務器端響應。 HTTP是無狀態(tài)協(xié)議，意味著服務器不會在兩個請求之間保留任何數(shù)據(jù)（狀態(tài)）。

HTTP是明文傳輸?shù)模簿鸵馕吨橛诎l(fā)送端、接收端中間的任意節(jié)點都可以知道你們傳輸?shù)膬?nèi)容是什么。這些節(jié)點可能是路由器、代理等。

舉個最常見的例子，用戶登陸。用戶輸入賬號，密碼，采用HTTP的話，只要在代理服務器上做點手腳就可以拿到你的密碼了。

用戶登陸 --> 代理服務器（做手腳）--> 實際授權(quán)服務器

在發(fā)送端對密碼進行加密？沒用的，雖然別人不知道你原始密碼是多少，但能夠拿到加密后的賬號密碼，照樣能登陸。

HTTP是應用層協(xié)議，位于HTTP協(xié)議之下是傳輸協(xié)議TCP。TCP負責傳輸，HTTP則定義了數(shù)據(jù)如何進行包裝。

HTTPS相對于HTTP有哪些不同呢？其實就是在HTTP跟TCP中間加多了一層加密層TLS/SSL。

通俗的講，TLS、SSL其實是類似的東西，SSL是個加密套件，負責對HTTP的數(shù)據(jù)進行加密。TLS是SSL的升級版。現(xiàn)在提到HTTPS，加密套件基本指的是TLS。

傳輸加密的流程

原先是應用層將數(shù)據(jù)直接給到TCP進行傳輸，現(xiàn)在改成應用層將數(shù)據(jù)給到TLS/SSL，將數(shù)據(jù)加密后，再給到TCP進行傳輸。

對安全或密碼學基礎有了解的同學，應該知道常見的加密手段。一般來說，加密分為對稱加密、非對稱加密（也叫公開密鑰加密）

HTTPS協(xié)議需要到CA申請證書，一般免費證書很少，需要交費。

HTTP協(xié)議運行在TCP之上，所有傳輸?shù)膬?nèi)容都是明文，內(nèi)容可能會被竊聽。HTTPS運行在SSL/TLS之上，SSL/TLS運行在TCP之上，所有傳輸?shù)膬?nèi)容都經(jīng)過加密的。

HTTP和HTTPS使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。

HTTPS可以有效的防止運營商劫持，解決了防劫持的一個大問題。

不驗證通信方的身份，通信方的身份有可能遭遇偽裝。

無法證明報文的完整性，報文有可能遭篡改。

谷歌推行一種協(xié)議(HTTP 之下SSL之上[TCP]),可以算是HTTP2的前身,SPDY可以說是綜合了HTTPS和HTTP兩者優(yōu)點于一體的傳輸協(xié)議，比如

壓縮數(shù)據(jù)(HEADER)

多路復用

優(yōu)先級(可以給請求設置優(yōu)先級)

SPDY構(gòu)成圖：

SPDY位于HTTP之下，TCP和SSL之上，這樣可以輕松兼容老版本的HTTP協(xié)議(將HTTP1.x的內(nèi)容封裝成一種新的frame格式)，同時可以使用已有的SSL功能。

HTTP2.0可以說是SPDY的升級版（其實原本也是基于SPDY設計的），但是，HTTP2.0 跟 SPDY 仍有不同的地方，主要是以下兩點

HTTP2.0 支持明文 HTTP 傳輸，而 SPDY 強制使用 HTTPS

HTTP2.0 消息頭的壓縮算法采用 HPACK，而非 SPDY 采用的 DEFLATE

http2 新特性

新的二進制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本協(xié)議的格式解析存在天然缺陷，文本的表現(xiàn)形式有多樣性，要做到健壯性考慮的場景必然很多，二進制則不同，只認0和1的組合。基于這種考慮HTTP2.0的協(xié)議解析決定采用二進制格式，實現(xiàn)方便且健壯。

多路復用（MultiPlexing），支持單個連接多次請求，即連接共享，即每一個request都是是用作連接共享機制的。一個request對應一個id，這樣一個連接上可以有多個request，每個連接的request可以隨機的混雜在一起，接收方可以根據(jù)request的 id將request再歸屬到各自不同的服務端請求里面。

header壓縮，如上文中所言，對前面提到過HTTP1.x的header帶有大量信息，而且每次都要重復發(fā)送，HTTP2.0使用encoder來減少需要傳輸?shù)膆eader大小，通訊雙方各自cache一份header fields表，既避免了重復header的傳輸，又減小了需要傳輸?shù)拇笮　?/p>

服務端推送（server push），同SPDY一樣，HTTP2.0也具有server push功能。目前，有大多數(shù)網(wǎng)站已經(jīng)啟用HTTP2.0，例如YouTuBe，淘寶網(wǎng)等網(wǎng)站，利用chrome控制臺可以查看是否啟用H2：

chrome=>Network=>Name欄右鍵=>√Protocol

本節(jié)參考文章：簡單比較 http https http2、HTTPS科普掃盲帖

GET在游覽器回退會刷新，而POST會再次提交請求

GET請求會被游覽器主動緩存，而POST不會，除非手動設置

GET請求參數(shù)會被完整的保留在游覽器歷史記錄里，而POST中的參數(shù)不會被保留

GET產(chǎn)生的URL地址可以被收藏，而POST不可以

GET參數(shù)通過URL傳遞，而POST放在Request body

GET請求只能進行URL編碼，而POST支持多種編碼方式

GET請求在URL中傳遞的參數(shù)是有長度限制的，而POST沒有限制

GET請求會把參數(shù)直接暴露在URL上，相比POST更安全

對參數(shù)的數(shù)據(jù)類型，GET只接受ASCII字符，而POST沒有限制

1.請求參數(shù)：get參數(shù)附在URL后面?隔開，POST參數(shù)放在包體中
2.大小限制：GET限制為2048字符，post無限制
3.安全問題：GET參數(shù)暴露在URL中，不如POST安全
4.瀏覽器歷史記錄：GET可以記錄，POST無記錄
5.緩存：GET可被緩存，post無
6.書簽：GET可被收藏為書簽，post不可
7.數(shù)據(jù)類型：GET只能ASCII碼，post無限制

MVC是一種設計模式，它將應用劃分為3個部分：數(shù)據(jù)(模型)、展示層(視圖)和用戶交互層。結(jié)合一下下圖，更能理解三者之間的關系。

換句話說，一個事件的發(fā)生是這樣的過程

用戶和應用交互

控制器的事件處理器被觸發(fā)

控制器從模型中請求數(shù)據(jù)，并將其交給視圖

視圖將數(shù)據(jù)呈現(xiàn)給用戶

MVVM是Model-View-ViewModel的縮寫。mvvm是一種設計思想。Model 層代表數(shù)據(jù)模型，也可以在Model中定義數(shù)據(jù)修改和操作的業(yè)務邏輯；View 代表UI 組件，它負責將數(shù)據(jù)模型轉(zhuǎn)化成UI 展現(xiàn)出來，ViewModel 是一個同步View 和 Model的對象。

在MVVM架構(gòu)下，View 和 Model 之間并沒有直接的聯(lián)系，而是通過ViewModel進行交互，Model 和 ViewModel 之間的交互是雙向的， 因此View 數(shù)據(jù)的變化會同步到Model中，而Model 數(shù)據(jù)的變化也會立即反應到View 上。

ViewModel 通過雙向數(shù)據(jù)綁定把 View 層和 Model 層連接了起來，而View 和 Model 之間的同步工作完全是自動的，無需人為干涉，因此開發(fā)者只需關注業(yè)務邏輯，不需要手動操作DOM, 不需要關注數(shù)據(jù)狀態(tài)的同步問題，復雜的數(shù)據(jù)狀態(tài)維護完全由 MVVM 來統(tǒng)一管理。

在之前的MVC中我們提到一個控制器對應一個視圖，控制器用狀態(tài)機進行管理，如果項目足夠大的時候，狀態(tài)機的代碼量就變得非常臃腫，難以維護。

性能問題，在MVC中我們大量的操作了DOM，而大量操作DOM會讓頁面渲染性能降低，加載速度變慢，影響用戶體驗。

最后就是當Model頻繁變化的時候，開發(fā)者就手動更新View，那么數(shù)據(jù)的維護就變得困難。

為了減小工作量，節(jié)約時間，一個更適合前端開發(fā)的架構(gòu)模式就顯得非常重要，這時候MVVM模式在前端中的應用就應運而生。

mvc和mvvm其實區(qū)別并不大。都是一種設計思想。主要就是mvc中Controller演變成mvvm中的viewModel。mvvm主要解決了mvc中大量的DOM 操作使頁面渲染性能降低，加載速度變慢，影響用戶體驗。和當 Model 頻繁發(fā)生變化，開發(fā)者需要主動更新到View 。

defineProperty（VUE），臟檢查（angular），原生js實現(xiàn)（發(fā)布訂閱者模式）

在Angular中實現(xiàn)數(shù)據(jù)的觀測使用的是臟檢查，就是在用戶進行可能改變ViewModel的操作的時候，對比以前老的ViewModel然后做出改變。

vue.js 則是采用 數(shù)據(jù)劫持 結(jié)合 發(fā)布者-訂閱者模式 的方式，通過Object.defineProperty()來劫持各個屬性的setter，getter，在數(shù)據(jù)變動時發(fā)布消息給訂閱者，觸發(fā)相應的監(jiān)聽回調(diào)。

本節(jié)參考文章：MVC/MVVM

同時支持瀏覽器端和服務端的請求

支持promise

支持請求和和數(shù)據(jù)返回的攔截

轉(zhuǎn)換請求返回數(shù)據(jù)，自動轉(zhuǎn)換JSON數(shù)據(jù)

取消請求

客戶端防止xsrf攻擊

在node端支持設置代理

內(nèi)部一些針對具體項目環(huán)境的二次封裝

本節(jié)參考文章：axios優(yōu)點

1、當要求動態(tài)上下文的時候，就不能夠使用箭頭函數(shù)，箭頭函數(shù)this的固定化

2、在使用=>定義函數(shù)的時候，this的指向是定義時所在的對象，而不是使用時所在的對象

3、不可以當作構(gòu)造函數(shù)，也就是說，不可以使用new命令，否則會拋出一個錯誤

4、不可以使用arguments對象，該對象在函數(shù)體內(nèi)不存在。如果要用，可以用Rest參數(shù)代替

5、不可以使用yield命令，因此箭頭函數(shù)不能用作Generator函數(shù)

class Animal {
    constructor(){
        this.type = "animal"
    }
    says(say) {
        setTimeout(function () {
            console.log(this.type + "says" + say)
        },1000)
    }
}
var animal = new Animal()
animal.says("hi") // undefined says hi

我們再來看看=>的情況

class Animal() {
    constructor() {
        this.type = "animal"
    }
    says(say) {
        setTimeout(() => {
            console.log(this.type + " says " + say)
        }, 1000)
    }
}
var animal = new Animal()
animal.says("hi") // animal says hi

本節(jié)參考文章：前端面試之ES6篇