transform比top更適合進行居中
今天看到一個回答說transform比top更適合居中操作的原理，主要有三個部分，一是transform可以生成新的合成層，合成層上有GPU加速，二是它的使用不會引起迴流，三是top的動畫處理是是以px爲單位，但是transform的處理更加平滑，因爲它的基本單位更小。
首先對於第二點，因爲transform會生成新的渲染層，並使用一種合成渲染的方式，講渲染好的圖層平移過去，跳過了repaiting和reflow，因此它的性能確實更好。
但是對於第一點，transform在二維上的使用是不會創建新的合成層的，只有滿足一定條件的渲染層纔會被提升到新的合成層，我們可以通過devtool查看。
而使用了:
will-change: transform
可以看到這兒多了兩個合成層，這是爲什麼呢？
因爲我在代碼中的原渲染層上添加了一個新的渲染層，使用z-index，同時這個層層級 是高的，因此出現了隱式合成合成層的情況，生成了兩個合成層。
二維碼原理
用戶進入一個網頁後，服務器生成一個uid來標識用戶，而顯現出的二維碼則標識了對應uid的鏈接。當使用正確的客戶端打開這個鏈接時，服務器會收到用戶的相關信息，並在客戶端點擊確認登陸後生成一個token給對應網頁。之後的交互都依賴這個token。
寫個事件委託
function delegate(element, type, selector, fn){
element.addEventListener(type, e=>{
let target = e.target
while(!target.matches(selector)){
if(target==element){
target = null
break
}
target=target.parentNode
}
target&&fn(target)
})
}
數組去重
arr.reduce((t,v)=>t.includes(v)?t:[...t, v],[])
arr.filter((v,i)=>arr.indexOf(v)==i)
[...new Set(arr)]
Webpack生命週期
- 初始化參數，從配置文件或shell中
- 初始化Compile，加載插件，執行run方法開始編譯
- 根據entry找到入口文件
- 從入口文件出發，執行所有的loader對模塊編譯，找到該模塊依賴的模塊，再遞歸的執行，知道所有編譯結束。
- 拿到模塊翻譯後的最終內容和依賴關係
- 根據入口和模塊的依賴關係，打包成一個個chunk，把每個chunk轉換成輸出文件加入輸出列表
- 根據輸出配置輸出路徑和文件名
Webpack的XHR
- 在watch模式下，webpack監聽到文件的變化，重新打包並保存到內存中
- 通過sockjs在瀏覽器和服務端建立一個websocket長連接，將 webpack 編譯打包的各個階段的狀態信息告知瀏覽器端，最主要的是新模塊的hash值。
- 客戶端某模塊接收到新模塊的hasn值，發送AJAX請求，服務端返回一個json，上面有所有需要更新的模塊hash，根據這個更新列表發送JSONP。
- 檢查新舊模塊更新與否，更新模塊依賴等。
domain和samesite
domain設置.baidu.com，指的是cookie還是可以發送到百度及其下的子域名，而無需管請求的來源，因此domain是指子域名下能拿到該cookie。
samesite則關注請求來源。
記一次體驗很差的面試
上次遇到一次nice的面試官，這次同樣的企業，遇到了位很不尊重人的面試官，或許面試策略如此吧。
相對於CSS和JS，對HTML還是有些輕視的，在表單和meta這一塊，昨天被問到逮個正着。不過從一開始，對方總是說自己不帶偏見的去說這說那，言語中真讓人感覺不到所謂的不帶偏見。偶爾竟然還能說髒話，整個面試就已經不想進行下去了。還說移動端現在佔據業務的百分之90，這一點我是不知道，可能和您自家有關吧。還有就是說自己準備了很多移動端問題，你不瞭解touch事件我都沒法問。不過也沒辦法，人是菜了點，一臉笑臉面到最後，卻是這麼多家，只在這兒感覺得不到基本的尊重，實在是想不到的。
說一下漏掉的兩個問題，input表單的問題，問的是readonly和disable，這個確是不記得了，現在看來是一個能提交請求，一個不能。
meta，viewport和移動端相關知識的問題，移動端的知識確實是之前漏掉了，很多面經也沒有提到這塊，所有這裏來梳理一下。
首先是device pixels，我們可以理解爲一個點，有紅藍綠三個彩燈通過不同的亮度顯示最後的色彩。
接着是設備獨立像素，區別於上面的知識，設備獨立像素可能包含多個設備像素。而1個CSS像素 等於 1個設備獨立像素，設原來分辨率爲100100，元素爲5050，當我們分辨率改成200*200，元素自然顯得更小了。
2K和4K就不說了，說說PPI，5.8英寸、分辨率爲1125x2436的iphonex，ppi = Math.sqrt(11251125 + 24362436) / 5.8=463ppi。DPR則是物理像素除以設備獨立像素。
掌握了上面的基本知識，再看viewport就很好理解了，假如你使用!+Tab，html文件會自動生成：
<meta name="viewport" content="width=device-width, initial-scale=1.0">
這意味着當我們使用手機端測試時，寬度會默認爲設備的寬度，如iphone設爲375等。這樣字體就不至於縮放的很小，否則，大部分瀏覽器會以980的寬度進行渲染。
initial-scale定義了初始縮放比例，maximum-scale定義了用戶最多能放大多少倍，minimum-scale定義了最大能縮小多少倍。