最近面試總能遇到有面試官問到let,const和var的區別,箭頭函數與普通函數的區別等等等等,各類區別,我也能答出一二,但恨不能答到完整,答全要點,並且結巴,因此這裏我就對此進行一些總結(翻看各類資料,只能算偏完整,缺失的還要靠你們評論補充,我再修改)。javascript
a. 箭頭函數和普通函數的樣式不一樣,箭頭函數語法更加簡潔、清晰,箭頭函數是=>
定義函數,普通函數是function
定義函數。
css
b. 箭頭函數會捕獲其所在上下文的 this 值,做爲本身的 this 值,定義的時候就肯定並固定了。
html
c. 箭頭函數不能做爲構造函數使用,也不能使用new關鍵字(由於箭頭函數沒有本身的this,它的this實際上是繼承了外層執行環境中的this,且this指向永遠不會改變,做爲構造函數其的this要是指向建立的新對象
)。
前端
d. 箭頭函數沒有本身的arguments。在箭頭函數中訪問arguments實際上得到的是外層局部(函數)執行環境中的值。
vue
e. call、apply、bind 並不會影響其 this 的指向。
java
f. 箭頭函數沒有原型prototype。
node
g. 箭頭函數不能看成 Generator 函數,不能使用 yield 關鍵字。
react
從如下三個方面
說。
webpack
變量提高方面:var聲明的變量存在變量提高,即變量能夠在聲明以前調用,值爲undefined。
let和const不存在變量提高問題(注意這個‘問題’後綴,實際上是有提高的,只不過是let和const具備一個暫時性死區的概念,即沒有到其賦值時,以前就不能用
),即它們所聲明的變量必定要在聲明後使用,不然報錯。
ios
塊級做用域方面:var不存在塊級做用域,let和const存在塊級做用域
聲明方面:var容許重複聲明變量,let和const在同一做用域不容許重複聲明變量。其中const聲明一個只讀的常量(由於如此,其聲明時就必定要賦值,否則報錯)。一旦聲明,常量的值就不能改變。
如何使const聲明的對象內屬性不可變,只可讀呢?
若是const聲明瞭一個對象,對象裏的屬性是能夠改變的。
const obj={name:'蟹黃'};
obj.name='同窗';
console.log(obj.name);//同窗
複製代碼
由於const聲明的obj只是保存着其對象的引用地址,只要地址不變,就不會出錯。
使用Object.freeze(obj)
凍結obj,就能使其內的屬性不可變,但它有侷限,就是obj對象中要是有屬性是對象,該對象內屬性還能改變,要全不可變,就須要使用遞歸等方式一層一層所有凍結。
Number類型的數字有精度限制,數值的精度只能到 53 個二進制位(至關於 16 個十進制位, 正負9007199254740992
),大於這個範圍的整數,就沒法精確表示了。
Bigint沒有位數的限制,任何位數的整數均可以精確表示。可是其只能用於表示整數,且爲了與Number進行區分,BigInt 類型的數據必須添加後綴n。BigInt 可使用負號(-),可是不能使用正號(+)。
另外number類型的數字和Bigint類型的數字不能混合計算。
12n+12;//報錯
基本數據類型:
a. 基本數據類型的值是不可變的(從新賦值屬於改變屬性名的指向了,而不是對值進行操做),這裏你就能夠聯想到,是否是全部關於字符串和數字的方法
都是帶有返回值
的,而不是改變原字符串或數字。
例如
let a='abc';
a.split('');
console.log(a);//abc
複製代碼
b. 基本數據類型不能夠添加屬性和方法,雖然不會報錯,但也只是一瞬間轉爲了相應包裝對象,操做完又轉化回原基本數據類型,不會保存結果。
c. 基本數據類型的賦值是簡單賦值,基本數據類型的比較是值的比較。
d. 基本數據類型是存放在棧區的
引用數據類型:
a. 引用類型的值是能夠改變的,例如對象就能夠經過修改對象屬性值更改對象。
b. 引用類型能夠添加屬性和方法。
c. 引用類型的賦值是對象引用,即聲明的變量標識符,存儲的只是對象的指針地址。
d. 引用類型的比較是引用(指針地址
)的比較。
e. 引用類型是同時保存在棧區和堆區中的,棧區保存變量標識符和指向堆內存的地址。
你們應該都知道在script標籤內有這兩個屬性async和defer,例如<script src="./home.js" async defer></script>
defer:中文意思是延遲。用途是表示腳本會被延遲到整個頁面都解析完畢後再運行。所以,在<script>
元素中設置defer屬性,至關於告訴瀏覽器當即下載,但延遲執行。
HTML5規範要求腳本按照它們出現的前後順序執行
,所以第一個延遲腳本會先於第二個延遲腳本執行,但執行腳本之間存在依賴,須要有執行的前後順序時
,就可使用defer
,延遲執行。我以爲把script腳本放在body底部和defer差很少。
async:中文意思是異步,這個屬性與defer相似,都用於改變處理腳本的行爲。一樣與defer相似,async只適用於外部腳本文件,並告訴瀏覽器當即下載文件。但與defer不一樣的是,標記爲async的腳本並不保證按照它們的前後順序執行。
指定async屬性的目的是不讓頁面等待兩個腳本下載和執行,從而異步加載頁面
其餘內容,這使用於之間互不依賴
的各腳本。
當網頁交給瀏覽器的HTML解析器轉變成一系列的詞語(Token)。解釋器根據詞語構建節點(Node),造成DOM樹。由於JavaScript代碼可能會修改DOM樹的結構,因此節點是JavaScript代碼的話,就須要中止當前DOM樹的建立,直到JavaScript的資源加載並被JavaScript引擎執行後才繼續DOM樹的建立。
這裏就會產生阻塞,出現白屏問題(白屏問題優化有不少方面,這裏就腳本阻塞這一小點),咱們就可使用async和defer
屬性來解決JavaScript腳本阻塞問題。
固然最穩妥的辦法仍是把script標籤放置在body的底部,沒有兼容性問題,不會所以產生白屏問題,沒有執行順序問題。
async/await優勢:
a. 它作到了真正的串行的同步寫法,代碼閱讀相對容易
b. 對於條件語句和其餘流程語句比較友好,能夠直接寫到判斷條件裏面
function a() {
return new Promise((resolve, reject) => {
setTimeout(() => {
resolve(222)
}, 2222)
})
};
async function f() {
try {
if ( await a() === 222) {
console.log('yes, it is!') // 會打印
}
} catch (err) {
// ...
}
}
複製代碼
c. 處理複雜流程時,在代碼清晰度方面有優點
async/await缺點:
a. 沒法處理promise返回的reject對象,要藉助try...catch...
b. 用 await 可能會致使性能問題,由於 await 會阻塞代碼,也許以後的異步代碼並不依賴於前者,但仍然須要等待前者完成,致使代碼失去了併發性。
//promise
Promise.all([ajax1(), ajax2()])
複製代碼
c. try...catch...內部的變量沒法傳遞給下一個try...catch...,Promise和then/catch內部定義的變量,能經過then鏈條的參數傳遞到下一個then/catch,可是async/await的try內部的變量,若是用let和const定義則沒法傳遞到下一個try...catch...,只能在外層做用域先定義好。
但async/await確確實實是解決了promise一些問題的。更加靈活的處理異步
promise的一些問題:
a. 一旦執行,沒法中途取消,鏈式調用多個then中間不能隨便跳出來
b. 錯誤沒法在外部被捕捉到,只能在內部進行預判處理,若是不設置回調函數,Promise內部拋出的錯誤,不會反應到外部
c. Promise內部如何執行,監測起來很難,當處於pending狀態時,沒法得知目前進展到哪個階段(剛剛開始仍是即將完成)
a. GET 是將參數寫在 URL 中 ?
的後面,並用 &
分隔不一樣參數;而 POST 是將信息存放在 Message Body
中傳送,參數‘不會’顯示在 URL 中(Restful規範中是這樣,但post在有須要時能夠把參數放URL裏)。GET方式須要使用Request.QueryString來取得變量的值,而POST方式經過Request.Form來獲取變量的值。 也就是說Get是經過地址欄來傳值,而Post是經過提交表單來傳值。
b. GET請求提交的數據有長度限制(HTTP 協議自己沒有限制 URL 及正文長度,對 URL 的限制大可能是瀏覽器和服務器的緣由),POST請求沒有內容長度限制。
c. GET請求返回的內容會被瀏覽器緩存起來。而每次提交POST請求,瀏覽器不會緩存POST請求返回的內容。
d. GET對數據進行查詢,POST主要對數據進行增刪改!簡單說,GET是隻讀,POST是寫。
e. 關於安全性,GET 請求方式從瀏覽器的 URL 地址就能夠看到參數;因此post更安全,其實不管是 GET 仍是 POST 其實都是不安全的,由於 HTTP 協議是明文傳輸,只要攔截封包便能輕易獲取重要資訊。想要安全傳輸資料,必須使用 SSL/TLS來加密封包,也就是 HTTPS。
那爲何推崇使用post來處理敏感數據呢?
由於get的記錄會保存在瀏覽器,上網日誌中,而使用Post,由於數據不會記錄存儲在瀏覽器的記錄和網址訪問記錄中,這樣會有更大的安全性。
f.一個誤區 說GET產生一個TCP數據包;POST產生兩個TCP數據包
其說法:對於GET方式的請求,瀏覽器會把http header和data一併發送出去,服務端響應200,請求成功。
對於POST方式的請求,瀏覽器會先發送http header給服務端,告訴服務端等一下會有數據過來,服務端響應100 continue,告訴瀏覽器我已經準備接收數據,瀏覽器再post發送一個data給服務端,服務端響應200,請求成功。
爲其正名:上面所說的post會比get多一個tcp包其實不太嚴謹。多發的那個expect 100 continue header報文,是由客戶端對http的post和get的請求策略決定
的,目的是爲了不浪費資源,如帶寬,數據傳輸消耗的時間等等。因此客戶端會在發送header的時候添加expect 100去探探路,若是失敗了就不用繼續發送data,從而減小了資源的浪費。因此是否再發送一個包取決了客戶端的實現策略,和get/post並沒什麼關係。有的客戶端好比fireFox就只發送一個包。
首先說說用框架和不用框架的區別:(以使用框架的角度看)
框架好處:
a. 使用框架工具寫項目,在瀏覽器中代碼依然是原生的HTML CSS JS。而框架幫開發者作了不少事情,開發者只關注業務邏輯就能夠,極大的加快了開發速度。
例如前端框架根本上是解決了UI 與狀態同步問題
,頻繁操做 DOM 性能低下
.中間步驟過多,易產生 bug且不易維護
,並且心智要求較高不利於開發效率
的一系列阻礙
b. 組件化
: 其中以 React 的組件化最爲完全,甚至能夠到函數級別的原子組件,高度的組件化能夠是咱們的工程易於維護、易於組合拓展。
c. 自然分層
: JQuery 時代的代碼大部分狀況下是麪條代碼,耦合嚴重,現代框架無論是 MVC、MVP仍是MVVM 模式都能幫助咱們進行分層,代碼解耦更易於讀寫。
d. 生態
: 如今主流前端框架都自帶生態,無論是數據流管理架構仍是 UI 庫都有成熟的解決方案
e. 待補充。。。(但願評論區能提出寶貴看法)
框架缺點:
a. 代碼臃腫,使用者使用框架的時候會將整個框架引入,而框架封裝了不少功能和組件,使用者必須按照它的規則使用,而實際開發中不少功能和組件是用不到的。
b. 框架迭代更新速度很是快,須要時間熟悉它。
c. 待補充。。。(但願評論區能提出寶貴看法)
說說Vue和React的區別:
這裏就說說其思想差別(畢竟面試時不必定就要把兩個框架差別說清楚,理解核心就好):
react總體是函數式的思想
,把組件設計成純組件,狀態和邏輯經過參數傳入,因此在react中,是單向數據流;
vue的思想是響應式的
,也就是基因而數據可變的,經過對每個屬性創建Watcher來監聽,當屬性變化的時候,響應式的更新對應的虛擬dom。
其餘的細節差別能夠看看這篇文章:關於Vue和React的一些對比
a. 存儲位置不一樣:
cookie的數據信息存放在客戶端瀏覽器上,session的數據信息存放在服務器上。
b. 存儲容量不一樣:
單個cookie保存的數據<=4KB,一個站點最多保存20個Cookie,而對於session來講並無上限,但出於對服務器端的性能考慮,session內不要存放過多的東西,而且設置session刪除機制。
c. 存儲方式不一樣:
cookie中只能保管ASCII字符串,並須要經過編碼方式存儲爲Unicode字符或者二進制數據。session中可以存儲任何類型的數據,包括且不限於string,integer,list,map等。
d. 隱私策略不一樣:
cookie對客戶端是可見的,別有用心的人能夠分析存放在本地的cookie並進行cookie欺騙,因此它是不安全的,而session存儲在服務器上,對客戶端是透明的,不存在敏感信息泄漏的風險。
e. 有效期上不一樣:
開發能夠經過設置cookie的屬性,達到使cookie長期有效的效果。session依賴於名爲JSESSIONID的cookie,而cookie JSESSIONID的過時時間默認爲-1,只需關閉窗口該session就會失效,於是session不能達到長期有效的效果。
f. 服務器壓力不一樣:
cookie保管在客戶端,不佔用服務器資源。對於併發用戶十分多的網站,cookie是很好的選擇。session是保管在服務器端的,每一個用戶都會產生一個session。假如併發訪問的用戶十分多,會產生十分多的session,耗費大量的內存。
g. 跨域支持上不一樣:
cookie支持跨域名訪問(二級域名是能夠共享cookie的)。session不支持跨域名訪問。
微任務和宏任務皆爲異步任務,它們都屬於一個隊列,主要區別在於他們的執行順序,Event Loop的走向和取值。
宏任務和微任務的一些分配
宏任務 瀏覽器 Node
I/O ✅ ✅
setTimeout ✅ ✅
setInterval ✅ ✅
setImmediate ❌ ✅
requestAnimationFrame ✅ ✅
微任務
process.nextTick ❌ ✅
MutationObserver ✅ ❌
Promise.then catch finally ✅ ✅
複製代碼
宏任務與微任務之間的執行順序(同步任務->微任務->宏任務)
下面說說執行到宏任務後是怎麼繼續運行的
(這裏聲明下,整段js代碼就是第一個大的宏任務,事件循環是由這第一個宏任務開始的,而後分出微任務,這裏是爲了理解微任務宏任務的執行區別就先跳過這第一層)
說一個頗有名的銀行例子
:銀行櫃檯前排着一條隊伍,都是存錢的人,存錢屬於宏任務,這條隊伍就是宏任務隊列,當一個‘宏大爺’被叫到了本身的號碼,就上前去--被處理,處理存錢業務時,‘宏大爺’忽然想給本身的存款辦個微理財(微任務
),那麼銀行職員就將他的需求添加到本身的微任務隊列,大爺就不用再排隊了,直接在存錢宏任務進行完後就處理衍生出來的微任務理財,辦理財時大爺又說辦個信用卡,那就又排到微任務隊列裏。但要是在這次存錢時‘宏大爺’說他還要存錢,且是他老伴要存錢,也是宏任務
,但很差意思,須要取號到宏任務隊列的後面排隊(這裏就是在宏任務進行時產生微任務和宏任務的處理方式)。
結合下面的題目理解理解(這裏先不介紹node環境的事件循環的特殊地方,主要以瀏覽器環境,最好看看底下推薦的文章):
<script> setTimeout(function () {//宏任務1 console.log('1'); }); new Promise(function (resolve) { console.log('2');//同步任務1 resolve(); }).then(function () {//微任務1 console.log('3'); }); console.log('4');//同步任務2 setTimeout(function () {//宏任務2 console.log('5');//宏任務2中的同步任務 new Promise(function (resolve) { console.log('6');//宏任務2中的同步任務 new Promise(function (resolve) {//宏任務2中的微任務 console.log('x1'); resolve(); }).then(function () { console.log('X2'); }); setTimeout(function () {//宏任務2中的宏任務 console.log('X3'); new Promise(function (resolve) {//宏任務2中的宏任務中的同步任務 console.log('X4'); resolve(); }).then(function () {//宏任務2中的宏任務中的微任務 console.log('X5'); }); }) resolve(); }).then(function () {//宏任務2中的微任務 console.log('7'); }); }) setTimeout(function () {//宏任務3 console.log('8'); }); //(對於這段代碼node環境和瀏覽器環境輸出一致) //輸出答案:2,4,3,1,5,6,x1,x2,7,8,x3,x4,x5 </script>
複製代碼
上面這個例子我爲了測試,可能搞得有點長。。。
Ajax是什麼:Ajax是(Asynchronous JavaScript and XML)的縮寫。如今,容許瀏覽器與服務器通訊而無須刷新當前頁面的技術都被叫作Ajax。核心使用XMLHttpRequest
對象。
axios是什麼:axios 是一個基於Promise 用於瀏覽器和 nodejs 的 HTTP 客戶端,本質上也是對原生XHR
的封裝,只不過它是Promise的實現版本,符合最新的ES規範。
fetch是什麼:Fetch被稱爲下一代Ajax技術,採用Promise方式來處理數據。是一種簡潔明瞭的API,比XMLHttpRequest更加簡單易用。
因此其主要區別是 axios、fetch請求後都支持Promise對象API,ajax只能用回調函數。
具體瞭解可看此文章一文秒懂 ajax, fetch, axios
a. TCP 是面向鏈接的,udp 是無鏈接的即發送數據前不須要先創建連接。
b. TCP 提供可靠的服務。也就是說,經過 TCP 鏈接傳送的數據,無差錯,不丟失,不重複,且按序到達; UDP 盡最大努力交付,即不保證可靠交付。 而且由於 tcp 可靠, 面向鏈接,不會丟失數據所以適合大數據量的交換。
c. TCP 是面向字節流,UDP 面向報文,而且網絡出現擁塞不會使得發送速率下降(因 此會出現丟包,對實時的應用好比 IP 電話和視頻會議等)。
d. TCP 只能是 1 對 1 的,而UDP 支持 1 對 1,1 對多。
e. TCP 的首部較大爲 20 字節,而 UDP 只有 8 字節。
f. TCP 是面向鏈接的可靠性傳輸,而 UDP 是不可靠的。
堆(heap)和棧(stack)的區別:
堆:隊列優先,先進先出;由操做系統自動分配釋放 ,存放函數的參數值,局部變量的值等。其操做方式相似於數據結構中的棧。
棧:先進後出;動態分配的空間 通常由程序員分配釋放, 若程序員不釋放,程序結束時可能由OS回收,分配方式卻是相似於鏈表。
棧和隊列的區別:
a. 棧只容許在表尾一端進行插入和刪除,隊列只容許在表尾一端進行插入,在表頭一端進行刪除。
b. 棧是先進後出,隊列是先進先出。
相同點
a. 都是同樣基於TCP的,都是可靠性傳輸協議。
b. 都是應用層協議。
不一樣點
a. WebSocket是雙向通訊協議,模擬Socket協議,能夠雙向發送或接受信息。HTTP是單向的。
b. WebSocket是須要握手進行創建鏈接的(相對HTTP來講,WebSocket是一種持久化的協議。它會基於HTTP協議,來完成一部分握手,HTTP握手部分完成,協議升級爲WebSocket)。
能夠學習這篇文章WebSocket其實沒那麼難
a. HTTP 明文傳輸,數據都是未加密的,安全性較差,HTTPS(SSL+HTTP) 數據傳輸過程是加密的,安全性較好。
b. 使用 HTTPS 協議須要到 CA(Certificate Authority,數字證書認證機構) 申請證書,通常免費證書較少,於是須要必定費用。
c. HTTP 頁面響應速度比 HTTPS 快,主要是由於 HTTP 使用 TCP 三次握手創建鏈接,客戶端和服務器須要交換 3 個包,而 HTTPS除了 TCP 的三個包,還要加上 ssl 握手須要的 9 個包,因此一共是 12 個包。
d. http 和 https 使用的是徹底不一樣的鏈接方式,用的端口也不同,前者是 80,後者是 443。
e. HTTPS 其實就是建構在 SSL/TLS 之上的 HTTP 協議,因此,要比較 HTTPS 比 HTTP 要更耗費服務器資源。
px: px就是pixel的縮寫,意爲像素。px就是一張圖片最小的一個點,一張位圖就是千千萬萬的這樣的點構成的。
em: 參考物是父元素的font-size,具備繼承的特色。若是自身定義了font-size按自身來計算(瀏覽器默認字體是16px),整個頁面內1em不是一個固定的值。
rem: css3新單位,相對於根元素html(網頁)的font-size,不會像em那樣,依賴於父元素的字體大小,而形成混亂。
vw: css3新單位,viewpoint width的縮寫,視窗寬度,1vw等於視窗寬度的1%。
舉個例子:瀏覽器寬度1200px, 1 vw = 1200px/100 = 12 px。
vh: css3新單位,viewpoint height的縮寫,視窗高度,1vh等於視窗高度的1%。
舉個例子:瀏覽器高度900px, 1 vh = 900px/100 = 9 px。
什麼是loader?
loader是文件加載器,可以加載資源文件,並對這些文件進行一些處理,諸如編譯、壓縮等,最終一塊兒打包到指定的文件中
什麼是plugin?
在webpack運行的生命週期中會廣播出許多事件,plugin能夠監聽這些事件,在合適的時機經過webpack提供的API改變輸出結果。
區別:
a. 三者均可以改變函數的this對象指向。
b. 三者第一個參數都是this要指向的對象,若是若是沒有這個參數或參數爲undefined或null,則默認指向全局window。
c. 三者均可以傳參,可是apply是數組,而call是參數列表,且apply和call是一次性傳入參數,而bind能夠分爲屢次傳入。
d. bind 改變this指向後不會當即執行,而是返回一個永久改變this指向的函數便於稍後調用; apply, call則是當即調用
301 Moved Permanently:
被請求的資源已永久移動到新位置,而且未來任何對此資源的引用都應該使用本響應返回的若干個 URI 之一。若是可能,擁有連接編輯功能的客戶端應 當自動把請求的地址修改成從服務器反饋回來的地址。除非額外指定,不然這個響應也 是可緩存的。
302 Found:
請求的資源如今臨時從不一樣的 URI 響應請求。因爲這樣的重定向是臨時的,客戶端應當繼續向原有地址發送之後的請求。只有在 Cache-Control 或 Expires 中進行了指定的狀況下,這個響應纔是可緩存的。
字面上的區別就是 301 是永久重定向,而 302 是臨時重定向。
301 比較經常使用的場景是使用域名跳轉。302 用來作臨時跳轉, 好比未登錄的用戶訪問用戶中心被重定向到登陸頁面
a. 根本區別:進程是操做系統資源分配的基本單位,而線程是處理器任務調度和執行的基本單位
b. 資源開銷:每一個進程都有獨立的代碼和數據空間(程序上下文),程序之間的切換會有較大的開銷;線程能夠看作輕量級的進程,同一類線程共享代碼和數據空間,每一個線程都有本身獨立的運行棧和程序計數器(PC),線程之間切換的開銷小。
c. 包含關係:若是一個進程內有多個線程,則執行過程不是一條線的,而是多條線(線程)共同完成的;線程是進程的一部分,因此線程也被稱爲輕權進程或者輕量級進程。
d. 內存分配:同一進程的線程共享本進程的地址空間和資源,而進程之間的地址空間和資源是相互獨立的
e. 影響關係:由於進程有獨立的地址空間,一個進程崩潰後,在保護模式下不會對其它進程產生影響,而線程之間沒有單獨的地址空間,一個線程死掉就等於整個進程死掉,因此多進程要比多線程健壯。
還可看看:
阮一峯對進程線程的簡單解釋
深刻理解Node.js 中的進程與線程
a. TypeScript 從核心語言方面和類概念的模塑方面對 JavaScript 對象模型進行擴展。
b. JavaScript 代碼能夠在無需任何修改的狀況下與 TypeScript 一同工做,同時可使用編譯器將 TypeScript 代碼轉換爲 JavaScript。
c. TypeScript 經過類型註解提供編譯時的靜態類型檢查。
d. TypeScript 中的數據要求帶有明確的類型,JavaScript不要求。
e. TypeScript 爲函數提供了缺省參數值。
f. TypeScript 引入了 JavaScript 中沒有的「類」概念。
h. TypeScript 中引入了模塊的概念,能夠把聲明、數據、函數和類封裝在模塊中。
a. 相同點是都是保存在瀏覽器端、且同源的
b. cookie數據始終在同源的http請求中攜帶(即便不須要),即cookie在瀏覽器和服務器間來回傳遞,而sessionStorage和localStorage不會自動把數據發送給服務器,僅在本地保存。cookie數據還有路徑(path)的概念,能夠限制cookie只屬於某個路徑下
c. 存儲大小限制也不一樣,cookie數據不能超過4K,同時由於每次http請求都會攜帶cookie、因此cookie只適合保存很小的數據,如會話標識。sessionStorage和localStorage雖然也有存儲大小的限制,但比cookie大得多,能夠達到5M或更大
d. 數據有效期不一樣,sessionStorage:僅在當前瀏覽器窗口關閉以前有效;localStorage:始終有效,窗口或瀏覽器關閉也一直保存,所以用做持久數據;cookie:只在設置的cookie過時時間以前有效,即便窗口關閉或瀏覽器關閉
e. 做用域不一樣,sessionStorage不在不一樣的瀏覽器窗口中共享,即便是同一個頁面;localstorage在全部同源窗口中都是共享的;cookie也是在全部同源窗口中都是共享的
f. webStorage(webstorage是本地存儲,存儲在客戶端,包括localStorage和sessionStorage
)支持事件通知機制,能夠將數據更新的通知發送給監聽者
h. webStorage的api接口使用更方便
http 1.0(構建可擴展性)
HTTP原有的應用很是侷限,瀏覽器和服務器迅速擴展使其用途更廣:
a. 版本信息如今會隨着每一個請求發送(HTTP1.0 被追加到GET行)
b. 狀態代碼行也會在響應開始時發送,容許瀏覽器自己瞭解請求的成功或失敗,並相應地調整其行爲(如以特定方式更新或使用本地緩存)
c. 引入了HTTP頭的概念,不管是對於請求仍是響應,容許傳輸元數據,並使協議很是靈活和可擴展。
d. Content-Type標頭告訴客戶端實際返回的內容的內容類型。在Content-Type標頭幫助下,增長了傳輸除純文本HTML文件外的其餘類型文檔的能力。
http 1.1(標準化的協議)
HTTP/1.0的多種不一樣的實現運用起來有些混亂,HTTP1.1是第一個標準化版本,重點關注的是校訂HTTP設計中的結構性缺陷:
a. 鏈接能夠重複使用,節省了屢次打開它的時間,以顯示嵌入到單個原始文檔中的資源。
b. 增長流水線操做,容許在第一個應答被徹底發送以前發送第二個請求,以下降通訊的延遲。
c. 支持響應分塊。
d. 引入額外的緩存控制機制。
e. 引入內容協商,包括語言,編碼,或類型,並容許客戶端和服務器約定以最適當的內容進行交換。
f. 經過 Host 頭,可以使不一樣的域名配置在同一個IP地址的服務器。
g. 安全性獲得了提升
http 2.0(爲了更優異的表現)
HTTP/2在HTTP/1.1有幾處基本的不一樣:
HTTP2是二進制協議而不是文本協議。再也不可讀和無障礙的手動建立,改善的優化技術如今可被實施。
這是一個複用協議。並行的請求能在同一個連接中處理,移除了HTTP/1.x中順序和阻塞的約束。
壓縮了headers。由於headers在一系列請求中經常是類似的,其移除了重複和傳輸重複數據的成本。
其容許服務器在客戶端緩存中填充數據,經過一個叫服務器推送的機制來提早請求。
直接放上對比表格:
數據庫 | MongoDB | MySQL |
---|---|---|
數據庫模型 | 非關係型 | 關係型 |
存儲方式 | 以類JSON的文檔的格式存儲 | 不一樣引擎有不一樣的存儲方式 |
查詢語句 | MongoDB查詢方式(相似JavaScript的函數) | SQL語句 |
數據處理方式 | 基於內存,將熱數據存放在物理內存中,從而達到高速讀寫 | 不一樣引擎有本身的特色 |
成熟度 | 新興數據庫,成熟度較低 | 成熟度高 |
普遍度 | NoSQL數據庫中,比較完善且開源,使用人數在不斷增加 | 開源數據庫,市場份額不斷增加 |
事務性 | 僅支持單文檔事務操做,弱一致性 | 支持事務操做 |
佔用空間 | 佔用空間大 | 佔用空間小 |
join操做 | MongoDB沒有join | MySQL支持join |
但願各位看官指出其中的錯誤,我必改正!也請對其中的一些問題提出本身的一些見解。這裏只是一些大概的總結,想要有最好的學習效果,仍是對其中每有一個點進行系統的學習。
筆者最近也在準備面試和尋找前端實習崗位中!wx:xieHB-frontend-178,加個微信一塊兒學習😜,也但願有大佬介紹個內推和提出學習意見,感謝。哈哈!