JS一些概念知識及參考連接

var obj = {a: 123, b: 456}
console.log(Object.prototype.toString.call(obj) === '[object Object]'); console.log(obj.constructor === Object); console.log(obj instanceof Object);

10.二、判斷是否爲數組

var obj = [1,2]
console.log(Array.isArray(obj));        //true
console.log(obj instanceof Array);    //true
console.log(Object.prototype.toString.call(obj) === '[object Array]');    //true
console.log(obj.constructor === Array);   //true
console.log(obj.push != undefined);         //true 有兼容性問題

10.三、判斷是否爲字符串

var str = 'aaa'
console.log(typeof str); console.log(str.constructor); console.log(Object.prototype.toString.call(str)); var str2 = new String(); console.log(str2 instanceof String); //true 只有經過new方式聲明一個字符串時，使用instanceof方法纔是true

十一、原型鏈繼承、構造函數繼承、組合繼承

原型鏈繼承代碼簡單，易實現，可是子類實例修改父類中的引用類型屬性值時，其餘子類實例的該值也將發生改變。由於經過原型對象 prototype 實現繼承，則原型對象中的全部引用類型值都是複用的，即都是同一個值。而且在建立子類實例時，沒法向父類構造函數傳參

構造函數解決了子類實例對引用類型值的誤修改操做問題，可是每一個實例都拷貝一份引用類型值，佔用內存大，尤爲是方法過多的時候。（函數複用又無從談起了，原本咱們用 prototype 就是解決複用問題的）

組合繼承既解決了子類實例對引用類型值的誤修改操做問題，在建立子類實例時也向父類構造函數傳參，又能夠複用一些屬性。在組合繼承中，在父類的原型對象中定義的屬性都是會複用的，而在父類的構造函數裏定義的屬性都不是複用的屬性。或許有人會想到這時會不會跟原型鏈繼承同樣，父類的構造函數中引用類型的值也是複用的，因此也有原型鏈繼承的缺點，但其實不是，構造函數繼承的值至關於子類實例自己的值，而原型鏈繼承的值就是子類實例原型對象的值，在同時擁有時，首先做用的是子類實例自己的值。

ES6中類的繼承能夠看作是組合式繼承的語法糖（簡單理解），但二者的繼承機制仍是不太同樣的。

參考：http://www.javashuo.com/article/p-mkrhcevy-bb.html、http://www.javashuo.com/article/p-bgpmtkrn-be.html、http://www.javashuo.com/article/p-rwkatbxg-gb.html

十二、HTTP和HTTPS

HTTP的弊端：超文本傳輸協議HTTP協議被用於在Web瀏覽器和網站服務器之間傳遞信息。HTTP協議以明文方式發送內容，不提供任何方式的數據加密，若是攻擊者截取了Web瀏覽器和網站服務器之間的傳輸報文，就能夠直接讀懂其中的信息，所以HTTP協議不適合傳輸一些敏感信息，好比信用卡號、密碼等。

HTTPS：爲了解決HTTP協議的這一缺陷，須要使用另外一種協議：安全套接字層超文本傳輸協議HTTPS。爲了數據傳輸的安全，HTTPS在HTTP的基礎上加入了SSL協議，SSL依靠證書來驗證服務器的身份，併爲瀏覽器和服務器之間的通訊加密。可是，加密和解密過程須要耗費系統大量的開銷，嚴重下降傳輸數據的工做效率。

HTTPS的數據傳輸是用對稱加密的，不過要先用非對稱加密來加密傳輸對稱加密的密鑰，而證書的做用就是證實傳輸過來的非對稱的公鑰就是那我的的。

好比說服務器和客戶端是經過對稱加密傳輸數據的，可是要使用對稱加密就二者就必須有一個共同的密鑰，客戶端要想把這個共同的密鑰傳輸給服務器，就必須先對這個密鑰加密。

客戶端傳輸這個密鑰時使用的是非對稱加密（非對稱加密是公鑰加密的數據只能夠經過私鑰解開，私鑰加密的數據有公鑰就能夠解開，公鑰是公開的，誰均可以有它的公鑰），服務器端維護一個私鑰和公鑰，不過先要把公鑰傳輸給客戶端，而後客戶端就可使用公鑰加密數據（即對稱加密算法的密鑰）傳輸給服務器。

不過客戶端怎麼肯定收到的公鑰是來自所須要的服務器的而不是黑客的呢？這就要使用到證書了。公證處CA給服務器頒發私鑰和證書，證書包括該服務器的基本信息 + 公鑰 + 數字簽名。數字簽名的造成：首先將服務器的基本信息和公鑰經過 hash 算法獲得一個 hash 值，而後經過公證處的私鑰來對該 hash 值進行加密就造成了數字簽名。當服務器把它的證書傳輸給客戶端，客戶端就可使用公證處的公鑰來對數字簽名進行解密，獲得一個hash值，而後將證書裏面的基本信息和公鑰經過使用一樣的 hash 算法來進行計算又獲得一個 hash 值，若是兩個 hash 值相同，便可以判斷證書是服務器的證書，公鑰也就是服務器的公鑰，由此就能夠獲得服務器傳輸過來的公鑰了。

就像前面所說的同樣，獲得公鑰之後客戶端就能夠經過該公鑰來對傳輸的數據（即對稱加密算法的密鑰）進行加密，服務器端就可使用私鑰對數據進行解密，獲得將要使用的對稱加密算法的密鑰，而後服務器和客戶端就可使用對稱加密來進行傳輸數據了。

參考：http://www.javashuo.com/article/p-yqyvffkf-eg.html

12.一、HTTPS的缺點

（1）https加劇了服務端的負擔，相比於http其須要更多的資源來支撐，同時也下降了用戶的訪問速度

（2）目前來講大多數網站並不關心數據的安全性和保密性，即https最大的優勢對它來講並不適用

（3）https的技術門檻較高，多數我的或者私人網站難以支撐，CA機構頒發的證書都是須要年費的，此外對接Https協議也須要額外的技術支持

1三、JS中的new關鍵字的工做過程

function Animal(name) {
  this.name = name; } Animal.color = "black"; Animal.prototype.say = function () { console.log("I'm " + this.name); }; var cat = new Animal("cat"); console.log( cat.name, 　　 //cat cat.height 　　 //undefined ); cat.say(); 　　　 //I'm cat  console.log(typeof Animal); console.log( Animal.name, //Animal Animal.color //back ); Animal.say(); //Animal.say is not a function

JS引擎在執行 new 關鍵詞那段代碼時，在內部進行了不少工做，用僞代碼模擬其工做流程以下：

new Animal("cat") = {
    var obj = {}; obj.__proto__ = Animal.prototype; var result = Animal.call(obj,"cat"); return typeof result === 'object'? result : obj; }

參考：https://www.cnblogs.com/AaronNotes/p/6529492.html