1.Vue 常用的指令：
v-model
v-if
v-else
v-show
v-for
v-bind----簡寫: :class="qq"、:type="text"
v-on----簡寫: @click="qq"
2.v-model的原理
text 和 textarea 元素使用 value 屬性和 input 事件；checkbox 和 radio 使用 checked 屬性和 change 事件；select 字段將 value 作爲 prop 並將 change 作爲事件。
修飾符：
.lazy .number .trim
3.修改頁面上綁定的變量值，比如一段文章的title，下一行代碼是否能立即獲取到title的變化
不能。需要nextTick。 Vue 異步執行 DOM 更新。只要觀察到數據變化，Vue 將開啓一個隊列，並緩衝在同一事件循環中發生的所有數據改變。如果同一個 watcher 被多次觸發，只會被推入到隊列中一次。這種在緩衝時去除重複數據對於避免不必要的計算和 DOM 操作上非常重要。然後，在下一個的事件循環“tick”中，Vue 刷新隊列並執行實際 (已去重的) 工作。Vue 在內部嘗試對異步隊列使用原生的 Promise.then 和MessageChannel，如果執行環境不支持，會採用 setTimeout(fn, 0)代替。
4.Vue怎麼進行依賴收集的
Observer 的構造函數使用 defineReactive 方法給對象的鍵響應式化，給對象的屬性遞歸添加 getter/setter ，當data被取值的時候觸發 getter 並蒐集依賴，當被修改值的時候先觸發 getter 再觸發 setter 並派發更新
每個組件實例都有相應的 Watcher 實例對象，它會在組件渲染的過程中把屬性記錄爲依賴，之後當依賴項的 setter 被調用時，會通知 watcher 重新計算，從而致使它關聯的組件得以更新。
5.爲什麼需要Vuex
一、多個視圖依賴於同一狀態。
二、來自不同視圖的行爲需要變更同一狀態。
對於問題一，傳參的方法對於多層嵌套的組件將會非常繁瑣，並且對於兄弟組件間的狀態傳遞無能爲力。對於問題二，我們經常會採用父子組件直接引用或者通過事件來變更和同步狀態的多份拷貝。以上的這些模式非常脆弱，通常會導致無法維護的代碼。
因此，我們爲什麼不把組件的共享狀態抽取出來，以一個全局單例模式管理呢？在這種模式下，我們的組件樹構成了一個巨大的“視圖”，不管在樹的哪個位置，任何組件都能獲取狀態或者觸發行爲！
另外，通過定義和隔離狀態管理中的各種概念並強制遵守一定的規則，我們的代碼將會變得更結構化且易維護。
6.介紹一下Vue中的computed
我們可以將同一函數定義爲一個方法而不是一個計算屬性。兩種方式的最終結果確實是完全相同的。然而，不同的是計算屬性是基於它們的響應式依賴進行緩存的。只在相關響應式依賴發生改變時它們纔會重新求值。
計算屬性的 setter VS watch
A.當組件初始化的時候，computed 和 data 會分別建立各自的響應系統，Observer遍歷 data 中每個屬性設置 get/set數據攔截
B.初始化 computed 會調用 initComputed 函數
a.註冊一個 watcher 實例，並在內實例化一個 Dep 消息訂閱器用作後續收集依賴（比如渲染函數的 watcher 或者其他觀察該計算屬性變化的 watcher ）
b.調用計算屬性時會觸發其Object.defineProperty的get訪問器函數
c.調用 watcher.depend() 方法向自身的消息訂閱器 dep 的 subs 中添加其他屬性的 watcher
d.調用 watcher 的 evaluate 方法（進而調用 watcher 的 get 方法）讓自身成爲其他 watcher 的消息訂閱器的訂閱者，首先將 watcher 賦給 Dep.target，然後執行 getter 求值函數，當訪問求值函數裏面的屬性（比如來自 data、props 或其他 computed）時，會同樣觸發它們的 get 訪問器函數從而將該計算屬性的 watcher 添加到求值函數中屬性的 watcher 的消息訂閱器 dep 中，當這些操作完成，最後關閉 Dep.target 賦爲 null 並返回求值函數結果。
C.當某個屬性發生變化，觸發 set 攔截函數，然後調用自身消息訂閱器 dep 的 notify 方法，遍歷當前 dep 中保存着所有訂閱者 wathcer 的 subs 數組，並逐個調用 watcher 的 update 方法，完成響應更新。
7.Webpack的流程
- 初始化參數：從配置文件和
Shell語句中讀取與合併參數，得出最終的參數； - 開始編譯：用上一步得到的參數初始化
Compiler對象，加載所有配置的插件，執行對象的run方法開始執行編譯； - 確定入口：根據配置中的
entry找出所有的入口文件 - 編譯模塊：從入口文件出發，調用所有配置的
Loader對模塊進行翻譯，再找出該模塊依賴的模塊，再遞歸本步驟直到所有入口依賴的文件都經過了本步驟的處理； - 完成模塊編譯：在經過第4步使用
Loader翻譯完所有模塊後，得到了每個模塊被翻譯後的最終內容以及它們之間的依賴關係； - 輸出資源：根據入口和模塊之間的依賴關係，組裝成一個個包含多個模塊的
Chunk，再把每個Chunk轉換成一個單獨的文件加入到輸出列表，這步是可以修改輸出內容的最後機會； - 輸出完成：在確定好輸出內容後，根據配置確定輸出的路徑和文件名，把文件內容寫入到文件系統。 在以上過程中，
webpack會在特定的時間點廣播出特定的事件，插件在監聽到感興趣的事件後會執行特定的邏輯，並且插件可以調用webpack提供的API改變webpack的運行結果。
8.Class的Constructor調用Super
A.當作函數使用
在 constructor 中必須調用 super 方法，因爲子類沒有自己的 this 對象，而是繼承父類的 this 對象，然後對其進行加工,而 super 就代表了父類的構造函數。
B.當作對象使用
在普通方法中，指向父類的原型對象；在靜態方法中，指向父類。
9.Node裏面兩個文件互相require怎樣
爲了防止模塊載入的死循環，Node.js 在模塊第一次載入後會把它的結果進行緩存，下一次再對它進行載入的時候會直接從緩存中取出結果。所以在這種循環依賴情形下，不會有死循環，但是卻會因爲緩存造成模塊沒有按照我們預想的那樣被導出。
詳細點擊鏈接🔗
10.移動端響應式、自適應適配
響應式設計與自適應設計的區別：響應式開發一套界面，通過檢測視口分辨率，針對不同客戶端在客戶端做代碼處理，來展現不同的佈局和內容；自適應需要開發多套界面，通過檢測視口分辨率，來判斷當前訪問的設備是pc端、平板、手機，從而請求服務層，返回不同的頁面。
響應式佈局的實現方案：
A.媒體查詢
B.百分比佈局
C.rem佈局
D.視口單位vh、vw、vmax、vmin
11.bootstrapt實現響應式的原理是什麼
Bootstrap採取12列的柵格體系，根據主流設備的尺寸進行分段，每段寬度固定，通過百分比和媒體查詢實現響應式佈局。
12.304緩存
強緩存通過Expires和Cache-Control兩種響應頭實現 Expires是http1.0提出的一個表示資源過期時間的header，它描述的是一個絕對時間，由服務器返回。Expires 受限於本地時間，如果修改了本地時間，可能會造成緩存失效 Cache-Control 出現於 HTTP / 1.1，優先級高於 Expires ,表示的是相對時間 Cache-Control: no-cache 是可以緩存到本地緩存區中的，只是在與原始服務器進行新鮮度再驗證之前，緩存不能將其提供給客戶端使用；Cache-Control: no-store纔是真正的不緩存數據到本地； Cache-Control: public可以被所有用戶緩存（多用戶共享），包括終端和CDN等中間代理服務器； Cache-Control: private只能被終端瀏覽器緩存（而且是私有緩存），不允許中繼緩存服務器進行緩存；
協商緩存是利用的是【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】這兩對Header來管理的
13.react的生命週期函數
React生命週期主要包括三個階段：初始化階段、運行中階段和銷燬階段，在React不同的生命週期裏，會依次觸發不同的鉤子函數
A.初始化階段
- 設置組件的默認屬性
- 設置組件的初始化狀態
componentWillMount()render()componentDidMount()
B.運行中階段
componentWillReceiveProps()shouldComponentUpdate()componentWillUpdate()componentDidUpdate()
C.銷燬階段
componentWillUnmount()
14.react組件之間的傳遞數據
Propscontextredux
15.HTTP2.0
- 二進制傳輸
- 多路複用
- Header壓縮
- 服務器推送
- 更安全
16.position的屬性
- static
- relative
- absolute
- fixed
- stacky
17.HTTPS（securely transferring web pages）服務器
默認端口號爲443/tcp 443/udp
18.21.v-if、v-show
官方解釋： v-if 是“真正”的條件渲染，因爲它會確保在切換過程中條件塊內的事件監聽器和子組件適當地被銷燬和重建。 v-if 也是惰性的：如果在初始渲染時條件爲假，則什麼也不做——直到條件第一次變爲真時，纔會開始渲染條件塊。
相比之下，v-show 就簡單得多——不管初始條件是什麼，元素總是會被渲染，並且只是簡單地基於 CSS 進行切換。
一般來說，v-if 有更高的切換開銷，而 v-show 有更高的初始渲染開銷。
因此，如果需要非常頻繁地切換，則使用 v-show 較好；如果在運行時條件很少改變，則使用 v-if 較好。
理解：
- 手段：
v-if是動態的向DOM樹內添加或者刪除DOM元素；v-show是通過設置DOM元素的display樣式屬性控制顯隱； - 編譯過程：
v-if切換有一個局部編譯/卸載的過程，切換過程中合適地銷燬和重建內部的事件監聽和子組件；v-show只是簡單的基於css切換； - 編譯條件：
v-if是惰性的，如果初始條件爲假，則什麼也不做；只有在條件第一次變爲真時纔開始局部編譯（編譯被緩存後，然後再切換的時候進行局部卸載);v-show是在任何條件下（首次條件是否爲真）都被編譯，然後被緩存，而且DOM元素保留； - 性能消耗：
v-if有更高的切換消耗；v-show有更高的初始渲染消耗
