按鈕在界面設計中，屬于最基礎的元素部分組成，按鈕設計的精致，整個頁面的品質也會上升不少的檔次。今天給大家分享這篇文章，主要講解在設計按鈕時我們應該考慮哪些因素，包括視覺上，有哪些萬能的方法及公式，能夠正確的制定按鈕的設計標準，來提升整個設計的系統性。
在設計按鈕之前，需要先理解按鈕起到的代表含義。什么地方該加按鈕，什么地方不加按鈕，在系統化設計思路中需要非常有講究。通常按鈕在頁面，主要起到以下三點作用：
1. 某一類型的功能操作
這種比較常見，如一些控件形態的按鈕，比如加減、折疊、展開，下拉等。這類按鈕會起到一些功能形態的作用，常用于交互場景。所以在這類按鈕設計中，應當弱化按鈕形式，重點強調功能，突出主體信息。
2. 下一步的明確指引
當頁面內容信息過多后，用戶容易失去信息焦點，從而忘記下一步操作。信息種類越多，用戶權衡的時間就會越久，用戶選擇罷手及跳出的幾率也會越大。所以這個時候，在合適的地方增添按鈕，能夠很好的引導用戶進行下一步操作，提升整體操作的成功率。其次從體驗層面，也一定程度能起到頁面動線的引導作用，比如下方的一組卡片，在增添了按鈕后行動點很明確，非常有點擊欲望~
3. 固定習慣，明確心理預期
當用戶知悉某個按鈕能指向某個操作，或者獲取某類信息后，長期以往用戶就會形成使用這個按鈕的習慣，這樣對提升復訪及固定心智是非常有效果。
所以如果你認為你負責的產品或者是內容，能持續為用戶帶來價值，那么在頁面的關鍵節點，不如將按鈕設計的更醒目。這樣用戶下次再看到這個按鈕時，固定習慣會引導他持續的點擊。
這里我不以按鈕的長相來區分按鈕的類型，如漢堡按鈕或者別的什么的，意義不大。我主要還是想通過以按鈕的功能區分，來劃分類型，這樣大家理解起來更為清晰。
1. 功能性質按鈕
這類按鈕見到的最多，我們常用的APP里，大量都充斥了這類按鈕，這類按鈕會起到重點的功能交互，幫助用戶得到TA想要的信息。其次樣式上面，其實圓形的點擊欲，會更強一些，看起來也更利于點擊。而方型的按鈕，則顯得更為正式、嚴謹。
公式：如果是圓形按鈕，圓角的半徑=高度的50%比較合適，而如果是方按鈕，邊角的小圓角半徑控制在15%以下比較合適，我個人喜好用10%。
2. 聚焦大按鈕
這類按鈕通常見于一些核心頁面的強指引，比如登錄、注冊、提交表單、或者是保存，等對頁面全局進行操作的一些按鈕。需要注意的是，這類按鈕只適合對頁面全局進行操作，而且頁面中大按鈕的數量不宜超過2個，信息盡量需要保持聚焦。
公式：基于@2x，這類大按鈕的高度≥72px是比較合適的，通常的尺寸有 80px、88px、96px，大家可以根據產品面向的人群來定高度，如果頁面面向的人群較為廣泛，我建議采用 88px 或者是 96px 的這種大號版本，畢竟操作起來更為方便。
3. 吸底按鈕
這類按鈕的優先級，在整個頁面屬于最高，頁面的所有信息，都將聚焦在這個按鈕中。由于按鈕是吸底的，所以會一直浮在頁面上，不受頁面篇幅影響控制。
需要注意的是，吸底按鈕一定是頁面最重要的功能，或者是整個頁面的下一步指引，比如淘寶的立即購買，或者是餓了么、美團的立即下單，又或者是常見的充值界面。
公式：基于@2x，吸底的高度≥80px是比較合適，常見的尺寸有88px、100px、112px ，按鈕的大小可以根據內容來定，建議高度保持在72px以上比較合適。這里需要注意的是，吸底的按鈕，需要產出兩套設計稿，一套為常規稿，一套為iPhoneX的適配稿。iPhoneX底部控件的區域高度為68px，所以iPhoneX設計稿的吸底高度=常規設計稿吸底高度+68px
另外在設計按鈕的時候，也別忘了補充按鈕的多個狀態的設計稿。常見的狀態，有以下四種：
1. Normal-正常態
這個為按鈕的正常顯示態，就是正常頁面中的顯示效果。
2. Hover-懸浮態
這個為按鈕的懸浮態，一般只會出現在使用鼠標的時候。當鼠標指針停留在按鈕時，按鈕發出的特殊反饋，則為懸浮態。這類形式在移動端交互中無作用，所以移動界面設計中不需要考慮這個狀態。
公式：正常情況 Hover 態增加 10% 黑色就可以，原理如下
3. Pressed-點擊態
這個為按鈕的按壓態，就是按鈕在被點擊或者是按壓后的效果。
公式：在APP設計中，點擊后的效果我們設一個標準值讓開發實現就好了。常用的值有按鈕減少20%的透明度，或者增添20%的暗度，這兩個都可以。通常我建議在亮色上的按鈕，使用暗度疊加（增添20%的黑色），在暗色上的按鈕，則使用透明度減少（透明度改為80%），實現效果原理參考 Hover 態那張配圖
4. Disable-禁用態
當信息未填充完整，或者是某類條件未到，按鈕會出現不可點擊的狀態，處于禁用形式，這個時候，按鈕就會呈現禁用態。這個禁用態無論是web還是app，很多場景都會用到，所以建議設定一套標準的設計規范，避免重復定義這個效果。
公式：禁用態尺寸及大小不變，僅使用色值做區分。建議使用灰色或者是不透明色，常用的禁用色有#CCC或者#999，需要盡可能把樣式做弱，避免用戶做無效的點擊。
在目前移動互聯網設計中，雖然按鈕的種類很多，但風格變的逐漸統一，更多都是色值及細節上的差異。從大的風格來看，按鈕還是分為這這幾種類型：扁平化、輕擬物、重擬物及游戲按鈕。
1. 扁平化按鈕
這類按鈕我們設計用的最多，信息簡潔，操作方便，形式追隨功能。這里也給大家分享一下我在設計扁平化按鈕的一些經驗，比如高度寬度，以及陰影的色值。
公式：按鈕高度，這個通常是文字字號的2.4倍然后取4的倍數整數，比如字號是24，那么按鈕的高度=57.6，離4倍數最近的是56，所以高度=56，圓角=10%的高度，取整后是6px。
另外如果覺得不合適，也可以單位往8遞增或者是遞減即可，例如 56、64、72、80、88 px
按鈕寬度：如果不是那種全局按鈕，通常按鈕的寬度=最多容納字數的寬度+按鈕高度，就好啦。還是以上面那個例子為例，按鈕高度=56，文字寬度=96，那么按鈕的寬度=56+96=152
2. 輕擬物按鈕
這類按鈕近幾年變的非常流行，甚至QQ、淘寶，都開始大面積使用，因為這類按鈕在保持信息簡潔的同時，仍然有較強的點擊欲，視覺上面也能夠增添頁面的品質感。
公式：漸變方向，建議采用水平漸變，重色在右側，輕色在左側更為合適。陰影色值我之前就寫過，不知道大家還記得么，陰影顏色=按鈕顏色的 Alpha50%，x=0，y=按鈕高度的20%，模糊值=按鈕高度的50%，擴展=按鈕高度的 -15%，高級又簡單，完美！
如果覺得這個彌散陰影太大的同學，也可以自己手動簡單調整下，不礙事。（這個公式僅適用于Sketch，用PS的同學，也可以按照這個邏輯自行研究一下）
另外說一句，實際上這個陰影公式并沒有什么很多的依據，大多數都是我個人原創總結出來的，簡單好用。比如下面的這些按鈕的樣式，用了公式后的效果大家可以自行感受~
3. 重擬物及游戲按鈕
在一些營銷頁面中，按鈕的樣式通常需要做的比較游戲化。游戲化的按鈕，大部分會采取游戲場景中的元素，再采用擬物的手法，來進行打造。
通常游戲化的按鈕，需要重點幾個部分組成，學過素描的同學應該會知道，立體的物體，通常會有幾大特征，分別為高光，亮部，暗部，投影及反光。那么如果我們需要繪制一個在營銷或者游戲場景中使用的按鈕，只需要保證這個按鈕有高光，亮部，暗部，投影及反光的這些特征，然后飽滿一點就，立馬就可以出效果啦。
當然，我舉的這幾個例子都是最基礎版本，如果你想做的更豐富一些，那也是沒問題的，這個可以case by case 來定。
這個沒有太多的公式可以總結，更多的是看設計師的基礎美術水平啦~~
在寫這篇文章的時候，突然刷到了一套新擬態的控件設計風格，有種眼前一亮的感覺。雖然這套設計視覺上很有層次很好看，不過感覺短時間之內，比較難大面積推廣，因為開發實現起來還是會比較耗費成本。
我把源文件保存下來了，對這個感興趣或者好奇這種效果如何實現的同學，可以下載源文件研究~~ sketch、psd、Figma 格式都有。
文章來源：優設 作者：UX小學
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
| 章節名稱 | 地址 |
|---|---|
| Vue.js教程-安裝和HelloWorld | https://coderhqf.blog.csdn.net/article/details/107574556 |
| Vue.js教程-Vue項目的目錄結構和.vue文件的構成 | https://coderhqf.blog.csdn.net/article/details/107621070 |
| Vue.js教程-Vue基本指令 | https://coderhqf.blog.csdn.net/article/details/107677588 |
| Vue.js教程-組件化開發 | https://coderhqf.blog.csdn.net/article/details/107783664 |
版權聲明：本文為博主原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接和本聲明。
與傳統PC桌面不同，手機屏幕的尺寸更加小巧操作，方式也已觸控為主，APP界面設計不但要保證APP功能的完整性和合理性，又要保證APP的功能性和實用性，在保證其擁有流暢的操作感受的同時，滿足人們的審美需求。
接下來為大家介紹幾款手機appui界面設計
--手機appUI設計--
--手機appUI設計--
--手機appUI設計--
--手機appUI設計--
--手機appUI設計--
--手機appUI設計--
--手機appUI設計--
--手機appUI設計--
--手機appUI設計--
--手機appUI設計--
--手機appUI設計--
（以上圖片均來源于網絡）
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
更多精彩文章：
還記得2019年4月上映的復仇者聯盟4么，漫威電影宇宙的第三階段結束了，電影很精彩，但最令人震撼的是先導版的電影海報！就是那個「五彩斑斕」的黑～
從設計上看，海報的設計師是把光運用到極限了，通過逆光和環境塑造出了酷+神秘的視覺感受。光是一切視覺表現的基礎，是構圖和傳遞調性的關鍵，也是視覺表現重要的組成部分。所以今天就和大家聊聊啥樣的光是一個牛X的光以及如何塑造一個合格的光影？
常見形式1-聚光
△ 圖片來源：小米米家臺燈1S
聚光是最常見光，也是在設計中用到最多的光，通常在塑造一個物體的時候就會用的到。
因為聚光的原因，場景更像個舞臺，凸顯「主角」的存在。具體的原理可以根據下圖去理解。
常見形式2-自然光
自然光其實就是陽光，理論上講其實光源是太陽也是聚光，但由于光源太過于龐大，無法真正的聚焦，所以就把這種光當成一種泛光源就好。在產品設計中也會經?？吹筋愃频墓庠闯霈F，比如行為召喚按鈕：
因為不需要強有力的表現和氛圍的營造，所以通常產品設計中更需要自然光來作為核心光源，通過泛光源去統一控制產品的光影體系就好（發布的 Mac OS – big Sur 的整體光源同樣是自然光，下文會講到）。
常見形式3-逆光
坦誠的講逆光也是聚光的一種，只不過由于角度特殊，呈現的視覺效果也非常不一樣，所以就單獨把逆光拿出來說一說。當畫面需要逆光來營造氛圍的時候，只需要在固有色上加上黑色蒙板和邊緣的高光就可以大概塑造出一個處于逆光的物體了。
小米是典型的逆光氛圍營造高手，但萬變不離其宗，依舊可以從海報里看到相同的方法。
△ 圖片來源：小米傳播物料
通?，F實中的光源并非那么理想，光線的復雜超出肉眼所見。所以我們在繪制的過程需要注意到，可以適當的抽象。舉個例子，自然光是普照的，所以我們抽象為四個小光源平均分布，依次打到物體上：
在他們疊加的部分可以清晰的看到，1是最重的，2其次，3再次。按照這個辦法就可以獲得光影的層級關系，在繪制輕擬態的圖標或者運營活動中更加細膩。
△ 圖片來源：09UI設計工作室-陌陌直播禮物設計
所有的光影其實都是幫助主體塑造體積感，一個合格的立體圖形必須具備：高光/過度色/明暗交界線和反光這四個基本屬性。
然后需要一點超現實主義的手法，把太陽光過濾下，從「赤橙黃綠青藍紫」的色調里提取跟主體和諧的顏色（通常是補色），營造出介于真實與玄幻之間的美妙效果hiahia～
然后再在投影上加一點點色彩傾向，一個完美的黑八就出現啦～按照這種方法，你可以試著去嘗試更多的物體/場景。（下圖是筆者作品「插著紅旗的地球」hiahia）
影響主體的除了光影之外就是材質了，近年來的三大巨頭apple/Microsoft/Google的設計都在材質上下足了功夫，蘋果的毛玻璃，微軟的亞克力和谷歌的「紙」。
從趨勢上看，材質的引入對產品中拉開層級關系上有巨大意義，以往的設計僅僅是通過光影和焦距來拉開關系，這兩個維度在少量的疊加界面中還能有效果，但到了復雜的多窗口互壓互疊里就不是那么奏效了，所以鐵子們要善于運用材質區分產品顯示的優先級。
△ 圖片來源：Eric Hoffman – Big Sur Mac Icons
△ 圖片來源：JIAJIE – WeSing Live gift
圖標好壞除了造型之外最重要的就是質感了，通常圖標也就是4種形式（如下圖），類似蘋果的系統圖標和抖音直播間禮物的圖標都是最后一種形式。
但如果僅僅是這樣就太水了，既然都說了是干貨預警，那就要拿出哥們看家的本領～此圖是大家關注公號后就會收到的推圖，主體就是一個POI的圖標加上微信的對話框和代表干貨的小星星營造出的氛圍。
刨析下這個圖，三個發光體和底下的投影，通過上文的講解依次繪制完成～
之后就到了amazing的時刻了，打開photoshop找到「濾鏡-模糊畫廊-場景模糊」設置幾個key-point，調試模糊值和透明度/亮度，最終完成對光影的塑造。
空氣中的灰塵相信大家都不陌生，這種情況多數是一束光影從窗戶里射入后，在光的折射下把平時看不到的灰塵統統照了個遍。
如果你是mac用戶一定熟知keynote里的動畫效果「轟然墜落」，這個效果是在模擬物體振動后彈開周圍灰塵，非常震撼。在PPT的設計中你也可以同樣借助光和霧來營造你想要的效果，下圖是我在做工作總結的時候為了凸顯Q4工作采用的辦法。
光影輕擬物在產品設計中的應用面還是很廣的，比如：圖標、數據可視化、插圖等等。而在大量扁平設計時代適量使用會顯得很出彩，當然再好的教程也比不上大家多動手試試練練，所以鐵汁們行動起來咯~
文章來源：優設 作者：Nana的設計錦囊
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
JavaScript 語言中的 for 循環用于多次執行代碼塊，它是 JavaScript 中最常用的一個循環工具，還可用于數組的遍歷循環等。
我們為什么要使用 for 循環呢？打個比方，例如我們想要控制臺輸出1到1000之間的所有數字，如果單寫輸出語句，要寫1000句代碼，但是如果使用 for 循環，幾句代碼就能實現?？傊?，使用 for 循環能夠讓我們寫代碼更方便快捷（當然啦，否則要它干嘛）。
for 循環語法
語法如下所示：
for(變量初始化; 條件表達式; 變量更新) {
// 條件表達式為true時執行的語句塊
}
變量初始化，表示代碼塊開始前執行。
條件表達式，定義運行循環代碼塊的條件。
變量更新，在循環代碼塊每次被執行之后再執行。
示例：
例如我們在一個HTML文件中，編寫如下代碼，實現計算1到100的總和：
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>JS_俠課島(9xkd.com)</title>
</head>
<body>
<script>
var result = 0;
for(var i = 1; i <= 100; i++) {
result = result + i;
}
alert(result);
</script>
</body>
</html>
在瀏覽器中打開這個文件，會彈出一個彈出層，彈出層中顯示的是1到100的總和：
上述代碼中，我們聲明了一個變量 result 并給它賦值為 0，表示初始的總和為 0 。
然后在 for 循環中三個語句：
變量初始化 i = 1，表示從 1 開始計算。
條件表達式 i <= 100，表示只要 i 小于等于 100 循環就會一直執行，當 i 大于 100 循環會停止。
變量更新 i++，之前我們學運算符的時候學過，這是遞增運算符 ++，表示為其操作數增加 1。
此時我們可以一點點來看這個 for 循環：
第一次循環： result = 0 + 1 // 此時result值為0， i的值為1
第二次循環： result = 1 + 2 // 此時result值為0+1，i的值為2
第三次循環： result = 3 + 3 // 此時result值為1+2，i的值為3
第四次循環： result = 6 + 4 // 此時result值為3+3，i的值為4
第五次循環： result = 10 + 5 // 此時result值為6+4，i的值為5
...
我們只需要搞清楚 for 循環中的執行原理，不需要手動來計算求和，只要寫好代碼，執行代碼后計算機會很快會告訴我們1到 100 的總和。
再補充一下，上述代碼中result = result + i，我們也可以寫成 result += i，這是我們之前學過的加賦值運算符，還記得嗎？
示例：
再來看一個例子，例如我們可以使用 for 循環來實現數組遍歷，首先定義一個數組 lst：
var lst = ["a", "b", "c", "d", "e"];
在寫 for 循環時，首先就是要搞清楚小括號里面的三個語句，因為我們可以通過數組中元素的下標索引來獲取元素的值，而數組的索引又是從 0 開始，所以變量初始化可以設置為i = 0。第二個條件表達式，因為數組中最后一個索引為 lst.length - 1，所以只要小于等于 lst.length - 1，循環就會一直執行。而i <= lst.length - 1 就相當于 i<lst.length。第三個變量更新，當循環每循環一次，索引值就加一，所以為 i++。
所以循環可以像下面這樣寫：
for(i = 0; i<lst.length; i++){
console.log(lst[i]); // 輸出數組中的元素值，從索引為0的值開始輸出，每次加1，一直到lst.length-1
}
輸出：
a
b
c
d
e
其實遍歷數組還有一種更好的方法，就是使用 for...in 循環語句來遍歷數組。
for...in 循環
for...in 循環主要用于遍歷數組或對象屬性，對數組或對象的屬性進行循環操作。for...in 循環中的代碼每執行一次，就會對數組的元素或者對象的屬性進行一次操作。
語法如下：
for (變量 in 對象) {
// 代碼塊
}
for 循環括號內的變量是用來指定變量，指定的可以是數組對象或者是對象屬性。
示例：
使用 for...in 循環遍歷我們定義好的 lst 數組：
var lst = ["a", "b", "c", "d", "e"];
for(var l in lst){
console.log(lst[l]);
}
輸出：
a
b
c
d
e
除了數組，for...in 循環還可以遍歷對象，例如我們遍歷 俠俠 的個人基本信息：
var object = {
姓名:'俠俠',
年齡:'22',
性別:'男',
出生日期:'1997-08-05',
職業:'程序員',
特長:'跳舞'
}
for(var i in object) {
console.log(i + ":" + object[i]);
}
輸出：
姓名: 俠俠
年齡: 22
性別: 男
出生日期: 1997-08-05
職業:程序員
特長:跳舞
動手小練習
請自定義一個長度為7的數組，然后通過 for 循環將數組中的元素遍歷出來。
求和：1~100的奇數和。
求和：1~100的偶數和。
使用對象定義一個人的個人信息（包括姓名、性別、年齡、出生日期、興趣愛好、職業、特長等），然后使用 for...in 循環將這些信息遍歷輸出。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
表格需求
一般管理系統對表格會有以下需求
可以分頁（需要有分頁條）
可以多選（表格帶復選框）
頂部需要加一些操作按鈕（新增，刪除等等）
表格每行行尾有操作按鈕
表格行可以編輯
如下圖為一個示例表格
如果我們直接使用element-ui提供的組件的話，那么開發一個這樣的表格就需要使用到以下內容
需要使用表格的插槽功能，開發每一行的按鈕
需要通過樣式調整頂部按鈕，表格，分頁條的布局樣式
需要監聽分頁的事件然后去刷新表格數據
頂部按鈕或操作按鈕如果需要獲取表格數據，需要調用表格提供的api
對于有行編輯的需求，還需要通過插槽去渲染行編輯的內容，同時要控制行編輯的開關
不僅僅開發表格比較麻煩，而且還要考慮團隊協作，如果每個人實現表格的方式存在差別，那么可能后期的維護成本也會變得很高。那怎么辦呢？
項目安裝
安裝插件
在使用element-ui的項目中，可以通過以下命令進行安裝
npm install vue-elementui-table -S
在項目中使用
在main.js中添加以下代碼
import ZjTable from 'vue-element-table'
Vue.use(ZjTable)
然后即可像下文中的使用方式進行使用
表格配置
為了滿足團隊快速開發的需要，小編對上面提出來的需求進行了封裝，然后使用的時候，開發人員只需要配置一些JSON便可以完成以上功能的開發。
基礎配置
一個基礎的表格包含了數據和列信息，那么如何用封裝的表格去配置呢？
<template>
<zj-table
:columns="columns"
:data="data"
:pagination="false"
/>
</template>
<script>
export default {
data() {
return {
// 表格的列信息, 數組每一項代表一個字段，可以使用element 列屬性的所有屬性，以下僅為示例
columns: Object.freeze([
{
// 表頭顯示的文字
label: '姓名',
// 對應數據里面的字段
prop: 'name'
},
{
label: '性別',
prop: 'sex',
// 格式化表格,與element-ui 的表格屬性相同
formatter(row, column, cellValue) {
return cellValue === 1 ? '男' : '女'
}
},
{
label: '年齡',
prop: 'age'
}
]),
data: [
{
name: '子君',
sex: 1,
age: 18
}
]
}
}
}
</script>
通過上面的配置，就可以完成一個基礎表格的開發，完整代碼見 https://github.com/snowzijun/vue-element-table/blob/master/example/views/demo/base.vue，效果如下圖所示
表格默認會顯示復選框，也可以通過配置selectable屬性來關閉掉
添加分頁
簡單的表格用封裝之后的或未封裝的開發工作量區別并不大，我們繼續為表格添加上分頁
<template>
<!--
current-page.sync 表示頁碼, 添加上 .sync 在頁碼發生變化時自動同步頁碼
page-size.sync 每頁條數
total 總條數
height="auto" 配置height:auto, 表格高度會根據內容自動調整，如果不指定，表格將保持充滿父容器，同時表頭會固定，不跟隨滾動條滾動
@page-change 無論pageSize currentPage 哪一個變化，都會觸發這個事件
-->
<zj-table
v-loading="loading"
:columns="columns"
:data="data"
:current-page.sync="currentPage"
:page-size.sync="pageSize"
:total="total"
height="auto"
@page-change="$_handlePageChange"
/>
</template>
<script>
export default {
data() {
return {
columns: Object.freeze([
// 列字段與上例一樣，此處省略
]),
data: [],
// 當前頁碼
currentPage: 1,
// 每頁條數
pageSize: 10,
// 總條數
total: 0,
// 是否顯示loading
loading: false
}
},
created() {
this.loadData()
},
methods: {
// 加載表格數據
loadData() {
this.loading = true
setTimeout(() => {
// 假設總條數是40條
this.total = 40
const { currentPage, pageSize } = this
// 模擬數據請求獲取數據
this.data = new Array(pageSize).fill({}).map((item, index) => {
return {
name: `子君${currentPage + (index + 1) * 10}`,
sex: Math.random() > 0.5 ? 1 : 0,
age: Math.floor(Math.random() * 100)
}
})
this.loading = false
}, 1000)
},
$_handlePageChange() {
// 因為上面設置屬性指定了.sync,所以這兩個屬性會自動變化
console.log(this.pageSize, this.currentPage)
// 分頁發生變化，重新請求數據
this.loadData()
}
}
}
</script>
完整代碼請參考 https://github.com/snowzijun/vue-element-table/blob/master/example/views/demo/pagination.vue
通過封裝，表格將自帶分頁功能,通過上面代碼，實現效果如下所示,是不是變得簡單了一些。接下來我們繼續給表格添加按鈕
添加頂部按鈕
表格上面可能會有新增，刪除等等按鈕，怎么辦呢，接下來我們繼續通過配置去添加按鈕
<template>
<zj-table
:buttons="buttons"
/>
</template>
<script>
export default {
data() {
return {
buttons: Object.freeze([
{
// id 必須有而且是在當前按鈕數組里面是唯一的
id: 'add',
text: '新增',
type: 'primary',
icon: 'el-icon-circle-plus',
click: this.$_handleAdd
},
{
id: 'delete',
text: '刪除',
// rows 是表格選中的行，如果沒有選中行，則禁用刪除按鈕, disabled可以是一個boolean值或者函數
disabled: rows => !rows.length,
click: this.$_handleRemove
},
{
id: 'auth',
text: '這個按鈕根據權限顯示',
// 可以通過返回 true/false來控制按鈕是否顯示
before: (/** rows */) => {
return true
}
},
// 可以配置下拉按鈕哦
{
id: 'dropdown',
text: '下拉按鈕',
children: [
{
id: 'moveUp',
text: '上移',
icon: 'el-icon-arrow-up',
click: () => {
console.log('上移')
}
},
{
id: 'moveDown',
text: '下移',
icon: 'el-icon-arrow-down',
disabled: rows => !rows.length,
click: () => {
console.log('下移')
}
}
]
}
])
}
},
created() {},
methods: {
// 新增
$_handleAdd() {
this.$alert('點擊了新增按鈕')
},
// 頂部按鈕會自動將表格所選的行傳出來
$_handleRemove(rows) {
const ids = rows.map(({ id }) => id)
this.$alert(`要刪除的行id為${ids.join(',')}`)
},
// 關注作者公眾號
$_handleFollowAuthor() {}
}
}
</script>
表格頂部可以添加普通的按鈕，也可以添加下拉按鈕，同時還可以通過before來配置按鈕是否顯示，disabled來配置按鈕是否禁用，上面完整代碼見 https://github.com/snowzijun/vue-element-table/blob/master/example/views/demo/button.vue
通過上面的代碼就可以配置出下面的表格,是不是很簡單呢？
表格頂部可以有按鈕，行尾也是可以添加按鈕的，一起來看看
行操作按鈕
一般我們會將一些單行操作的按鈕放在行尾，比如編輯，下載等按鈕，那如何給行尾配置按鈕呢?
<template>
<zj-table
:columns="columns"
/>
</template>
<script>
export default {
data() {
return {
columns: Object.freeze([
{
// 可以指定列的寬度，與element-ui原生用法一致
width: 220,
label: '姓名',
prop: 'name'
},
// 行編輯按鈕，在表格末尾出現，自動鎖定右側
{
width: 180,
label: '操作',
// 通過 actions 指定行尾按鈕
actions: [
{
id: 'follow',
text: '關注作者',
click: this.$_handleFollowAuthor
},
{
id: 'edit',
text: '編輯',
// 可以通過before控制按鈕是否顯示，比如下面年齡四十歲的才會顯示編輯按鈕
before(row) {
return row.age < 40
},
click: this.$_handleEdit
},
{
id: 'delete',
text: '刪除',
icon: 'el-icon-delete',
disabled(row) {
return row.sex === 0
},
// 為了拿到this,這里需要用箭頭函數
click: () => {
this.$alert('女生被禁止刪除了')
}
}
]
}
])
}
},
methods: {
// 關注作者公眾號
$_handleFollowAuthor() {
console.log('微信搜索【前端有的玩】，這是對小編最大的支持')
},
/**
* row 這一行的數據
*/
$_handleEdit(row, column) {
this.$alert(`點擊了姓名為【${row.name}】的行上的按鈕`)
}
}
}
</script>
行操作按鈕會被凍結到表格最右側，不會跟隨滾動條滾動而滾動，上面完整代碼見, https://github.com/snowzijun/vue-element-table/blob/master/example/views/demo/button.vue
通過上面的代碼就可以完成以下效果
最后再來一起看看行編輯
行編輯
比如上例，我希望點擊行尾的編輯按鈕的時候，可以直接在行上面編輯用戶的姓名與性別，如何配置呢?
<template>
<zj-table
ref="table"
:columns="columns"
:data="data"
/>
</template>
<script>
export default {
data() {
return {
columns: Object.freeze([
{
label: '姓名',
prop: 'name',
editable: true,
field: {
componentType: 'input',
rules: [
{
required: true,
message: '請輸入姓名'
}
]
}
},
{
label: '性別',
prop: 'sex',
// 格式化表格,與element-ui 的表格屬性相同
formatter(row, column, cellValue) {
return cellValue === '1' ? '男' : '女'
},
editable: true,
field: {
componentType: 'select',
options: [
{
label: '男',
value: '1'
},
{
label: '女',
value: '0'
}
]
}
},
{
label: '年齡',
prop: 'age',
editable: true,
field: {
componentType: 'number'
}
},
{
label: '操作',
actions: [
{
id: 'edit',
text: '編輯',
// 如果當前行啟用了編輯，則不顯示編輯按鈕
before: row => {
return !this.editIds.includes(row.id)
},
click: this.$_handleEdit
},
{
id: 'save',
text: '保存',
// 如果當前行啟用了編輯，則顯示保存按鈕
before: row => {
return this.editIds.includes(row.id)
},
click: this.$_handleSave
}
]
}
]),
data: [
{
// 行編輯必須指定rowKey字段，默認是id,如果修改為其他字段，需要給表格指定row-key="字段名"
id: '0',
name: '子君',
sex: '1',
age: 18
},
{
// 行編輯必須指定rowKey字段，默認是id,如果修改為其他字段，需要給表格指定row-key="字段名"
id: '1',
name: '子君1',
sex: '0',
age: 18
}
],
editIds: []
}
},
methods: {
$_handleEdit(row) {
// 通過調用 startEditRow 可以開啟行編輯
this.$refs.table.startEditRow(row.id)
// 記錄開啟了行編輯的id
this.editIds.push(row.id)
},
$_handleSave(row) {
// 點擊保存的時候，通過endEditRow 結束行編輯
this.$refs.table.endEditRow(row.id, (valid, result, oldRow) => {
// 如果有表單驗證，則valid會返回是否驗證成功
if (valid) {
console.log('修改之后的數據', result)
console.log('原始數據', oldRow)
const index = this.editIds.findIndex(item => item === row.id)
this.editIds.splice(index, 1)
} else {
// 如果校驗失敗，則返回校驗的第一個輸入框的異常信息
console.log(result)
this.$message.error(result.message)
}
})
}
}
}
</script>
不需要使用插槽就可以完成行編輯，是不是很開心。上述完整代碼見 https://github.com/snowzijun/vue-element-table/blob/master/example/views/demo/row-edit.vue
效果如下圖所示:
其他功能
除了上面的功能之外，表格還可以配置其他許多功能，比如
可以指定字段為鏈接列，需要給列配置link屬性
可以通過插槽自定義頂部按鈕，行操作按鈕，行字段等
可以在按鈕區域右側通過插槽配置其他內容
其他等等
表格開發說明
通過上面的代碼示例，我們已經知道了封裝之后的表格可以完成哪些事情，接下來一起來看看表格是如何實現的。完整代碼見 https://github.com/snowzijun/vue-element-table/tree/master/src/components/zj-table
表格布局
整個表格是通過JSX來封裝的，因為JSX使用起來更加靈活。對于我們封裝的表格，我們從豎向可以分為三部分，分別是頂部按鈕區，中間表格區，底部分頁區，如何去實現三個區域的布局呢，核心代碼如下
render(h) {
// 按鈕區域
const toolbar = this.$_renderToolbar(h)
// 表格區域
const table = this.$_renderTable(h)
// 分頁區域
const page = this.$_renderPage(h)
return (
<div class="zj-table" style={{ height: this.tableContainerHeight }}>
{toolbar}
{table}
{page}
</div>
)
}
通過三個render函數分別渲染對應區域，然后將三個區域組合在一起。
渲染表格列
通過前文的講解,我們可以將表格的列分為以下幾種
常規列
行編輯列
操作按鈕列
插槽列
鏈接列(文檔后續完善)
嵌套列(文檔后續完善)
$_renderColumns(h, columns) {
// 整體是否排序
let sortable = this.sortable ? 'custom' : false
return columns
.filter(column => {
const { hidden } = column
if (hidden !== undefined) {
if (typeof hidden === 'function') {
return hidden({
columns,
column
})
}
return hidden
}
return true
})
.map(column => {
const {
useSlot = false,
// 如果存在操作按鈕，則actions為非空數組
actions = [],
// 是否可編輯列， 對于可編輯列需要動態啟用編輯
editable = false,
// 是否有嵌套列
nests,
// 是否可點擊
link = false
} = column
let newSortable = sortable
if (column.sortable !== undefined) {
newSortable = column.sortable ? 'custom' : false
}
column = {
...column,
sortable: newSortable
}
if (nests && nests.length) {
// 使用嵌套列
return this.$_renderNestColumn(h, column)
} else if (editable) {
// 使用編輯列
return this.$_renderEditColumn(h, column)
} else if (useSlot) {
// 使用插槽列
return this.$_renderSlotColumn(h, column)
} else if (actions && actions.length > 0) {
// 使用操作列
column.sortable = false
return this.$_renderActionColumn(h, column)
} else if (link) {
// 使用鏈接列
return this.$_renderLinkColumn(h, column)
} else {
// 使用默認列
return this.$_renderDefaultColumn(h, column)
}
})
},
行編輯列
當前表格行編輯支持input,select,datepicker,TimeSelect,InputNumber等組件，具體渲染代碼如下所示
// 編輯單元格
$_renderEditCell(h, field) {
const components = {
input: Input,
select: ZjSelect,
date: DatePicker,
time: TimeSelect,
number: InputNumber
}
const componentType = field.componentType
const component = components[componentType]
if (component) {
return this.$_renderField(h, field, component)
} else if (componentType === 'custom') {
// 如果自定義，可以通過component指定組件
return this.$_renderField(h, field, field.component)
}
return this.$_renderField(h, field, Input)
},
$_renderField(h, field, Component) {
// 編輯行的id字段
const { rowId, events = {}, nativeEvents = {} } = field
const getEvents = events => {
const newEvents = {}
Object.keys(events).forEach(key => {
const event = events[key]
newEvents[key] = (...rest) => {
const args = [
...rest,
{
rowId,
row: this.editRowsData[rowId],
value: this.editRowsData[rowId][field.prop]
}
]
return event(...args)
}
})
return newEvents
}
// 事件改寫
const newEvents = getEvents(events)
const newNativeEvents = getEvents(nativeEvents)
return (
<Component
size="small"
on={newEvents}
nativeOn={newNativeEvents}
v-model={this.editRowsData[rowId][field.prop]}
{...{
attrs: field,
props: field
}}
/>
)
}
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
配色，設計師的世紀難題。從平面到屏幕，CMYK 到 RGB，墨點到像素，色彩越來越豐富，形式越來越復雜。UI 的發展從擬物的繁瑣細節中掙脫出來，卻在色彩的展現中放飛了自我。
零售業有個有趣的研究成果 —— 「七秒鐘定律」：人們在挑選商品和服務時 ，只需要 7 秒鐘就可以確定是否感興趣，而在這短暫的 7 秒鐘內，色彩的作用占到了 67%。
要在小小的手機屏幕中加入這么多顏色，并保持其中的聯系和邏輯，著實不易。如果你還對配色一無所知，完全不知道配色應該怎么入手，那么你需要了解一下，我幾年經驗總結的配色思路。
無論我們用 PS、AI，還是 Sketch、XD、Figma，和色彩打交道最多的地方就是拾色器窗口，我們來看看這些案例：
雖然是不同的應用，但是這個拾色器的用法大同小異，但是，很多新人并沒有搞懂拾色器的正確應用邏輯。
很多人知道，UI 的色彩使用 RGB 模式，但是拾色器主要的選色原理遵循的是 HSB 模式的邏輯，也就是色相（H）、飽和度（S）、明度（B）。
HSB 是色彩科學中對所有顏色屬性的理論劃分，是種概念上的定義，可以用來解釋任何色彩，也就是說可以和 RGB 和 CMYK 相互轉化，且 HSB 的選色邏輯更清晰、簡潔、干練。
因為一個正確的選色過程，是先確定出色相，然后再在這個色相維度下選出明度和飽和度，所以我們首先要關注色相選擇條。
細心的同學應該已經發現了，它們的首尾都是紅色，那是因為色相的序列是一個首尾相接的環形模式，所以它實際上就是色環的柱狀展示圖，應用起來和色環沒有實際區別。
接下來就要說到重點，飽和度和明度選擇區，我自己使用的習慣，是將這個選擇區通過黃金三分法的方式切割成等比的 9 個區域，然后明確它們在 UI 中的對應情緒和應用場景。
在過去的大量分析中，互聯網產品的主色和重要輔助色都會往右上角聚集，一些次要、不可點的色彩聚集在中上方，而文字背景色則聚集在左側，無人區則是我們重點避開的對象。
下面我們分析幾個案例，看看它們在這個選擇區中的色彩分布情況：
大家也可以自己拿一些主流的應用做截圖，然后把它們的 UI 元素色彩排列到拾色面板中，就會得到基本一致的結果。牢記這9個區域的場景劃分，可以幫助我們非常、安全地完成 UI 配色。
在眾多的 UI 設計規范中，色彩部分的介紹，都必然包含三種類型，分別是：
1. 主色的選擇
主色是一個應用的最核心的色彩，品牌的象征色，比如想到餓了么的藍色、微信的綠色、京東的紅色、淘寶的橙色。
確定主色，并沒有大家想象的那么復雜，它的要點在于——你想讓用戶感受到哪種情緒，然后通過情緒關聯一個大致的色彩范圍，再進行微調。
在今天的互聯網產品中，主色的應用選擇范圍在拾色器區域的右上角，前面已經有解釋了。這和平面設計中的用色有非常大的不同。
移動端產品要在一個方寸大的空間中爭奪用戶的注意力，引起用戶的興趣，那么低飽和清淡的色調是無法實現這個目標的，所以今天主色飽和度越來越，比如我們之前整理的一篇總結：
為什么支付寶要換 Logo 顏色？分析下目前 Logo 的主色趨勢
再加上屏幕的 RGB 顯示特性，高對比度，高動態范圍的特質能給用戶提供更好的觀感。所以選擇主色最安全的做法，就是在確定色相類型后，在右上方區域選出合適的色值。
2. 輔助色的選擇
輔助色是豐富應用中的次要色彩，它會包含一到若干個和主色不同的色彩，除了品牌傳達外，具有更強的實用性。
前面我們提到過色環，這里就要派上用場了。我們知道色環是個色彩序列首尾相連的環形模型，它蘊含一個最樸素的原則，即兩個顏色在這個環形中角度越大，那么視覺差異性越大，對比越強，比如下圖的展示：
這些配色的模式是不能閉著眼隨便挑的，它們僅僅作為一個色彩對比度的判斷標準。而真正輔助色的選擇，是根據實際場景的功能決定的。
比如通知、提醒、取消用大紅色，確認、同意用綠色或者藍色，收藏、打分、評價用橙黃色。都是已經在用戶心智中建立了標準的用色類型，跟著常規方法來做，是沒有其它思路的情況下最簡單、最安全的輔助色選擇方式。
沒有標準元素用色的情況下，再考慮應用色環的 「角度原則」，越需要被突出的顏色，可以在色環中離主色越遠，越不需要被突出的則越近。
比如下方攜程的案例，主色在藍色的情況下，支付、保險金標簽這些需要被重點突出的色彩，使用了主色的互補色， 讓我們一眼就能看見并產生強烈的操作欲望。
3. 中性色的選擇
中性色，是頁面中文字、背景用到的顏色，它們承擔起最基本的層次表現、便于閱讀的重任。多數新手覺得中性色無關緊要，實際情況恰恰相反。
主色輔助色決定了界面視覺是否出彩，而中性色的應用直接決定了頁面能不能正常使用。如果看過比較多的原型案例，就應該明白，即使只有黑白灰的狀態下，我們理解這些頁面和進行使用也不會有絲毫的障礙。
中性色的配置，就是制定一個由深到淺的灰度階梯，應用在對應權重的元素上，色彩輕重的主要判斷依據是 HSB 中的 B（明度） 值。
中性色雖然指的是無個性，但并不是只能用純灰色，常見的一種做法，就是為中性色添加適量的藍色飽和度，提升觀看體驗（滿足RGB的某種特性）。
這種做法，顏色越淺的時候飽和度應用色值就越低，將這個規律在拾色器中進行表現，那么我們就可以得到一個 L 型曲線，我稱它為 「中性曲線」。
掌握對于主色、輔助色、中性色的選擇方法，那么對于UI配色的奧義來說，你已經掌握了一半，接下來就要了解更具體的實踐思路了。
配色并不是只有色彩的色值本身，大家一直在研究各種色彩心理學和理論，卻很少關心它們如何應用，如何配置。
所以，我根據主色和輔助色應用總結了一個配色的四象限表格，再分別看看它們對應的案例：
1. 主色占比大，色彩豐富度高
主色會作為頂部標題欄或其它重要模塊中的背景色，進行大面積應用，加深用戶對品牌的認知和辨識度。而產品中又包含了大量功能和服務，需要用豐富的色彩來進行暗示，吸引用戶關注。
2. 主色占比大，色彩豐富度低
這類配色中，主色的應用占比也大，出現頻率高，鮮有其它顏色出現。比較適用于圖片內容豐富的題材中，或者是相對正式、品牌感強的應用。
3. 主色占比小，色彩豐富度高
這是多數主流應用的趨勢，降低主色占比，留出更多的空間給內容模塊的展示上，突出自身帶有的服務和功能。
4. 主色占比小，色彩豐富度低
通常，會應用這種方式是因為產品的服務是相對單一，但也需要用戶投入注意力的應用，設計師就會盡力避免給予用戶過多的干擾。
每次在進行配色的時候，我們都需要對自己要應用哪種配色應用方式做出規劃，然后再動手執行。有了這個目標，后面在整個項目的設計中的配色步驟就是水到渠成的事情了。
在實踐前，我們要簡單講講一個應用或者界面的標準配色的流程了，流程順序如下：
具體應該怎么使用這套流程，我們用一個圖蟲APP改版的案例來做演示，首先從四象限中的第一個主色占比高、色彩豐富度高的類型做起。
1. 配色流程演示
原型是 UI 設計的基本藝能了，在開始具體設計、配色前，搭建頁面的框架原型是一個必備的條件，下面，是我們已經準備好的原型案例。
然后，我們確定以橙色作為應用主色，并在拾色器中進行確認。
有了主色，就可以對頁面進行色彩填充和圖片填充了。既然我們主色是占比大的，那么首先可以用到的就是頂部標題欄的背景色了，以及底部 Tabbar 中的選中色，大按鈕色等。
接著，我們開始整理中性色的使用，選擇新的顏色來填充文字和背景，清晰的表現模塊層級，文字信息的權重。
最后，就是添加輔助色和其它色彩的元素了，這個步驟建議都是放在最后一步操作。因為色彩越豐富，越難控制，容易讓整個畫面顯得雜亂無序，所以先完成基礎搭建，可以更好的幫助我們判斷彩色的使用是否合理。
下面，我們使用彩色的金剛區圖標，然后將用戶關注、認證用戶、標簽等元素使用其它色彩，來豐富頁面的色彩內容。
2. 其他配色類型應用
根據第一個方案，我們可以再用這個原型來實現其余的三個方案的配色。
比如下面的主色占比大，但是色彩豐富度低的。因為已經不太適用其它輔助色，所以主色填充上我們不再填充頂部導航欄的背景，而是將更多元素應用主色，減少輔助色數量。
然后是主色占比小，色彩豐富度高的方案，進一步降低主色應用的比例，然后在金剛區、標簽等處使用較為豐富的配色。
最后，就是主色占比小，色彩豐富性也低的方案，那么使用中性色的元素就開始增多，只保留最核心的一些元素使用主色，和極少的輔助色。
根據四種不同的配色方案，我們就可以得到四種不同的配色結果和風格，在每次設計開始實施前，我們都可以根據這種做法來做嘗試，并選出自己滿意的方案。
要再次強調，UI 配色是極其強調形式的應用科學，最后做的往往會和一開始想的效果有極大出入，所以需要我們有幾個備選方案，可以隨時進行調整，并選出合理的那個。
以上是我們關于配色有關知識點的分享，希望可以幫助大家提升對 UI 配色的認識。
文章來源：優設 作者：超人的電話亭
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
提交規范
AngularJS 在開發者文檔中關于 git commit 的指導說明，提到嚴格的 git commit 格式規范可以在瀏覽項目歷史的過程中看到更易讀的信息，并且能用 git commit 的信息直接生成 AngularJS 的 change log 。
commit messages 格式規范
commit messages 由 header 、body 、footer 組成。
header 又包含 type 、scope 、subject 。header 是必需的，不過其中的 scope 是可選的。
body 和 footer 可以省略。
<type>(<scope>): <subject>
// 空行
<BLANK LINE>
<body>
// 空行
<BLANK LINE>
<footer>
注：為了能在 github 以及各種 git 工具中看得更清晰，commit messages 的每一行都不要超過 100 個字符。
Header
Type
類型必須是以下幾種之一：
feat: 新功能
fix: bug 修復
docs: 僅修改文檔
style: 修改格式（空格，格式化，省略分號等），對代碼運行沒有影響
refactor: 重構（既不是修 bug ，也不是加功能）
build: 構建流程、外部依賴變更，比如升級 npm 包、修改 webpack 配置等
perf: 性能優化
test: 測試相關
chore: 對構建過程或輔助工具和庫（如文檔生成）的更改
ci: ci 相關的更改
除此之外，還有一個特殊的類型 revert ，如果當前提交是為了撤銷之前的某次提交，應該用 revert 開頭，后面加上被撤銷的提交的 header，在 body 中應該注明： This reverts commit <hash>. ，hash 指的就是將要被撤銷的 commit SHA 。
// 例如
revert: feat(user): add user type
This reverts commit ca16a365467e17915f0273392f4a13331b17617d.
Scope
scope 可以指定提交更改的影響范圍，這個視項目而定，當修改影響超過單個的 scope 時，可以指定為 * 。
Sbuject
subject 是指更改的簡潔描述，長度約定在 50 個字符以內，通常遵循以下幾個規范：
用動詞開頭，第一人稱現在時表述，例如：change 代替 changed 或 changes
第一個字母小寫
結尾不加句號（.）
Body
body 部分是對本地 commit 的詳細描述，可以分成多行。
跟 subject 類似，用動詞開頭，第一人稱現在時表述，例如：change 代替 changed 或 changes。
body 應該說明修改的原因和更改前后的行為對比。
Footer
footer 基本用在這兩種情況：
不兼容的改動（ Breaking Changes ）,通常用 BREAKING CHANGE: 開頭，后面跟一個空格或兩個換行符。剩余的部分就是用來說明這個變動的信息和遷移方法等。
關閉 Issue, github 關閉 Issue 的例子
// BREAKING CHANGE: 的例子
BREAKING CHANGE: isolate scope bindings definition has changed and
the inject option for the directive controller injection was removed.
To migrate the code follow the example below:
Before:
scope: {
myAttr: 'attribute',
myBind: 'bind',
myExpression: 'expression',
myEval: 'evaluate',
myAccessor: 'accessor'
}
After:
scope: {
myAttr: '@',
myBind: '@',
myExpression: '&',
// myEval - usually not useful, but in cases where the expression is assignable, you can use '='
myAccessor: '=' // in directive's template change myAccessor() to myAccessor
}
The removed `inject` wasn't generaly useful for directives so there should be no code using it.
// Closes Issue 例子
Closes #2314, #3421
完整的例子
例一: feat
feat($browser): onUrlChange event (popstate/hashchange/polling)
Added new event to $browser:
- forward popstate event if available
- forward hashchange event if popstate not available
- do polling when neither popstate nor hashchange available
Breaks $browser.onHashChange, which was removed (use onUrlChange instead)
例二: fix
fix($compile): couple of unit tests for IE9
Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw expectations.
Closes #392
Breaks foo.bar api, foo.baz should be used instead
例三: style
style($location): add couple of missing semi colons
查看更多例子
規范 commit message 的好處
首行就是簡潔實用的關鍵信息，方便在 git history 中快速瀏覽
具有詳實的 body 和 footer ，可以清晰的看出某次提交的目的和影響
可以通過 type 過濾出想要查找的信息，也可以通過關鍵字快速查找相關提交
可以直接從 commit 生成 change log
// 列舉幾個常用的 log 參數
// 輸出 log 的首行
git log --pretty=oneline
// 只輸出首行的 commit 信息。不包含 hash 和 合并信息等
git log --pretty=format:%s
// 查找有關“更新菜單配置項”的提交
git log --grep="更新菜單配置項"
// 打印出 chenfangxu 的提交
git log --author=chenfangxu
// 紅色的短 hash，黃色的 ref , 綠色的相對時間
git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset'
用工具實現規范提交
上面介紹了規范提交的格式，如果讓各位同學在 git commit 的時候嚴格按照上面的規范來寫，首先心智是有負擔的，得記住不同的類型到底是用來定義什么的，subject 怎么寫，body 怎么寫，footer 要不要寫。其次，對人的規范大部分都是反人性的，所以很可能在過不了多久，就會有同學漸漸的不按照規范來寫?？恳庵玖砜刂谱约簢栏癜凑找幏秮韺懯切枰~外耗費一些精力的，把精力耗費在這種事情上面實在有些浪費。
用工具實現規范提交的方案，一種是在提交的時候就提示必填字段，另一種是在提交后校驗字段是否符合規范。這兩種在實際項目中都是很有必要的。
Commitizen
Zen-like commit messages for internet citizens. 嗯~~一種禪意
Commitizen 是一個幫助撰寫規范 commit message 的工具。他有一個命令行工具 cz-cli，接下來會把使用 Commitizen 分成幾個階段來介紹。
體驗 git cz
// 全局安裝 Commitizen
npm install -g commitizen
你的倉庫可能還不是對 Commitizen 友好的，此時運行 git cz 的效果跟 git commit 一樣，也就是沒有效果。 不過，可以執行 npx git-cz 來體驗。
如果想直接運行 git cz 實現語義化的提交，可以根據 streamich/git-cz 文檔中說的全局安裝 git cz。
// 全局安裝 git cz
npm install -g git-cz
除此之外還有一種更推薦的方式，就是讓你的倉庫對 Commitizen 友好。
Commitizen 友好
全局安裝 Commitizen 后，用 cz-conventional-changelog 適配器來初始化你的項目
// 初始化 cz-conventional-changelog 適配器
commitizen init cz-conventional-changelog --save-dev --save-exact
上面的初始化做了三件事：
安裝 cz-conventional-changelog 依賴
把依賴保存到 package.json 的 dependencies 或 devDependencies 中
在根目錄的 package.json 中 添加如下所示的 config.commitizen
"config": {
"commitizen": {
"path": "./node_modules/cz-conventional-changelog"
}
}
或者，在項目根目錄下新建一個 .czrc 文件，內容設置為
{
"path": "cz-conventional-changelog"
}
現在運行 git cz 效果如下：
cz-customizable 自定義中文配置
通過上面的截圖可以看到，提交的配置選項都是英文的，如果想改成中文的，可以使用 cz-customizable 適配器。
運行下面的命令，注意之前已經初始化過一次了，這次再初始化，需要加 --force 覆蓋
npm install cz-customizable --save-dev
commitizen init cz-customizable --save-dev --save-exact --force
現在 package.json 中 config.commitizen 字段為：
"config": {
"commitizen": {
"path": "./node_modules/cz-customizable"
}
}
cz-customizable 文檔中說明了查找配置文件的方式有三種，我們按照第一種，在項目根目錄創建一個 .cz-config.js 的文件。按照給出的示例 cz-config-EXAMPLE.js 編寫我們的 config。 commit-type 可以參考 conventional-commit-types 。
可以點擊查看我配置好的文件 qiqihaobenben/commitizen-git/.cz-config.js ，里面中詳細的注釋。
commitlint 校驗提交
Commitizen 文檔中開始就介紹到，Commitizen 可以在觸發 git commit 鉤子之前就能給出提示，但是也明確表示提交時對 commit messages 的校驗也是很有用的。畢竟即使用了 Commitzen，也是能繞過去，所以提交最后的校驗很重要。
commitlint 可以檢查 commit messages 是否符合常規提交格式，需要一份校驗配置，推薦 @commitlint/config-conventional 。
npm i --save-dev @commitlint/config-conventional @commitlint/cli
在項目根目錄創建 commitlint.config.js 文件并設置校驗規則：
module.exports = {
extends: ["@commitlint/config-conventional"],
// rules 里面可以設置一些自定義的校驗規則
rules: {},
};
在項目中安裝 husky ，并在項目根目錄新建 husky.config.js 文件，加入以下設置：
// 安裝 husky
npm install --save-dev husky
// husky.config.js 中加入以下代碼
module.exports = {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
}
注意：因為 @commitlint/config-conventional 校驗規則遵循 Angular 的規范， 所以我們在用 cz-customizable 自定義中文配置時， 是按照給出的符合 Angular 規范的示例 cz-config-EXAMPLE.js 編寫.cz-config.js 的。但是如果你自定義的 Commitizen 配置不符合 Angular 規范，可以使用 commitlint-config-cz 設置校驗規則。（推薦還是按照 Angular 規范進行 cz-customizable 自定義配置）
// 安裝 commitlint-config-cz
npm install commitlint-config-cz --save-dev
// commitlint.config.js 改為
module.exports = {
extends: [
'cz'
]
};
git commit 觸發 git cz
在提交的時候，我們都習慣了 git commit ，雖然換成 git cz 不難，但是如果讓開發者在 git commit 時無感知的觸發 git cz 肯定是更好的，
而且也能避免不熟悉項目的人直接 git commit 提交一些不符合規范的信息。
我們可以在 husky.config.js 中設置：
"hooks": {
"prepare-commit-msg": "exec < /dev/tty && git cz --hook || true",
}
注意： 在 window 系統，可能需要在 git base 中才能生效。
生成 CHANGELOG
standard-version
是一個使用 semver 和 conventional-commits 支持生成 CHANGELOG 進行版本控制的實用程序。
standard-version 不只是能生成 CHANGELOG , 還能根據 commit 的 type 來進行版本控制。
// 安裝 standard-verison
npm i --save-dev standard-version
// 在 package.json 中的 scripts 加入 standard-version
{
"scripts": {
"release": "standard-version"
}
}
示例項目
可以查看 commitizen-git ，里面歸納了快速配置 Commitizen 友好倉庫的步驟。
差不多三五分鐘就能搞定。
可以看一下配置完后，執行 git commit 的效果。
擴展
更復雜的自定義提示
cz-customizable 中自定義配置項通常情況是夠用的，
commitlint 中校驗的規則基本上也是夠用的，但是會有比較硬核的開發者會覺得還是不夠，還要更多。比如一些 prompt 更加自定義，
提交時詢問的 question 添加更多的邏輯，比如可以把一些重要的字段校驗提前到 Commitizen 中，或者添加更多自定義的校驗。
如果真想這么干，那就去 fork 一份 cz-conventional-changelog 或者 cz-customizable 來改，
或者直接自己寫一個 adapter。
Commitizen 友好徽章
如果把倉庫配置成了對 Commitizen 友好的話，可以在 README.md 中加上這個小徽章
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
Web 安全是互聯網中不可或缺的一個領域，這個領域中誕生了大量的黑帽子與白帽子，他們都是安全領域的王者，在平時里，他們利用各種巧妙的技術互相博弈，時不時就會掀起一場 Web 安全浪潮，真可謂神仙打架，各顯神通。
本文從一個吃瓜群眾的角度，聊一聊 Web 安全的一些有趣故事。
安全世界觀
安全攻防案例
總結與思考
安全世界觀
在互聯網發展之初，IE 瀏覽器壟斷的時期，大家上網的目的都很單純，主要通過瀏覽器分享信息，獲取新聞。但隨著互聯網的不斷發展發展，一個網頁能做的事情越來越多，除了看新聞，我們還可以看視頻、玩游戲、購物、聊天等，這些功能都大大豐富了我們的生活。
隨著網頁功能的逐漸增多，就開始出現了一些黑帽子，他們試圖通過一些技術手段來牟取利益。在我小的時候，印象最深的就是木馬病毒，它可以監控你的鍵盤，將你在鍵盤上敲打的內容發送到黑客的機器上，黑客通過分析這些內容，很容易就能得到你的游戲賬號和密碼。
在這之后，就誕生出了一些殺毒軟件，致力于解決網絡上的各種病毒，隨著不斷地發展，殺毒軟件已經成為一臺電腦必不可少的軟件。
為什么會出現這樣的安全問題？
安全歸根到底是信任的問題，如果所有人都按照正常的流程去上網，不去謀取私利，也就沒有安全問題可談了。
安全的根本在于信任，但要讓所有人互相信任談何容易。在當前階段，我們可以做到：持續做好安全防護，讓漏洞越來越少，非法攻擊越來越困難，這樣就能逐漸減少黑帽子的數量，讓病毒制造者越來越少。
如何做好安全
要做好安全，首先得理解安全問題的屬性，前人通過無數實踐，最后將安全的屬性總結為安全三要素，分別為：機密性、完整性、可用性。
機密性
保護數據內容不被泄露。
通常使用加密的方法。
完整性
保護數據內容是完整的、沒有被篡改。
通常使用數字簽名的方法。
可用性
數據隨時都能夠使用。
通常是在防御 DOS。
有了安全 3 要素之后，我們就可以對安全問題進行評估了。
資產等級劃分
找出最重要的數據。
找出最重要數據的宿主空間，如：在數據庫里，那么數據庫就得重點防御。
找出數據庫的宿主空間，如：在一臺服務器上，那么這臺服務器就得做次等防御。
找出服務器的宿主空間，如：在 OSI 網絡層級上，那么在網絡層面就得做一般防御。
威脅分析
找出威脅（可能造成危害的來源）。
找出風險（可能出現的損失叫做風險）。
風險分析
采取多標準決策分析，即：風險 = 威脅等級 * 威脅可行性。
計算所有的威脅，將最終的風險進行排序，優先解決風險大的問題。
確認解決方案
找出不安全的實現方式，并確定解決方案。
解決方案不要改變商業需求的初衷。
解決方案需對用戶透明，不要改變用戶的習慣。
做好安全評估之后，我們就有了一份安全解決方案，后續的安全工作只需按照這個方案去做，就沒有任何問題。
安全的原則
有了安全解決方案之后，我們還可以制定一些安全原則，遵守原則做事，可以讓我們事半功倍。
黑名單、白名單原則
白名單方案指的是給安全的資源授權。
黑名單方案指的是禁用不安全的資源。
我們應該優先使用白名單方案，因為黑名單通常統計不完所有的不安全資源。
如：XSS 攻擊的方式非常多，可以通過 script、css、image 標簽等，盡管你將這些標簽都加入黑名單，也不能保證其他的標簽都沒有 XSS 的攻擊隱患。
最小權限原則
只授予必要的權限，不要過度授權，減少出錯機會。
如：普通權限的 Linux 用戶只能操作 ~ 文件夾下的目錄，如果有人想刪庫跑路，在執行 rm -rf / 時，就會提示無權限。
縱深防御原則
這條原則類似 木桶理論，安全水平往往取決于最短的那塊板。
即：不要留下短板，黑帽子們往往可以利用短板為突破口，挖掘更大的漏洞。
數據與代碼分離原則
當用戶數據被當成代碼執行時，混淆了數據和代碼的邊界，從而導致安全問題。
如：XSS 就是利用這一點去攻擊的。
不可預測性原則
這條原則是為了提高攻擊門檻，有效防止基于篡改、偽造的攻擊。
如：數據庫中使用 uuid 代替 number 型的自增主鍵，可以避免 id 被攻擊者猜到，從而進行批量操作。
token 也是利用不可預測性，攻擊者無法構造 token 也就無法進行攻擊。
有了這些安全原則，我們就可以開干了，接下來介紹幾個常見的攻防案例。
安全攻防案例
安全攻防的案例非常多，這里主要介紹幾個出鏡率比較高的安全問題。
客戶端攻擊
XSS 攻擊
CSRF 攻擊
點擊劫持
XSS 攻擊
XSS 攻擊的本質是將用戶數據當成了 HTML 代碼一部分來執行，從而混淆原本的語義，產生新的語義。
如圖所示，我們注冊了一個 <script>alert(document.cookie)</script> 的用戶名，所有能看到此用戶名字的頁面，都會彈出當前瀏覽器的 Cookie，如果代碼的邏輯是將 Cookie 發送到攻擊者的網站，攻擊者就能冒充當前用戶進行登錄了。
XSS 攻擊方式有很多，所有和用戶交互的地方，都有可能存在 XSS 攻擊。
例如：
所有 input 框。
window.location。
window.name。
document.referrer。
document.cookie。
localstorage。
...
由于頁面中與用戶交互的地方非常多，肯定還有一些 XSS 的攻擊方式沒有被發現，而一旦被黑帽子發現，就可能造成嚴重的影響，所以我們務必引起重視。
XSS 攻擊影響
被 XSS 攻擊成功后，攻擊者就可以獲取大量的用戶信息，例如：
識別用戶 UA。
識別用戶瀏覽器擴展。
識別用戶瀏覽過的網站。
通過 CSS 的 Visited 屬性。
獲取用戶真實的 IP。
通過 WebRTC 等。
盜取 Cookie
偽造用戶登錄，竊取用戶資料。
XSS 釣魚。
向頁面注入一個登錄彈窗，讓用戶認為是網站內的登錄彈窗（其實是釣魚網站的），一旦用戶登錄，賬號密碼就泄露給了釣魚網站。
XSS 攻擊防御
目前來說，XSS 已經得到了互聯網行業的重視，許多開發框架都內置了安全的 HTML 渲染方法。
我們也可以自定義進行一些安全配置。
配置 HTTP 中的 http-only 頭，讓前端 JS 不能操作 Cookie。
輸入檢查，在用戶提交數據時，使用 XssFilter 過濾掉不安全的數據。
輸出檢查，在頁面渲染的時候，過濾掉危險的數據。
CSRF 攻擊
CSRF（Cross-site request forgery）跨站請求偽造，是一種利用用戶身份，執行一些用戶非本意的操作。
如圖所示：
用戶先登錄了服務器 B，然后去訪問服務器 C。
服務器 C 通過惡意腳本，冒充 A 去調用服務器 B 上的某個功能，
對于服務器 B 來說，還以為這是 A 發起的請求，就當作正常請求處理了。
試想一下，如果 C 冒充 A 進行了一次轉賬，必定會造成大量的經濟損失。
CSRF 防御方式
防御 CSRF 主要有以下幾種方式：
驗證碼
每一次請求都要求用戶驗證，以確保請求真實可靠。
即：利用惡意腳本不能識別復雜的驗證碼的特點，保證每次請求都是合法的。
Referer 檢查
檢查發起請求的服務器，是否為目標服務器。
即：HTTP 請求中的 Referer 頭傳遞了當前請求的域名，如果此域名是非法服務器的域名，則需要禁止訪問。
Token
利用不可預測性原則，每一請求必須帶上一段隨機碼，這段隨機碼由正常用戶保存，黑帽子不知道隨機碼，也就無法冒充用戶進行請求了。
點擊劫持
點擊劫持是一種視覺欺騙的攻擊手段。攻擊者將需要攻擊的網站通過 iframe 嵌套的方式嵌入自己的網頁中，并將 iframe 設置為透明，在頁面中透出一個按鈕誘導用戶點擊。
就像一張圖片上面鋪了一層透明的紙一樣，你看到的是攻擊者的頁面，但是其實這個頁面只是在底部，而你真正點擊的是被攻擊者透明化的另一個網頁。
如果所示，當你點擊了頁面上的按鈕之后，本以為會...... ，而真正執行的操作是關注了某人的博客。
點擊劫持防御
由于點擊劫持主要通過 iframe，所以在防御時，主要基于 iframe 去做。
方案一：frame busting
正常網站使用 JS 腳本判斷是否被惡意網站嵌入，如：博客網站監測到被一個 iframe 打開，自動跳轉到正常的頁面即可。
if (self !== top) { // 跳回原頁面 top.location = self.location;}
方案二：使用 HTTP 中的 x-frame-options 頭，控制 iframe 的加載，它有 3 個值可選：
DENY，表示頁面不允許通過 iframe 的方式展示。
SAMEORIGIN，表示頁面可以在相同域名下通過 iframe 的方式展示。
ALLOW-FROM，表示頁面可以在指定來源的 iframe 中展示。
配置 iframe 的 sandbox 屬性
sandbox = "allow-same-origin" 則只能加載與主站同域的資源。
服務器端攻擊
服務器端的攻擊的方式也非常多，這里列舉幾個常見的。
SQL 注入攻擊
文件上傳漏洞
登錄認證攻擊
應用層拒絕服務攻擊
webServer 配置安全
SQL 注入攻擊
SQL 注入和 XSS 一樣，都是違背了數據和代碼分離原則導致的攻擊方式。
如圖所示，我們利用 SQL 注入，就能在不需要密碼的情況下，直接登錄管理員的賬號。
攻擊的前提是：后端只用了簡單的拼接 SQL 的方式去查詢數據。
# 拼接出來的 sql 如下：select * from user where username = 'admin' or 1=1 and password = 'xxx'# 無論密碼輸入什么，這條 sql 語句都能查詢到管理員的信息
除此之外，SQL 注入還有以下幾種方式：
使用 SQL 探測，猜數據庫表名，列名。
通過 MySQL 內置的 benchmark 探測數據庫字段。
如：一段偽代碼 select database as current if current[0]==='a',benchmark（10000,'猜對了'） 如果表明猜對了，就延遲 10 s 并返回成功。
使用存儲過程執行系統命令
通過內置的方法或存儲過程執行 shell 腳本。
如：xp_cmdshell、sys_eval、sys_exec 等。
字符串截斷
如：MySQL 在處理超長的字符串時，會顯示警告，但會執行成功。
注冊一個 admin + 50 個空格的用戶，會觸發截斷，最終新增一個 admin 用戶，這樣就能擁有管理員權限了。
SQL 注入防御
防止 SQL 注入的最好的辦法就是，不要手動拼接 SQL 語句。
最佳方案，使用預編譯語句綁定變量
通常是指框架提供的拼接 SQL 變量的方法。
這樣的語義不會發生改變，變量始終被當成變量。
嚴格限制數據類型，如果注入了其他類型的數據，直接報錯，不允許執行。
使用安全的存儲過程和系統函數。
CRLF 注入
在注入攻擊中，換行符注入也是非常常見的一種攻擊方式。
如果在 HTTP 請求頭中注入 2 個換行符，會導致換行符后面的所有內容都被解析成請求實體部分。
攻擊者通常在 Set-Cookie 時，注入換行符，控制請求傳遞的內容。
文件上傳漏洞
上傳文件是網頁開發中的一個常見功能，如果不加處理，很容易就會造成攻擊。
如圖所示，攻擊者上傳了一個木馬文件，并且通過返回的 URL 進行訪問，就能控制服務器。
通常我們會控制上傳文件的后綴名，但也不能完全解決問題，攻擊者還可以通過以下方式進行攻擊：
偽造正常文件
將木馬文件偽裝成正常的后綴名進行上傳。
如果要避免這個問題，我們可以繼續判斷上傳文件的文件頭前 10 個字節。
Apache 解析方式是從后往前解析，直到找到一個認識的后綴名為止
如：上傳一個 abc.php.rar.rar.rar 能繞過后綴名檢查，但在執行時，被當成一個 php 文件進行執行。
IIS 會截斷分號進行解析
如：abc.asp;xx.png 能繞過后綴名檢查，但在執行時，被當成一個 asp 文件進行執行。
HTTP PUT 方法允許將文件上傳到指定位置
通過 HTTP MOVE 方法，還能修改上傳的文件名。
通過二者配合，就能先上傳一個正常的后綴名，然后改為一個惡意的后綴名。
PHP CGI 路徑問題
執行 http://abc.com/test.png/xxx.php 時，會把 test.png 當做 php 文件去解析。
如果用戶正好是把一段惡意的 php 腳本當做一張圖片進行上傳，就會觸發這個攻擊。
文件上傳漏洞防御
防御文件上傳漏洞，可以從以下幾點考慮：
將文件上傳的目錄設置為不可執行。
判斷文件類型
檢查 MIME Type，配置白名單。
檢查后綴名，配置白名單。
使用隨機數改寫文件名和文件路徑
上傳文件后，隨機修改文件名，讓攻擊者無法執行攻擊。
單獨設置文件服務器的域名
單獨做一個文件服務器，并使用單獨的域名，利用同源策略，規避客戶端攻擊。
通常做法是將靜態資源存放在 CDN 上。
登錄認證攻擊
登錄認證攻擊可以理解為一種破解登錄的方法。攻擊者通常采用以下幾種方式進行破解：
彩虹表
攻擊者通過搜集大量明文和 MD5 的對應關系，用于破解 MD5 密文找出原文。
對于彩虹表中的 MD5 密碼，我們可以加鹽，進行二次加密，避免被破解。
Session Fixation 攻擊
利用應用系統在服務器的 SessionID 固定不變機制，借助他人用相同的 SessionID 獲取認證和授權。
攻擊者登錄失敗后，后端返回了 SessionID，攻擊者將 SessionID 交給正常用戶去登錄，登錄成功后，攻擊者就能使用這個 SessionID 冒充正常用戶登錄了。
如果瀏覽器每一次登錄都刷新 SessionID 可以避免這個問題。
Session 保持攻擊
有些時候，后端出于用戶體驗考慮，只要這個用戶還活著，就不會讓這個用戶的 Session 失效。
攻擊者可以通過不停發起請求，可以讓這個 Session 一直活下去。
登錄認證防御方式
多因素認證
密碼作為第一道防御，但在密碼驗證成功后，我們還可以繼續驗證：動態口令，數字證書，短信驗證碼等，以保證用戶安全。
由于短信和網頁完全是 2 套獨立的系統，攻擊者很難獲取到短信驗證碼，也就無法進行攻擊。
除此之外，前端登錄認證還有多種方式，如果你對此感興趣，可以參考我之前寫的 前端登錄，這一篇就夠了。
應用層拒絕服務攻擊
應用層拒絕服務攻擊，又叫 DDOS 攻擊，它指的是利用大量的請求造成資源過載，導致服務器不可用。
通常有以下幾種 DDOS 攻擊方式：
SYN Flood 洪水攻擊
利用 HTTP 3 次握手機制，消耗服務器連接資源。
如：攻擊者發起大量的 HTTP 請求，但并不完成 3 次握手，而是只握手 2 次，這時服務器端會繼續等待直至超時。這時的服務器會一直忙于處理大量的垃圾請求，而無暇顧及正常請求。
Slowloris 攻擊
以非常低的速度發送 HTTP 請求頭，消耗服務器連接資源。
如：攻擊者發送大量 HTTP 請求，但每個請求頭都發的很慢，每隔 10s 發送一個字符，服務器為了等待數據，不得始終保持連接，這樣一來，服務器連接數很快就被占光了。
HTTP POST DOS
發送 HTTP 時，指定一個非常大的 Content-Length 然后以很長的間隔發送，消耗服務器連接資源。
CC 攻擊
針對一些非常消耗資源的頁面，不斷發起請求。
如：頁面中的某些頁面，需要后端做大量的運算，或者需要做非常耗時的數據庫查詢。在大量的請求下，服務器的 CPU、內存等資源可能就被占光了。
Server Limit DOS
通過 XSS 注入一段超長的 Cookie，導致超出 Web 服務器所能承受的 Request Header 長度，服務器端就會拒絕此服務。
ReDOS
針對一些缺陷的正則表達式，發起大量請求，耗光系統資源。
應用層拒絕服務攻擊防御
對于應用層拒絕服務攻擊，目前也沒有特別完美的解決方案，不過我們還是可以進行一些優化。
應用代碼做好性能優化
合理使用 Redis、Memcache 等緩存方案，減少 CPU 資源使用率。
網絡架構上做好優化
后端搭建負載均衡。
靜態資源使用 CDN 進行管理。
限制請求頻率
服務器計算所有 IP 地址的請求頻率，篩選出異常的 IP 進行禁用。
可以使用 LRU 算法，緩存前 1000 條請求的 IP，如果有 IP 請求頻率過高，就進行禁用。
其實，處理 DDOS 核心思路就是禁用不可信任的用戶，確保資源都是被正常的用戶所使用。
WebServer 配置安全
我們在部署 web 應用的時候，經常會用到 Nginx、Apache、IIS、Tomcat、Jboss 等 Web 服務器，這些服務器本身也存在一些安全隱患，如果配置不當，很容易收到攻擊。
在配置 Web 服務器時，可以參考以下幾點：
以用戶權限運行 Web 服務器
遵守最小權限原則，以最小權限身份運行 Web 服務器，限制被入侵后的權限。
刪除可視化后臺
運行 Tomcat、Jboss 等 Web 服務器時，默認會開啟一個可視化的運營后臺，運行在 8080 端口，并且第一次訪問是沒有認證的。
攻擊者可以利用可視化后臺，遠程加載一段 war 包或者上傳木馬文件，進行控制。
及時更新版本
主流的 Web 服務器，每隔一段時間就會修復一些漏洞，所以記得及時更新版本。
總結與思考
本文介紹了 Web 安全的基本概念，以及大量的攻防技巧，其實這只是 Web 安全中的冰山一角，如果你對此感興趣，不妨在安全領域繼續深耕學習，一定能看到更廣闊一片天。
對于一個開發者來說，我們應該在寫代碼時就將安全考慮其中，形成自己的一套安全開發體系，做到心中有安全，時時考慮安全，就能無形之中化解不法分子的攻擊。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
編輯導讀：隨著醫療行業與互聯網的聯系日益緊密，醫療行業對產品經理的需求也越來越迫切。在這個特殊行業中，醫療產品經理需要具備哪些能力，應該如何工作，創造哪些價值？本文圍繞醫療產品經理展開，從七個方面展開介紹分析，希望對你有幫助。
越來越多的醫療機構開始考慮設置醫療產品經理這個崗位，但是對于產品經理具體應該做什么工作，可能產生何等價值，以及如何招聘到合適的人才，和這個角色在組織內部如何開展工作，都有很多的困惑。今天我們就簡單聊聊這個話題。
總的來說醫療產品經理還是個非常新，甚至可以說有一些超前的職能，傳統FMCG和互聯網行業的產品經理對應的工作內容和思考方式并不能簡單照搬過來使用。我們需要清空過去在這些行業積累的認知，從醫療經營的原點出發，從下面7個方面思考：
產品經理就是足球場上的中場大將，起到承上啟下，功放轉換的樞紐，具體說有三大作用：
什么是進攻？進攻就是嘗試主動去占據一塊領地。
對營利性醫療機構來說最常見的情況有4種：
那么，又何謂防守呢？簡單來說，就是對應上述各種進攻的應對。
十年前私立醫院還不算很多，也還沒有那么多連鎖診所品牌的時候，事實上大家主要都在忙著跑馬圈地，短兵相接的攻防其實并不多?，F在隨著市場參與者的倍增，慢慢開始出現了小區域內的半正面PK，并且我預計在未來兩年內可能會出現直接內部指名道姓對標的戰斗。
足球場上的三條線是進攻、防守和中場，這里我們所說的三條線，大體對應的是：市場營銷、醫療質量和行政職能三大板塊。產品經理的重要價值就是能夠打通這三條線的隔閡，把整個醫院的資源凝結成有效的市場成果。
醫療產品不等于，不等于，不等于“打包套餐”！這個概念請務必建立起來。
首先要厘定什么是醫療產品。
可以用“三個明確”來界定之：
醫療產品開發的邏輯的源頭就在于評估一種醫療服務是否吻合這三個明確，因此不是所有的醫療服務都可能變成“產品”。
比如我們醫院口腔科有一個非常棒的醫生，專注于牙齒美容，我們稱之為“微笑設計”。這種設計是完全量體裁衣的，我們市場團隊對他的關注點就主要在故事性的傳播，而不是試圖將這種高度個性化、動態化的醫療行為產品化。
簡單來說，對于符合三個明確的醫療服務，我們對其進行產品化的“化”，是一系列有序的動作：
囿于篇幅，這里我們就不展開詳述了。
理想中的醫療產品經理對下面4件事情負責：
很容易看出來，這4種不同的職責恰好也就對應了攻防轉換的價值所在。其中促銷是一個容易被忽視和輕視的事情，“不就是打折然后發個微信（十年前是發短信）推文嘛”——絕對不是這樣，促銷是一門大學問，打折、捆綁、買贈、兌獎、積分凡此種種。不僅花樣很多，更重要的是背后的深層次的思考，是“為什么”。
另外，目前的醫療機構基本上也沒有人比較認真、成體系地做競品追蹤。這樣會失去潛在市場機會，非?？上?。
我認為一名出色的醫療產品經理應該在下面四個方面都具備一定的能力，沒有特別的短板：
特別就同理心和表達能力簡單闡述。同理心，即換位思考，用現在更流行的話說，是場景意識。能否準確地設置出用戶的場景，體會到用戶的感受，會直接決定產品帶給客戶的體驗，進而一系列結果：定價、毛利、傳播ROI、客戶口碑，口碑帶來的新客增長，等等不一而足。
而表達能力則是決定這個產品經理是否能實現“串聯三條線”價值的決定性因素。醫院是一個觀念高度保守，流程高度復雜的行業，很多人雄心勃勃地進來，最終死在“搞不定那些人”上。因此，優秀的表達能力，包括書面和口頭表達能力，是遴選醫療產品經理必須考量的重要因素之一。
我不是危言聳聽：產品經理幾乎要和醫院里所有部門打交道。
常見的如下面這些：
醫療、護理和財務對于產品工作的重要性相信無需贅言。后面幾個呢？
試想，你精心設計的賣點，是你自己拉著每一個潛在客戶去吆喝么？當然不是，客服要幫你介紹，新媒體要幫你寫文章、畫插圖。他們是不是要吃透你的意思？如果涉及填表、兌獎，要不要和客服商量流程？遇到產品的技術較為復雜，需要不需要策劃一些活動幫助客戶直觀理解其價值？最后，當潛在用戶感興趣而打電話給呼叫中心的時候，接線員是否已經被你提前武裝好，能充分回答各種提問了？
至于獨立的數據部門，是我的一個強力推薦。傳統上由財務和病案提供的數據，更多聚焦于“既往”而很少關注“開來”。如果不由同時懂得醫療業務和有商業經驗的數據部門處理，很難直接推動運營的改善和提升。
很多人問我，產品經理屬于市場營銷部門嗎？難道不是屬于運營部，或者醫療企劃之類的部門嗎？
別忘了，市場營銷最基本的范式——4P中第一個P就是產品，Product。只要你所在的醫療機構設置有相對完整的市場部門，就應該在其中設置產品經理崗位。或者反過來說，如果你準備建制產品經理崗位，從一開始就應該將其設置在市場部內，并從頭開始考慮這個職位所需要的上下游角色和他們之間的銜接。
如前面所分析的，產品經理的后端，一定要有提供數據支持的部門，前端一定要有專業的傳播團隊，這樣才能實現產品的潛力。橫向上，產品經理和他的上級，一定要高度重視與客戶服務團隊的緊密合作。
老實說，現在幾乎沒有多少現成的、成熟的醫療產品經理。因為營利性醫療行業太新了，而產品經理這個崗位在這個行業又是近一兩年剛剛興起的角色。
從招聘角度來說，我建議不要拘泥于候選人必須有醫療背景。我就沒念過醫學院，十一年前入行，就這樣摸著石頭過河，也多多少少做過一些還不錯的產品，有過幾個“爆款”的心得。相對來說，我更看重候選人是否有完整的商業思考邏輯能力。
換一個角度來說，還可以在醫院內部挖掘有潛力的人才，從臨床部門轉型為產品經理。最關鍵的環節在于這個人是否有足夠強烈的興趣。世上無難事只怕有心人，有醫學院背景的人才，只要對產品工作發自內心感興趣，就有很大的轉型成功概率。
文章來源：人人都是產品經理 作者：易亮
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
藍藍設計的小編 http://www.syprn.cn