前端綜合試題（一）

時間 2019-11-15

標籤前端綜合試題简体版

原文原文鏈接

談談對html5的瞭解

1.良好的移動性，以移動設備爲主。javascript

2.響應式設計，以適應自動變化的屏幕尺寸css

3.支持離線緩存技術，webStorage本地緩存html

4.新增canvas，video，audio等新標籤元素。新增特殊內容元素：article，footer，header，nav，section等，新增表單控件：calendar，date，time，email，url，search。前端

5.地理定位...vue

6.新增webSocket/webWork技術html5

百度移動端首頁秒開是如何作到的？

從幾個方面優化：java

(1) 靜態文件放置node

(2) 緩存react

(3) 外鏈jquery

(4) 緩存DOM

(5) 使用 iconfont

(6) 卡片的異步加載與緩存

(7) 不在首屏的就要異步化

(8) 少許靜態文件的域名

詳細參見：http://www.javashuo.com/article/p-wrkmdljz-gd.html

前端速度統計（性能統計）如何作？

回答下面的兩個問題：

(1) 網站都有哪些指標？

(2) 如何統計本身網站的這些指標？

詳細參見：https://segmentfault.eom/a/1190000005869953

說出三種減小頁面加載的方法（加載時間指感知的時間或實際加載的時間）

CSS Sprites；

JS、CSS源碼壓縮、圖片大小控制合適；

網頁Gzip；

CDN託管；

data緩存；

圖片服務器；

項目中有沒有用過加密，哪一種加密算法？

項目中沒有用過，但我瞭解幾個加密算法：

(1) RSA加密

(2) MD5加密

(3) SHA256加密

(4) SHA1（微信公衆號配置wx.config）

Ajax同步和異步的區別，如何解決跨域問題

同步的概念應該是來自於OS中關於同步的概念:不一樣進程爲協同完成某項工做而在前後次序上調整(經過阻塞,喚醒等方式).同步強調的是順序性.誰先誰後.異步則不存在這種順序性.

同步：瀏覽器訪問服務器請求，用戶看獲得頁面刷新，從新發請求,等請求完，頁面刷新，新內容出現，用戶看到新內容,進行下一步操做。

異步：瀏覽器訪問服務器請求，用戶正常操做，瀏覽器後端進行請求。等請求完，頁面不刷新，新內容也會出現，用戶看到新內容。

jsonp、 iframe、window.name、window.postMessage、服務器上設置代理頁面，socke,cros

列舉幾種後端通信的方法及其使用的場景，關於跨域的理解。

1.後端程序能夠經過session來進行通信，session有過時時間，主要用於驗證碼的驗證，登陸過時等的應用。

2.數據庫，數據庫支持多種語言的操做，那麼經過數據庫就能夠通信。

關於跨域：

跨域請求存在的緣由：因爲瀏覽器的同源策略，即屬於不一樣域的頁面之間不能相互訪問各自的頁面內容。

跨域的場景：

1.域名不一樣 www.yangwei.com 和www.wuyu.com 即爲不一樣的域名）

2.二級域名相同，子域名不一樣（www.wuhan.yangwei.com www.shenzheng.yangwei.com 爲子域不一樣）

3.端口不一樣，協議不一樣（ http://www.yangwei.com 和https://www.yangwei.com屬於跨域www.yangwei.con:8888和www.yangwei.con:8080)

跨域的方式：（內容較多，需掌握CORS和jsonp，其餘內容也要了解）

1.前端的方式: possMessage，window.name,document.domain,image.src(得不到數據返回)，jsonP(script.src後臺不配合得不到數據返回)，style.href（得不到數據返回)

一.image.src,script.src,style.href 不受同源策略的影響能夠加載其餘域的資源，能夠用這個特性，向服務器發送數據。最經常使用的就是使用image.src 向服務器發送前端的錯誤信息。image.src 和style.href 是沒法獲取服務器的數據返回的，script.src 服務器端配合能夠獲得數據返回。

2、possMessage,window.name,document.domain 是兩個窗口直接相互傳遞數據。

（1）possMessage 是HTML5中新增的，使用限制是必須得到窗口的window 引用。IE8+支持，firefox，chrome,safair,opera支持

（2）window.name ，在一個頁面中打開另外一個頁面時，window.name 是共享的，因此能夠經過window.name 來傳遞數據，window.name的限制大小是2M，這個全部瀏覽器都支持,且沒有什麼限制。

3） document.domain 將兩個頁面的document.domain 設置成相同，document.domain 只能設置成父級域名，既能夠訪問，使用限制：這頂級域名必須相同

2.純後端方式: CORS，服務器代理

CORS 是w3c標準的方式，經過在web服務器端設置：響應頭Access一Cntrol一Alow一Origin 來指定哪些域能夠訪問本域的數據，ie8&9(XDomainRequest),10+,chrom4 ，firefox3.5,safair4，opera12支持這種方式。

服務器代理，同源策略只存在瀏覽器端，經過服務器轉發請求能夠達到跨域請求的目的，劣勢：增長服務器的負擔，且訪問速度慢。

3.先後端結合:JsonP

script.src 不受同源策略的限制，因此能夠動態的建立script標籤，將要請求數據的域寫在src 中參數中附帶回調的方法，服務器端返回回調函數的字符串，並帶參數。

如 script.src="http://www.yangwei.com/?id=001&callback=getInfoCallback",服務器端返回 getInfoCallBack("name:yangwei;age:18") 這段代碼會直接執行，在前面定義好getInfoCallBack函數，既能夠得到數據並解析。這種是最多見的方式。

4.webSocket（瞭解性拓展）

服務端推送websocket和sse場景及應用

應用場景

均可以進行服務端推送,而且都是使用長鏈接來進行.但二者的實現又有一點不一樣,sse仍使用http協議,而且使用相同的連接發送正常的http協議報文.而websocket是使用http協議進行握手,而後再使用同一個連接進行websocket協議的通訊.

websocket能夠進行雙向的通訊,即服務端能夠往客戶端發信息,客戶端也能夠向服務端發信息.而sse是單向的,只能由服務端往客戶端發.

websocket自帶鏈接的保持,即經過ping/pong協議保證鏈接能夠始終維持,sse沒有這個保證,不過能夠參考ping/pong協議,本身週期性地發送信息來一樣地進行處理.好比,5秒往客戶端發一個特別的信息(經過type/name進行區分).其次,由於是基於瀏覽器的使用,sse有一個特性,就是瀏覽器發現一個鏈接斷掉了,就會自動地進行重聯,即從新發送請求.這樣,服務端也不用擔憂鏈接被斷開,不過須要處理新的請求必須和上一次請求的內容相連續,以及新的推送註冊.

由於都是使用http協議進行起始處理,所以在籤權上均可以使用到http協議自己的一些東西,好比header/cookie籤權.在相應的握手階段,經過讀取cookie(session)來保證相應的請求必須是通過受權的,也能夠用於定位使用人.甚至能夠經過這些信息保證單個用戶只能有一個請求,避免重複請求

因爲都是基於瀏覽器使用,所以建議的數據傳輸都是文本型.雖然websocket支持二進制frame傳輸,不過一些都不建議使用.sse只能傳輸文本

無論是websocket仍是sse,在用於通訊時,都建議只用於進行數據的推送,而不是進行完整的應用處理.這裏能夠理解爲,常規的業務處理仍然交給後端的服務來處理.這樣,便可以使用以前的業務開發的優點,又可使用推送的優點.而不是走向另外一個級端,即全部的信息都想經過推送來傳遞.

開發方式

websocket開發首選netty,由於netty對協議的封裝已經作到了徹底的支持.經過 HttpServerCodec做爲握手協議,WebSocketServerProtocolHandler做爲協議處理,而後再加一個本身的handler,就完成了相應的業務處理.同時在性能上,netty在一個ws的請求創建起來以後,會自動地去除httpServerCodec相關的handler,這樣保證後續的處理都是按照ws的協議來進行.

sse開發首選jersey,jersey一media一sse提供了相應的sse支持,而且經過與rest相集成,開發一個sse就跟普通的業務開發相同.

ws和sse在文本支持上都只支持utf一8編碼,所以在處理上須要註冊編碼方式.同時在使用sse時,若是後端第一次進行響應時,相應的編碼不對.chrome會直接報錯,包括utf8都會報錯(這是以前後端開發的一個問題),能夠修正或者增長相應的攔截器,保證後端content一type響應中的charset=UTF一8.

ws和sse均可以經過nginx進行代理轉發.ws的處理只須要設置http版本,以及從新轉發前端的Upgrade和Connection頭便可.而sse,也能夠經過禁用buffer來處理.參考 http://stackoverflow.com/questions/27898622/server一sent一events一stopped一work一after一enabling一ssl一on一proxy

特定實現

爲保證在開發時推送類的和業務類的系統不會耦合在一塊兒,或者同一個應用內有兩種處理模式的功能存在.建議直接在系統層就開發2個不一樣的系統,一個專門用於推送,另外一個用於相應的業務處理.而後業務處理後的數據,須要再交由推送處理,則能夠在後端進行經過消息系統進行中轉,如kafka(持久保證)或redis(內存訂閱)等

由於兩者在ie上的支持都頗有限,所以不建議在ie上進行嘗試

使用sse仍是websocket,取決因而否須要前臺交互,還取決於對後端的支持技術的瞭解程序.好比,瞭解jersey多一點,仍是netty多一點.因爲最近netty進行微服務化底層通訊支持愈來愈流行,我的更傾向於使用websocket.但若是僅僅是一個簡單的推送功能,又不但願修改代碼,那也可使用jersey(畢竟以前的系統就是在上面進行開發的)

須要後端有的時候須要進行定向發送或者是羣發,這種需求ws和sse的實現中都有相應的處理.如ChannelGroup和SseBroadcaster,這樣在後端獲取到一個消息,須要進行路由時就能夠從這裏面拿相應的channel信息.不過,前提是對各個channel上進行了特定的消息綁定,這樣就好區分具體的路由信息.具體路由策略能夠在創建時綁定session,後續經過session來路由.

設計一個幻燈應用，須要列舉選擇的基礎框架、項目的基礎框架和代碼管理、幻燈數據的存儲和讀取，部分特效的實現，能夠只寫思路，後續面聊。

本題無標準答案，同窗們能夠本身研究考慮一下，。

Html5中本地存儲概念是什麼，有什麼優勢，與cookie有什麼區別？

html5中的Web Storage包括了兩種存儲方式：sessionStorage和localStorage。

sessionStorage用於本地存儲一個會話（session）中的數據，這些數據只有在同一個會話中的頁面才能訪問而且當會話結束後數據也隨之銷燬。所以sessionStorage不是一種持久化的本地存儲，僅僅是會話級別的存儲。而localStorage用於持久化的本地存儲，除非主動刪除數據，不然數據是永遠不會過時的；

cookie是網站爲了標示用戶身份而儲存在用戶本地終端（Client Side）上的數據（一般通過加密）。

區別：

一、 cookie數據始終在同源的http請求中攜帶（即便不須要），即cookie在瀏覽器和服務器間來回傳遞。而sessionStorage和localStorage不會自動把數據發給服務器，僅在本地保存。cookie數據還有路徑（path）的概念，能夠限制cookie只屬於某個路徑下。

二、存儲大小限制也不一樣，cookie數據不能超過4k，同時由於每次http請求都會攜帶cookie，因此cookie只適合保存很小的數據，如會話標識。sessionStorage和localStorage 雖然也有存儲大小的限制，但比cookie大得多，能夠達到5M或更大。

三、數據有效期不一樣，sessionStorage：僅在當前瀏覽器窗口關閉前有效，天然也就不可能持久保持；localStorage：始終有效，窗口或瀏覽器關閉也一直保存，所以用做持久數據；cookie只在設置的cookie過時時間以前一直有效，即便窗口或瀏覽器關閉。

做用域不一樣，sessionStorage不在不一樣的瀏覽器窗口中共享，即便是同一個頁面；localStorage 在全部同源窗口中都是共享的；cookie也是在全部同源窗口中都是共享的。

說說你對做用域鏈的理解

做用域鏈的做用是保證執行環境裏有權訪問的變量和函數是有序的，做用域鏈的變量只能向上訪問，變量訪問到window對象即被終止，做用域鏈向下訪問變量是不被容許的。

見好文：http://weizhifeng.net/javascript-the-core.html

對新技術有那些瞭解，常去的網站有那些

node.js、angular.js、vue.js，reactjs，react-native，微信小程序

掘金、簡書、github、csdn，知乎等

用程序找出數組中出現次數超過一半的數字

思路：

一、一個數字在數組中出現次數超過了一半，則排序後，位於數組中間的數字必定就是該出現次數超過了長度一半的數字（能夠用反證法證實），也便是說，這個數字就是統計學上的中位數。最容易想到的辦法是用快速排序對數組排序號後，直接取出中間的那個數字，這樣的時間複雜度爲O(nlogn)，空間複雜度爲O(1)。

2 、事實上能夠不用對數組進行排序，或者說僅部分排序，受快速排序的partition函數的啓發，咱們能夠利用反覆調用partition函數來求的該數字。咱們如今數組中隨機選取一個數字，然後經過Partition函數返回該數字在數組中的索引index，若是index恰好等於n/2，則這個數字即是數組的中位數，也便是要求的數，若是index大於n/2，則中位數確定在index的左邊，在左邊繼續尋找便可，反之在右邊尋找。這樣能夠只在index的一邊尋找，而不用兩邊都排序，減小了一半排序時間。這種狀況的平均時間複雜度大體爲：T(n) = n+n/2+n/4+n/8+....+1，很明顯當n很大時，T(n)趨近於2n，也就是說平均狀況下時間複雜度爲O(n),可是這種狀況下，最壞的時間複雜度依然爲O(n*n)，最壞狀況下，index老是位於數組的最左或最右邊，這樣時間複雜度爲T(n) = n+n一1+n一2+n一3+....+1 = n(n一1)/2，顯然，時間複雜度爲O(n*n)，空間複雜度爲O(1)。

常使用的庫有哪些？經常使用的前端開發工具？開發過什麼應用或組件？

1)bootstrap, easy UI, highcharts和echarts， jqueryUI , jquery、angular.js, vue.js, reactjs等。

2)前端開發工具：gulp webpack

3)輪播插件，拖拽插件

你作的頁面在哪些瀏覽器測試過？這些瀏覽器的內核分別是什麼？

IE內核瀏覽器：360，傲遊，搜狗，世界之窗，騰訊TT。

非IE內核瀏覽器：firefox opera safari chrome 。

IE瀏覽器的內核Trident、Mozilla的Gecko、Chrome的Blink（WebKit的分支）、Opera內核原爲Presto，現爲Blink；

對前端界面工程師這個職位是怎麼理解的？它的前景怎樣？

前端工程師屬於一個比較新興的技術，各類技術層出不窮，隨着客戶體驗的重要性前端須要掌握的技能也愈來愈多，對前端的要求也愈來愈多，並且咱們前端是最貼近用戶的程序員，主要負責實現界面交互，提高用戶體驗，並且有了Node.js，前端能夠實現服務端的一些事情，針對服務器的優化、擁抱最新前端技術，除了掌握必要的技能還要掌握用戶的心理，善於溝通。

前景：前景無疑是值得確定的，也須要咱們時刻關注最新的技術，這會是一個時刻都在學習的道路

對WEB標準以及w3c的理解與認識？

Web標準就是將頁面的結構、表現和行爲各自獨立實現，w3c對標註提出了規範化的要求

1.對結構的要求：（標籤規範能夠提升搜索引擎對頁面的抓取效率，對SEO頗有幫助）

1）標籤字母要小寫；

2）標籤要閉合；

3）標籤不容許隨意嵌套。

2.對css和js的要求：

1）儘可能使用外聯css樣式表和js腳本，使結構、表現和行爲分紅三塊，符合規範，同時提升頁面渲染速度，提升用戶體驗；

2）樣式儘可能少用行間樣式表，使結構與表現分離，標籤的id和class命名要作到見文知義，標籤越少，加載越快，用戶體驗更高，代碼維護更簡單，便於改版；

3）不須要變更頁面內容，即可提供打印版本而不須要複製內容，提升網站易用性

爲何利用多個域名來提供網站資源會更有效？

1) 突破瀏覽器的併發限制（瀏覽器同一域名最大的併發請求數量爲6個，ie6爲2個）

2) 節約cookie帶寬 (默認狀況下，主域名請求靜態資源一樣會攜帶cookie，但跨域請求則不會攜帶，必定程度上節約了cookie帶寬）

3) CDN緩存更方便

4) 防止沒必要要的安全問題（尤爲是cookie的隔離尤其重要）

5) 節約主機域名鏈接數，優化頁面響應速度

身爲覺得web前端工程師，你確定知道如今最流行的前端技術吧，有那些？

Vuejs2.0/Angular2.0/React Native /es6//Nodejs

http2

gulp/webpack

請簡述爲何要使用數據庫的事務

數據庫事務(Database Transaction) ，是指做爲單個邏輯工做單元執行的一系列操做，要麼徹底地執行，要麼徹底地不執行。

原子性（Atomic）（Atomicity)
　　事務必須是原子工做單元；對於其數據修改，要麼全都執行，要麼全都不執行。一般，與某個事務關聯的操做具備共同的目標，而且是相互依賴的。若是系統只執行這些操做的一個子集，則可能會破壞事務的整體目標。原子性消除了系統處理操做子集的可能性。
　　一致性（Consistent）(Consistency)
　　事務在完成時，必須使全部的數據都保持一致狀態。在相關數據庫中，全部規則都必須應用於事務的修改，以保持全部數據的完整性。事務結束時，全部的內部數據結構（如 B 樹索引或雙向鏈表）都必須是正確的。某些維護一致性的責任由應用程序開發人員承擔，他們必須確保應用程序已強制全部已知的完整性約束。例如，當開發用於轉賬的應用程序時，應避免在轉賬過程當中任意移動小數點。
　　隔離性（Insulation）(Isolation)
　　由併發事務所做的修改必須與任何其它併發事務所做的修改隔離。事務查看數據時數據所處的狀態，要麼是另外一併發事務修改它以前的狀態，要麼是另外一事務修改它以後的狀態，事務不會查看中間狀態的數據。這稱爲隔離性，由於它可以從新裝載起始數據，而且重播一系列事務，以使數據結束時的狀態與原始事務執行的狀態相同。當事務可序列化時將得到最高的隔離級別。在此級別上，從一組可並行執行的事務得到的結果與經過連續運行每一個事務所得到的結果相同。因爲高度隔離會限制可並行執行的事務數，因此一些應用程序下降隔離級別以換取更大的吞吐量。
　　持久性（Duration）(Durability）
　　事務完成以後，它對於系統的影響是永久性的。該修改即便出現致命的系統故障也將一直保持。

聊一聊前端存儲。

老朋友cookie

短暫的 sessionStorage

簡易強大的localStorage

websql與indexeddb

詳細參見：https://segmentfault.com/aZ1190000005927232

CSS，JS代碼壓縮，以及代碼CDN託管，圖片整合

CSSJS代碼壓縮：

能夠應用gulp的gulp一uglify, gulp一minify一css模塊完成；能夠應用webpack的 UglifyJsPlugin 壓縮插件完成。

CDN:

內容分發網絡(CDN)是一個經策略性部署的總體系統，包括分佈式存儲、負載均衡、網絡請求的重定向和內容管理4個要件。主要特色有：本地Cache加速，鏡像服務，遠程加速，帶寬優化。關鍵技術有：內容發佈，內容路由，內容交換，性能管理。CDN網站加速適合以諮詢爲主的網站。CDN是對域名加速不是對網站服務器加速。CDN和鏡像站比較不須要訪客手動選擇要訪問的鏡像站。CDN使用後網站無需任何修改便可使用CDN得到加速效果。

若是經過CDN後看到的網頁仍是舊網頁，能夠經過URL推送服務解決，新增的網頁和圖片不須要URL推送。使用動態網頁能夠不緩存即時性要求很高的網頁和圖片。CDN能夠經過 gi域SVN來管理。

圖片整合

減小網站加載時間的最有效的方式之一就是減小網站的HTTP請求數。實現這一目標的一個有效的方法就是經過CSS Sprites ——將多個圖片整合到一個圖片中，而後再用CSS來定位。缺點是可維護性差。可使用百度的fis/webpack來自動化管理sprite。

如何利用webpack把代碼上傳服務器以及轉碼測試?

代碼上傳：

可使用sftp一webpack一plugin,可是會把子文件夾給提取出來，不優雅。可使用gulp +webpack來實現。

轉碼測試

webpack應用babel來對ES6轉碼，開啓devtool: 「source一map"來進行瀏覽器測試。應用 karma或mocha來作單元測試。

項目上線流程是怎樣的？

流程建議

模擬線上的開發環境

本地反向代理線上真實環境開發便可。（apache, nginx, nodejs都可實現）

模擬線上的測試環境

模擬線上的測試環境，實際上是須要一臺有真實數據的測試機，建議沒條件搭daily的，就直接用線上數據測好了，只不過程序部分走大家的測試環境而已，有條件搭daily最好。

可連調的測試環境

可連調的測試環境，分爲2種。一種是開發測試都在一個局域網段，直接綁hosts便可，不在一個網段，就每人分配一臺虛擬的測試機，放在你們均可以訪問到的公司內網，代碼直接往上布便可。

自動化的上線系統

自動化的上線系統，能夠採用Jenkins。若是沒有，能夠自行搭建一個簡易的上線系統，原理是每次上線時都抽取最新的trunk或master，作一個tag，再打一個時間戳的標記，而後分發到cdn就好了。界面裏就2個功能，打tag,回滾到某tag,部署。

適合先後端的開發流程

開發流程依據公司所用到的工具，構建，框架。原則就是分散獨立開發，互相不干擾，連調時有hosts可綁便可。

簡單的可操做流程

代碼經過git管理，新需求建立新分支，分支開發，主幹發佈一上線走簡易上線系統，參見上一節

經過gulp+webpack連到發佈系統，一鍵集成，本地只關心原碼開發

本地環境經過webpack反向代理的server

搭建基於linux的本地測試機，自動完成build+push功能

工程化怎麼管理的？

前端工程化能夠自動化處理一些繁複的工做，提升開發效率，減小低級錯誤。

目前前端構建工具不少，綜合比較來看，gulp相對來講更靈活，能夠作更多的定製化任務，而webpack在模塊化方面更完美一些

gulp打造前端工程化方案，同時引入webpack來管理模塊化代碼，大體分工以下：

gulp：處理html壓縮/預處理/條件編譯，圖片壓縮，精靈圖自動合併等任務

webpack：管理模塊化，構建js/css。

具體流程可參考： http://blog.csdn.net/java_goodstudy/article/details/52797322

webpack 和 gulp 對比

Gulp就是爲了規範前端開發流程，實現先後端分離、模塊化開發、版本控制、文件合併與壓縮、mock數據等功能的一個前端自動化構建工具。說的形象點，「Gulp就像是一個產品的流水線，整個產品從無到有，都要受流水線的控制，在流水線上咱們能夠對產品進行管理。」另外，Gulp是經過task對整個開發過程進行構建。

Webpack是當下最熱門的前端資源模塊化管理和打包工具。它能夠將許多鬆散的模塊按照依賴和規則打包成符合生產環境部署的前端資源。還能夠將按需加載的模塊進行代碼分隔，等到實際須要的時候再異步加載。經過loader的轉換，任何形式的資源均可以視做模塊，比如 CommonJs 模塊、AMD 模塊、ES6 模塊、CSS、圖片、JSON、Coffeescript、LESS等。

Gulp和Webpack功能實現對比：從基本概念、啓動本地Server、sass/less預編譯、模塊化開發、文件合併與壓縮、mock數據、版本控制、組件控制八個方面對Gulp和Webpack進行對比。

詳細參見：http://www.tuicool.com/articles/e632EbA

webpack打包文件太大怎麼辦？

webpack把咱們全部的文件都打包成一個JS文件，這樣即便你是小項目，打包後的文件也會很是大。能夠從去除沒必要要的插件，提取第三方庫，代碼壓縮，代碼分割，設置緩存幾個方面着手優化。

詳細參見：http://www.jianshu.com/p/a64735eb0e2b

談談你對webpack的見解

WebPack 是一個模塊打包工具，你可使用WebPack管理你的模塊依賴，並編繹輸出模塊們所需的靜態文件。它可以很好地管理、打包Web開發中所用到的HTML、JavaScript、CSS以及各類靜態文件（圖片、字體等），讓開發過程更加高效。對於不一樣類型的資源，webpack有對應的模塊加載器。webpack模塊打包器會分析模塊間的依賴關係，最後生成了優化且合併後的靜態資源。

webpack的兩大特點：

1.code splitting（能夠自動完成）

2.loader 能夠處理各類類型的靜態文件，而且支持串聯操做

webpack 是以commonJS的形式來書寫腳本滴，但對 AMD/CMD 的支持也很全面，方便舊項目進行代碼遷移。

webpack具備requireJs和browserify的功能，但仍有不少本身的新特性：

1. 對 CommonJS 、 AMD 、ES6的語法作了兼容

2. 對js、css、圖片等資源文件都支持打包

3. 串聯式模塊加載器以及插件機制，讓其具備更好的靈活性和擴展性，例如提供對CoffeeScript、ES6的支持

4. 有獨立的配置文件webpack.config.js

5. 能夠將代碼切割成不一樣的chunk，實現按需加載，下降了初始化時間

6. 支持 SourceUrls 和 SourceMaps，易於調試

7. 具備強大的Plugin接口，大可能是內部插件，使用起來比較靈活

8.webpack 使用異步 IO 並具備多級緩存。這使得 webpack 很快且在增量編譯上更加快

說說你對AMD和Commonjs的理解

CommonJS是服務器端模塊的規範，Node.js採用了這個規範。CommonJS規範加載模塊是同步的，也就是說，只有加載完成，才能執行後面的操做。AMD規範則是非同步加載模塊，容許指定回調函數。

AMD推薦的風格經過返回一個對象作爲模塊對象，CommonJS的風格經過對module.exports或exports的屬性賦值來達到暴露模塊對象的目的。

不想讓別人盜用你的圖片，訪問你的服務器資源該怎麼處理？

目前經常使用的防盜鏈方法主要有兩種：

(1) 設置Referer:適合不想寫代碼的用戶，也適合喜歡開發的用戶（Referer是HTTP協議中的請求頭，在跨頁面訪問的時候會帶上。須要看看瀏覽器請求的Referer是http://仍是https://，通常是http://）

(2) 簽名URL:適合喜歡開發的用戶

詳細參見：https://yq.aliyun.com/articles/57931

精靈圖和base64如何選擇？

css精靈，用於一些小的圖標不是特別多，一個的體積也稍大，好比大於10K (這個沒有嚴格的界定）。

base64,用於小圖標體積較小（相對於css精靈），多少都無所謂。字體圖標，用於一些別人作好的圖標庫（也有少數本身去作的）用起來比較方便，他的圖標只能用於單色，圖標用只能於一種顏色。

webpack怎麼引入第三方的庫？

拿jQuery爲例：

entry: {

page: 'path/to/page.js',

jquery: 'node—modules/jquery/dist/jquery.min.js'

}

new HtmlWebpaekPlugin({

 filename: 'index.html',

 template: 'index.html',

 inject: true,

chunks: ['jquery','page'] // 按照前後順序插入 script 標籤

})