使你的代碼可讀和可維護(hù)的快速提示。

有多少次，你打開一個舊的項(xiàng)目，發(fā)現(xiàn)混亂的代碼，當(dāng)你添加一些新的東西時，很容易崩潰？我們都有過這樣的經(jīng)歷。

為了減少難以讀懂的javascript的數(shù)量，我提供了以下示例。這些都是我過去所犯過的錯誤。

對具有多個返回值的函數(shù)使用數(shù)組解構(gòu)

假設(shè)我們有一個返回多個值的函數(shù)。一種可能的實(shí)現(xiàn)是使用數(shù)組解構(gòu)，如下所示：

const func = () => {

 const a = 1;

 const b = 2;

 const c = 3;

 const d = 4;

 return [a,b,c,d];

}

const [a,b,c,d] = func();

console.log(a,b,c,d); // 1,2,3,4

盡管上面的方法很好用，但確實(shí)引入了一些復(fù)雜性。

當(dāng)我們調(diào)用函數(shù)并將值分配給 a,b,c,d 時，我們需要注意返回數(shù)據(jù)的順序。這里的一個小錯誤可能會成為調(diào)試的噩夢。

此外，無法確切指定我們要從函數(shù)中獲取哪些值，如果我們只需要 c 和 d 怎么辦？

相反，我們可以使用對象解構(gòu)。

const func = () => {

 const a = 1;

 const b = 2;

 const c = 3;

 const d = 4;

 return {a,b,c,d};

}

const {c,d} = func();

現(xiàn)在，我們可以輕松地從函數(shù)中選擇所需的數(shù)據(jù)，這也為我們的代碼提供了未來的保障，允許我們在不破壞東西的情況下增加額外的返回變量。

不對函數(shù)參數(shù)使用對象分解

假設(shè)我們有一個函數(shù)，該函數(shù)將一個對象作為參數(shù)并對該對象的屬性執(zhí)行一些操作。一種幼稚的方法可能看起來像這樣：

// 不推薦

function getDaysRemaining(subscription) {

 const startDate = subscription.startDate;

 const endDate = subscription.endDate;

 return endDate - startDate;

}

上面的方法按預(yù)期工作，但是，我們創(chuàng)建了兩個不必要的臨時引用 startDate 和 endDate。

一種更好的實(shí)現(xiàn)是對 subscription 對象使用對象解構(gòu)來在一行中獲取 startDate 和 endDate。

// 推薦

function getDaysRemaining(subscription) {

 const { startDate, endDate } = subscription;

 return startDate - endDate;

}

我們可以更進(jìn)一步，直接對參數(shù)執(zhí)行對象析構(gòu)。

// 更好

function getDaysRemaining({ startDate, endDate }) {

 return startDate - endDate;

}

更優(yōu)雅，不是嗎？

在不使用擴(kuò)展運(yùn)算符的情況下復(fù)制數(shù)組

使用 for循環(huán)遍歷數(shù)組并將其元素復(fù)制到新數(shù)組是冗長且相當(dāng)丑陋的。

可以以簡潔明了的方式使用擴(kuò)展運(yùn)算符來達(dá)到相同的效果。

const stuff = [1,2,3];

// 不推薦

const stuffCopyBad = []

for(let i = 0; i < stuff.length; i++){

 stuffCopyBad[i] = stuff[i];

}

// 推薦

const stuffCopyGood = [...stuff];

使用var

使用 const 保證不能重新分配變量。這樣可以減少我們代碼中的錯誤，并使其更易于理解。

// 不推薦

var x = "badX";

var y = "baxY";

// 推薦

const x = "goodX";

const y = "goodX";

果你確實(shí)需要重新分配變量，請始終選擇 let 而不是 var。

這是因?yàn)?let 是塊作用域的，而 var 是函數(shù)作用域的。

塊作用域告訴我們，只能在定義它的代碼塊內(nèi)部訪問變量，嘗試訪問塊外部的變量會給我們提供ReferenceError。

for(let i = 0; i < 10; i++){

 //something

}

print(i) // ReferenceError: i is not defined

函數(shù)作用域告訴我們，只能在定義其的函數(shù)內(nèi)部訪問變量。

for(var i = 0; i < 10; i++){

 //something

}

console.log(i) // 10

let 和 const 都是塊范圍的。

不使用模板字面值

手動將字符串連接在一起相當(dāng)麻煩，而且輸入時可能會造成混淆。這是一個例子：

// 不推薦

function printStartAndEndDate({ startDate, endDate }) {

 console.log('StartDate:' + startDate + ',EndDate:' + endDate)

}

模板文字為我們提供了一種可讀且簡潔的語法，該語法支持字符串插值。

// 推薦

function printStartAndEndDate({ startDate, endDate }) {

 console.log(`StartDate: ${startDate}, EndDate: ${endDate}`)

}

模板文字也提供了嵌入新行的簡便方法，你所需要做的就是照常按鍵盤上的Enter鍵。

// 兩行打印

function printStartAndEndDate({ startDate, endDate }) {

 console.log(`StartDate: ${startDate}

 EndDate: ${endDate}`)

}

藍(lán)藍(lán)設(shè)計( sillybuy.com )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)

在多方合作的項(xiàng)目中，我們需要規(guī)劃項(xiàng)目的合理落地方案，并在執(zhí)行過程中和各方有效溝通。結(jié)合近期羚瓏商家合作測試項(xiàng)目的實(shí)踐經(jīng)歷，聊聊我在項(xiàng)目中的心得體會。

項(xiàng)目背景

我們想了解京東首焦banner中，設(shè)計因素對點(diǎn)擊效果的影響情況。做這件事最大的限制在于投放數(shù)據(jù)會受多種因素影響，不僅是一個設(shè)計因素的選擇，還有比如人群、出價、品牌、類目等因素的不同，都能影響到最終的投放結(jié)果。因此，從總體樣本中取樣進(jìn)行分析的意義不大。為了解決上述問題，我們招募了一些能控制其他因素的品牌廣告主，與有能力支持投放的測試投放系統(tǒng)合作，共同完成A/B測試。

需求拆解與規(guī)劃

不難發(fā)現(xiàn)這個需求會涉及到多個項(xiàng)目角色，意味著將有復(fù)雜的推進(jìn)流程，需要提前拆解與規(guī)劃，才能保證項(xiàng)目進(jìn)度可控。

△ 測試項(xiàng)目流程與分工

我們可以分三步來進(jìn)行：

1. 找到項(xiàng)目關(guān)鍵步驟

關(guān)鍵步驟是將一個項(xiàng)目的推進(jìn)拆解成多個階段，找到關(guān)鍵步驟，也就知道了每個階段的主要任務(wù)，可以進(jìn)一步分工來推進(jìn)項(xiàng)目。

如何找到關(guān)鍵步驟？我們可以從項(xiàng)目目標(biāo)中提取。測試項(xiàng)目的目標(biāo)是找到設(shè)計因素與投放點(diǎn)擊效果的影響關(guān)系。這個目標(biāo)里提取重要的關(guān)鍵詞為：設(shè)計因素、投放點(diǎn)擊效果、影響關(guān)系。面對這些關(guān)鍵詞我們會有疑問產(chǎn)生如「測試設(shè)計因素是什么？有哪些？」、「如何投放」、「如何判斷影響關(guān)系」，再進(jìn)行串聯(lián)梳理，得到完整步驟流程。

2. 明確角色任務(wù)與產(chǎn)出

每個階段的主要任務(wù)，可以拆解分工給項(xiàng)目角色，項(xiàng)目角色也就有了各自的任務(wù)，角色產(chǎn)出物則是任務(wù)執(zhí)行的結(jié)果，將直接推動項(xiàng)目進(jìn)入下一環(huán)節(jié)。所以為了順利推進(jìn)項(xiàng)目，我們需要根據(jù)項(xiàng)目實(shí)際情況評估角色任務(wù)分工是否合理，產(chǎn)出是否滿足項(xiàng)目要求。

比如在「設(shè)計測試圖片」這個步驟中，有兩個分工方案，讓廣告主或我們自己設(shè)計圖片。我們從項(xiàng)目時長、溝通成本、潛在風(fēng)險等維度進(jìn)行評估，判斷廣告主把控變量不嚴(yán)謹(jǐn)會導(dǎo)致測試數(shù)據(jù)無效，且外部合作溝通成本較高時間不夠，所以最后將設(shè)計圖片的任務(wù)分給了內(nèi)部。

3. 預(yù)判項(xiàng)目風(fēng)險

對流程規(guī)劃得越詳細(xì)，在后續(xù)合作過程中越容易把控項(xiàng)目的節(jié)奏，項(xiàng)目風(fēng)險越低。

再如「設(shè)計測試圖片」這個關(guān)鍵步驟，詳細(xì)展開執(zhí)行流程會發(fā)現(xiàn)涉及到交互設(shè)計師、兩方視覺設(shè)計師、廣告主四個角色。對于項(xiàng)目執(zhí)行角色，產(chǎn)出物的質(zhì)量及按時交付尤為重要，所以重點(diǎn)把控輸出準(zhǔn)確性與完成時間。對于項(xiàng)目決策角色，也就是決策最終投放哪些圖片的廣告主，溝通配合尤為重要。所以基于規(guī)避風(fēng)險也對項(xiàng)目流程進(jìn)行了優(yōu)化，前置在項(xiàng)目之初，要求廣告主提前準(zhǔn)備交付內(nèi)容，規(guī)定交付時間及格式，以及充分溝通說明圖片設(shè)計產(chǎn)出之后不能進(jìn)行較大改動。

結(jié)論推導(dǎo)的重要前提與方法

1. 保證數(shù)據(jù)有效

測試結(jié)論來源于測試數(shù)據(jù)，我們首先應(yīng)該保證回收數(shù)據(jù)的有效性。測試項(xiàng)目的關(guān)鍵指標(biāo)是點(diǎn)擊率，即點(diǎn)擊量與曝光量的比值。當(dāng)圖片本身曝光量低時，我們認(rèn)為隨著曝光量增加，點(diǎn)擊率比值波動范圍仍然較大，數(shù)據(jù)還未穩(wěn)定在某個區(qū)間段，會影響結(jié)論準(zhǔn)確性，判定為無效數(shù)據(jù)。發(fā)現(xiàn)類似這種問題，我們會和廣告主商量繼續(xù)投放，延長測試時間來增加曝光。

2. 充分測試

要想得到可靠普適的結(jié)論，需要對比多組樣本的測試結(jié)果。對于某個設(shè)計因素，我們先進(jìn)行了單一廣告主的投放數(shù)據(jù)對比，可以找到投放效果最優(yōu)和最差的設(shè)計水平。然后又將多個廣告主的結(jié)果進(jìn)行對比，會發(fā)現(xiàn)存在不一致的情況，驗(yàn)證了單組樣本結(jié)論不能作為類目結(jié)論輸出。如果多個廣告主結(jié)果一致，或呈現(xiàn)某一趨勢，則結(jié)論在該類目可以認(rèn)為較為普適。

3. 差異分析

對于多組樣本結(jié)果不一致的情況，可以從組間因素差異著手分析。

△ 背景設(shè)計因素測試結(jié)果

上圖是兩個廣告主分別測試背景設(shè)計因素得到的結(jié)果。第一組的投放結(jié)果為實(shí)景設(shè)計效果更好，第二組則為普通平面設(shè)計效果更好。產(chǎn)生這樣差異的原因是什么呢？我們先找出組間可能導(dǎo)致這一結(jié)果的因素，分別是顏色和產(chǎn)品。從顏色上看，是否平面+黑色效果更好呢？我們看了其他廣告主結(jié)果，否定了這一猜想。再從產(chǎn)品圖來看，兩個產(chǎn)品的識別度是不同的，我們將其他廣告主該因素測試圖按產(chǎn)品是否容易識別分組，最終得出兩組不同的結(jié)論：當(dāng)產(chǎn)品圖易識別時，背景設(shè)計對效果影響不大；當(dāng)產(chǎn)品圖不易識別時，實(shí)景圖效果更好。這也就解釋了上圖結(jié)果不一致的原因。

回顧整個項(xiàng)目，我個人認(rèn)為項(xiàng)目中最重要的工作是溝通。下面我來分別談?wù)剝?nèi)外部溝通的經(jīng)驗(yàn)。

雙贏是外部合作溝通的基石

與外部團(tuán)隊、廣告主合作推進(jìn)項(xiàng)目，需要及時有效的溝通，什么是有效的溝通呢？

1. 圍繞對方利益談配合

廣告主只看轉(zhuǎn)化結(jié)果，我們?nèi)绻徽勗O(shè)計不談轉(zhuǎn)化，廣告主是不會想要出錢參與項(xiàng)目的，那么項(xiàng)目也將停滯不前。所以在合作前，我們做了項(xiàng)目及團(tuán)隊包裝，用真實(shí)的案例讓廣告主快速理解參與項(xiàng)目所能帶來的價值，并用團(tuán)隊以往的作品、能力展示讓廣告主了解與我們合作的優(yōu)勢。廣告主越認(rèn)同項(xiàng)目價值及我們的專業(yè)度，配合度就會越高。

△ 招募PPT中的真實(shí)案例介紹

2. 圍繞對方目標(biāo)來「推銷」方案

在推進(jìn)項(xiàng)目這一點(diǎn)上，找到目標(biāo)一致的點(diǎn)更容易促成各方意見達(dá)成一致。

我們合作的廣告主很多會選擇外包banner設(shè)計，所以廣告主們習(xí)慣了做傳說中的「甲方爸爸」，難免會對視覺設(shè)計方案有各種主觀意見。比如，某電視廣告主不喜歡紅色圖片設(shè)計，想要藍(lán)色。對于這樣的分歧，我個人喜歡用引導(dǎo)式的溝通方法。首先，不要急于表達(dá)自己或否定對方的意見，可以以疑問句式來猜測對方的目的?！赶矚g藍(lán)色是希望用沉穩(wěn)的顏色來表現(xiàn)產(chǎn)品的高級感嗎？」，如果猜測正確，對方會因自己的需求被理解而更容易溝通，這時再繼續(xù)闡述用紅色如何表達(dá)高級感；如果猜測不正確，對方會順勢說出原因，我們再圍繞對方的目標(biāo)進(jìn)一步溝通。如果對方毫無理由「不喜歡這個設(shè)計」，而設(shè)計師并不覺得有設(shè)計問題，那么我們需要停止專業(yè)角度的溝通，從設(shè)計是否滿足當(dāng)前階段項(xiàng)目需求的角度來溝通，方案則更容易被接受。

內(nèi)部合作各盡所能發(fā)揮優(yōu)勢

內(nèi)部合作分交互、視覺、用研三種不同的崗位角色，在項(xiàng)目中都發(fā)揮著自己重要的作用。

交互擅長統(tǒng)籌與拆解問題，團(tuán)隊的內(nèi)部溝通能產(chǎn)生多種解題思路，對項(xiàng)目的推進(jìn)至關(guān)重要；在遇到如需要統(tǒng)計學(xué)分析、樣本設(shè)置等專業(yè)問題時，用研可以提供更專業(yè)的分析方法與幫助，為我們實(shí)現(xiàn)科學(xué)分析提供有力支持；視覺設(shè)計師對banner設(shè)計有豐富的經(jīng)驗(yàn)，可以在各個環(huán)節(jié)中發(fā)揮優(yōu)勢。從項(xiàng)目之初就參與設(shè)計因素拆解、測試方案設(shè)置，可以補(bǔ)充視覺相關(guān)的設(shè)計因素，在優(yōu)化測試方案、風(fēng)險預(yù)期方面都可以提供重要的建議。在結(jié)論推導(dǎo)中，對圖中的因素差異敏感度高，可以根據(jù)數(shù)據(jù)提出關(guān)鍵猜想。

文章來源：優(yōu)設(shè)    作者：京東設(shè)計中心JDC

藍(lán)藍(lán)設(shè)計( sillybuy.com )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)

色彩在UI設(shè)計中的作用：加深品牌印象與品牌感、引導(dǎo)用戶視覺凹增加易讀性、區(qū)分信息交互的狀態(tài)、營造氛圍傳遞熱度……

前言

不管是做 UI 設(shè)計還是畫插畫，有很多同學(xué)覺得自己是因?yàn)樘熨x不夠所以對色彩的敏感度不夠，其實(shí)不然。一個可能是大家總結(jié)的太少，從來都是憑感覺和運(yùn)氣去配色，但配色都是有講究的。

一個設(shè)計作品呈現(xiàn)到用戶面前，第一眼進(jìn)入眼簾的就是產(chǎn)品的視覺表現(xiàn)，而產(chǎn)品的色彩在其中起到了舉足輕重的作用，毫無疑問色彩搭配對于設(shè)計師來說是非常重要的。那么具體到實(shí)際項(xiàng)目中該使用什么怎樣的色彩，需要怎么做呢？

用戶界面是一個設(shè)計師用理性思維解決用戶感性需求的窗口。如果對色彩的運(yùn)用不加以克制，界面可能會顯得花哨而沒有主次；但過于拘謹(jǐn)又容易使界面保守，難以激發(fā)用戶情緒，下面以Bee express項(xiàng)目的實(shí)例來理性推導(dǎo)制定一套色彩系統(tǒng)。

切勿直奔主題

做過設(shè)計的同學(xué)應(yīng)該都知道顏色模式：RGB、CMYK、Lab 等等，這里不做過多的解釋了。另外每個顏色具有一定的性格特征和表達(dá)方式，而且都會有正反兩面。雖然每種色彩都有正向性格特征，但是我們在定位主體色之前一定要知道所選擇色彩的負(fù)面特征對企業(yè)是否會帶來負(fù)面的影響，

開始之前我們需要了解在配色過程中需要避免出現(xiàn)的問題，如果你經(jīng)常出現(xiàn)下列的問題，保證你在試用期內(nèi)一次性就能拿到全部薪資，emmm……

• 高飽和度的色彩會造成我們的視覺疲勞及視幻；
• 灰部使用過多的配色會使界面有一種臟兮兮、霧蒙蒙的感覺，甚至心情低落；
• 沒有規(guī)律且過多的配色。如果你不是做五彩斑斕的黑，建議6、3、1的色彩配比，輔助色不超過3種；
• 熒光色。使用這種色彩的，建議跟色彩對視，看誰堅持的更久，除非是你贏了；
• 太輕柔的顏色-沒有重點(diǎn)且輕飄飄的感覺；
• 現(xiàn)在很火的新擬物化設(shè)計對于部分（沒有絕對）產(chǎn)品可能會造成信息識別性很差；
• 不要將對抗色重疊，否則你會很浮躁。

定位品牌色

雖然設(shè)計是相通的，但是在不同的設(shè)計領(lǐng)域進(jìn)行配色時，依然會存在巨大的區(qū)別。更換品牌的主體色，都不會是因?yàn)樵O(shè)計師自己的決定，而是公司在商業(yè)策略上優(yōu)先做出了調(diào)整，然后通過品牌視覺上的變更將這個信息傳遞給消費(fèi)者。

Bee Express快遞、速遞柜業(yè)務(wù)為主，前期的主色及視覺形象以橙黃色為主，為了避免視覺跳躍性太大，以及后期IP形象（蜜蜂吉祥物）打造，本次品牌色彩升級在原有基礎(chǔ)上優(yōu)化了色調(diào)，以保證后期產(chǎn)品的易用性和延展性，并利用最科學(xué)、最適用的方式推導(dǎo)出輔助色，以提升應(yīng)用視覺的豐富性和感官體驗(yàn)。

express原主色：

為了不影響原有色調(diào)前期的視覺傳播，即在原有主體色的基礎(chǔ)上調(diào)整SHB的數(shù)值，讓色彩更具視覺沖擊力，在色彩襯托（字體、圖標(biāo)）更清晰。

• H（Hue：色相）
• S（Saturation：飽和度）
• B（Brightness：明度）

通過調(diào)整后的主體色也能看出，明亮清晰的主體色（品牌色）也更適合在界面中的運(yùn)用，為信息傳遞、引導(dǎo)操作、品牌價值帶來更大的提升。

• 信息傳遞：產(chǎn)品的首要目的是傳遞用戶所需要的信息，這就需要界面有清晰的層級關(guān)系，明確、舒適的閱讀體驗(yàn)。
• 引導(dǎo)操作：清晰合理的操作引導(dǎo)，讓用戶能夠準(zhǔn)確地根據(jù)引導(dǎo)進(jìn)行下一步操作。
• 品牌價值：很多同學(xué)會忽略這一點(diǎn)，導(dǎo)致產(chǎn)品的界面與品牌關(guān)聯(lián)性差，整體界面沒有品牌感。

根據(jù)主體色推理同色系

同色系為統(tǒng)一的色相，使用中可以加深品牌色的感知，可以讓界面更有層次，同時可以讓界面保持色彩上的一致性，整體感較強(qiáng)，產(chǎn)生低對比度的和諧美感，給人協(xié)調(diào)統(tǒng)一的感覺。

具體是指與品牌色 H（色相）一致，通過改變 S（飽和度）與 B（明度）變化產(chǎn)生的色組。分別往淺色/深色方向按均勻數(shù)據(jù)增減，各產(chǎn)生5個坐標(biāo)值。

綜上能看出，使用同一色系即可完成一個項(xiàng)目，但是對于中大型項(xiàng)目來說實(shí)在是過于單調(diào)，沒有太多的層次感，因此我們需要多色搭配為輔。多色的輔助顏色可設(shè)定不同的任務(wù)屬性和情感表達(dá)，再搭配中性色黑白灰，能賦予更多的變化和層次。

提取24色-鋪墊輔助色

根據(jù)主體色 H（色相）為基礎(chǔ)，不斷地遞增、遞減 15，在 0-360 之間可以得出 24 個顏色，也就是將 360° 色環(huán)分割為 24 份，（24份在360°色環(huán)上，每一個色相的角度為15°），最終得到下圖24色。

選取輔助色

輔助色需要滿足的兩個條件：

和品牌色有明顯區(qū)分：避免所選輔助色感官上給用戶視覺區(qū)別與品牌色差距不大，傳遞的調(diào)性太過一致；

不能過于突兀：根據(jù)色彩原理，互補(bǔ)色是最能與品牌色本色產(chǎn)生視覺感官對比的顏色，但可能會有些突兀。為了讓顏色的輔助起到豐富畫面的作用，而不是反而讓整個版面顯得不和諧，所以選擇互補(bǔ)色的鄰近色作為輔助色，避免直接使用互補(bǔ)色。

• 鄰近色：色相差值 15° 以內(nèi)的顏色為鄰近色;
• 類似色：色相差值 30° 以內(nèi)的顏色為類似色;
• 互補(bǔ)色：色相差值 180° 的顏色為互補(bǔ)色。

基于品牌色可衍生出 3 個輔助色：一個與品牌色傳遞調(diào)性有明顯區(qū)分的類似色；兩個互補(bǔ)色的鄰近色。

類似色搭配：使用色相相近的顏色，頁面元素不會相互沖突，更加協(xié)調(diào)有質(zhì)感。

互補(bǔ)色搭配：選擇使用互補(bǔ)色，最佳搭配是一種作為主色，另一種用于強(qiáng)調(diào)。它們有著非常強(qiáng)烈的對比度，用在需要特別強(qiáng)調(diào)某個元素時會非常有效。

視覺統(tǒng)一感官校準(zhǔn)

每一種顏色都有自己的「感官明度」，也就是發(fā)光度。根據(jù)現(xiàn)有的使用場景，類似色和互補(bǔ)色大都用在同層級的信息展示上，而當(dāng)我們將最終得到的輔助色擺放在一起之后發(fā)現(xiàn)，雖然我們提取出的輔助色明度色值都一致，因?yàn)轭伾旧碜詭У母泄倜鞫葘傩杂兴鶇^(qū)別，導(dǎo)致視覺上會有明顯的明暗差別。需要通過發(fā)光度來進(jìn)行最終的顏色校正。

校準(zhǔn)方式：依次在輔助色上疊加一層純黑圖層，將該純黑圖層顏色模式調(diào)整為 Hue（色相），就可以通過無彩色系下的明度色值，進(jìn)行對比，使色彩視覺感官保持一致（青色和藍(lán)色屬冷色調(diào)，固需加深）。

全色系輸出

根據(jù)上面同色系的明度、純度對比規(guī)則，對所有定義的輔助色進(jìn)行明度和純度的輔助色彩輸出，最終得到輔助色色板。H（色相）一致，通過改變 S（飽和度）與 B（明度）變化產(chǎn)生色組。分別往淺色/深色方向按均勻數(shù)據(jù)增減，各產(chǎn)生5個坐標(biāo)值

刪除最左側(cè)的3種同色系，因明度過低時，顏色已經(jīng)非常接近于黑色，色相在肉眼上幾乎已經(jīng)趨于一致。最后得到基于品牌色推導(dǎo)出的全色系色階色板。

總結(jié)

配色常常從確定主色開始，根據(jù)行業(yè)類型和視覺訴求的需要，選擇一種居于支配的色彩作為主調(diào)色彩，構(gòu)成畫面的整體色彩傾向。然后選擇輔色，添加點(diǎn)綴色，最后按照色彩組合的原則完成設(shè)計中的需求。

雖然有了以上的配色方式，但一套標(biāo)準(zhǔn)的色彩系統(tǒng)還會包含中性色規(guī)范、顏色的使用規(guī)范等等。相信解決了大部分的需求，剩下的工作也難不倒大家了。畢竟以上的方式只是給大家提供了一個理性科學(xué)的方法，如果想更加優(yōu)秀，還需要進(jìn)一步深入地去學(xué)習(xí)色彩理論知識，多看優(yōu)秀的配色作品提升審美，總之要多看、多實(shí)踐和多思考。

文章來源：優(yōu)設(shè)    作者：能量眼球

藍(lán)藍(lán)設(shè)計( sillybuy.com )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)

沒有 switch 就沒有復(fù)雜的代碼塊

switch很方便：給定一個表達(dá)式，我們可以檢查它是否與一堆case子句中的其他表達(dá)式匹配。 考慮以下示例：

const name = "Juliana";

switch (name) {

 case "Juliana":

   console.log("She's Juliana");

   break;

 case "Tom":

   console.log("She's not Juliana");

   break;

}

當(dāng) name 為“Juliana”時，我們將打印一條消息，并立即中斷退出該塊。 在switch函數(shù)內(nèi)部時，直接在 case 塊使用 return，就可以省略break。

當(dāng)沒有匹配項(xiàng)時，可以使用 default 選項(xiàng)：

const name = "Kris";

switch (name) {

 case "Juliana":

   console.log("She's Juliana");

   break;

 case "Tom":

   console.log("She's not Juliana");

   break;

 default:

   console.log("Sorry, no match");

}

switch在 Redux reducers 中也大量使用（盡管Redux Toolkit簡化了樣板），以避免產(chǎn)生大量的if。 考慮以下示例：

const LOGIN_SUCCESS = "LOGIN_SUCCESS";

const LOGIN_FAILED = "LOGIN_FAILED";

const authState = {

 token: "",

 error: "",

};

function authReducer(state = authState, action) {

 switch (action.type) {

   case LOGIN_SUCCESS:

     return { ...state, token: action.payload };

   case LOGIN_FAILED:

     return { ...state, error: action.payload };

   default:

     return state;

 }

}

這有什么問題嗎?幾乎沒有。但是有沒有更好的選擇呢？

從 Python 獲得的啟示

來自 Telmo 的這條 Tweet引起了我的注意。 他展示了兩種“switch”風(fēng)格，其中一種非常接近Python中的模式。

Python 沒有開關(guān)，它給我們一個更好的替代方法。 首先讓我們將代碼從 JavaScript 移植到Python：

LOGIN_SUCCESS = "LOGIN_SUCCESS"

LOGIN_FAILED = "LOGIN_FAILED"

auth_state = {"token": "", "error": ""}

def auth_reducer(state=auth_state, action={}):

   mapping = {

       LOGIN_SUCCESS: {**state, "token": action["payload"]},

       LOGIN_FAILED: {**state, "error": action["payload"]},

   }

   return mapping.get(action["type"], state)

在 Python 中，我們可以使用字典來模擬switch 。 dict.get() 可以用來表示 switch 的 default 語句。

當(dāng)訪問不存在的key時，Python 會觸發(fā)一個 KeyError 錯誤：

>>> my_dict = {

   "name": "John",

   "city": "Rome",

   "age": 44

   }

>>> my_dict["not_here"]

# Output: KeyError: 'not_here'

.get()方法是一種更安全方法，因?yàn)樗粫l(fā)錯誤，并且可以為不存在的key指定默認(rèn)值：

>>> my_dict = {

   "name": "John",

   "city": "Rome",

   "age": 44

   }

>>> my_dict.get("not_here", "not found")

# Output: 'not found'

因此，Pytho n中的這一行：

return mapping.get(action["type"], state)

等價于 JavaScript中的：

function authReducer(state = authState, action) {

 ...

   default:

     return state;

 ...

}

使用字典的方式替換 switch

再次思考前面的示例：

const LOGIN_SUCCESS = "LOGIN_SUCCESS";

const LOGIN_FAILED = "LOGIN_FAILED";

const authState = {

 token: "",

 error: "",

};

function authReducer(state = authState, action) {

 switch (action.type) {

   case LOGIN_SUCCESS:

     return { ...state, token: action.payload };

   case LOGIN_FAILED:

     return { ...state, error: action.payload };

   default:

     return state;

 }

}

如果不使用 switch 我們可以這樣做：

function authReducer(state = authState, action) {

 const mapping = {

   [LOGIN_SUCCESS]: { ...state, token: action.payload },

   [LOGIN_FAILED]: { ...state, error: action.payload }

 };

 return mapping[action.type] || state;

}

這里我們使用 ES6 中的計算屬性，此處，mapping的屬性是根據(jù)兩個常量即時計算的：LOGIN_SUCCESS 和 LOGIN_FAILED。

屬性對應(yīng)的值，我們這里使用的是對象解構(gòu)，這里 ES9((ECMAScript 2018)) 出來的。

const mapping = {

 [LOGIN_SUCCESS]: { ...state, token: action.payload },

 [LOGIN_FAILED]: { ...state, error: action.payload }

}

你如何看待這種方法？它對 switch 來說可能還能一些限制，但對于 reducer 來說可能是一種更好的方案。

但是，此代碼的性能如何？

性能怎么樣？

switch 的性能優(yōu)于字典的寫法。我們可以使用下面的事例測試一下：

console.time("sample");

for (let i = 0; i < 2000000; i++) {

 const nextState = authReducer(authState, {

   type: LOGIN_SUCCESS,

   payload: "some_token"

 });

}

console.timeEnd("sample");

測量它們十次左右,

for t in {1..10}; do node switch.js >> switch.txt;done

for t in {1..10}; do node map.js >> map.txt;done

clipboard.png

人才們的 【三連】 就是小智不斷分享的最大動力，如果本篇博客有任何錯誤和建議，歡迎人才們留言，最后，謝謝大家的觀看。

原文：https://codeburst.io/alternat...

代碼部署后可能存在的BUG沒法實(shí)時知道，事后為了解決這些BUG，花了大量的時間進(jìn)行l(wèi)og 調(diào)試，這邊順便給大家推薦一個好用的BUG監(jiān)控工具 Fundebug。

藍(lán)藍(lán)設(shè)計( sillybuy.com )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)

一.什么是Vuex？

Vuex 是一個專為 Vue.js 應(yīng)用程序開發(fā)的狀態(tài)管理模式。它采用集中式存儲管理應(yīng)用的所有組件的狀態(tài)，并以相應(yīng)的規(guī)則保證狀態(tài)以一種可預(yù)測的方式發(fā)生變化。Vuex 也集成到 Vue 的官方調(diào)試工具 devtools extension，提供了諸如零配置的 time-travel 調(diào)試、狀態(tài)快照導(dǎo)入導(dǎo)出等高級調(diào)試功能。采用了全局單例模式，將組件的共享狀態(tài)抽離出來管理，使得組件樹中每一個位置都可以獲取共享的狀態(tài)或者觸發(fā)行為。
那么什么是狀態(tài)呢？我把狀態(tài)理解為在沒有使用vuex時，在當(dāng)前組件中data內(nèi)需要共用的數(shù)據(jù)為狀態(tài)。
vuex使得狀態(tài)或行為成為了共享的狀態(tài)，所共享的狀態(tài)或行為可以在各個組件中都可以訪問到，省去了子父或子子之間傳遞變量，提高了開發(fā)效率。

二.不使用vuex時與使用vuex時的差別

當(dāng)我們不使用vuex時，對于組件之間傳遞信息會較為麻煩。

不使用vuex時

父子之間傳遞信息：

App.vue文件中：

<template>
  <div id="app">
      <Fruits :fruitList="fruitList"/>
  </div>
</template> 
<script> import Goods from './components/Goods'; export default { name: 'App',
  components:{
    Fruits,
    Goods
  }, data(){
    return{ goodList:[
      {
        name:'doll',
        price:12 },
      { name:'glass',
        price:10 }
    ],
    }
  }
}
</script>
<style>
</style>

Good.vue文件中：

<template>
  <div class="hello">
      <ul>
        <li v-for="(good,index) in goodList" :key="index"> name:{{good.name}} number: {{good.number}} {{index}}
        </li>
      </ul>
  </div>
</template>

<script> export default { props:['goodList'],
}
</script>
<style>

</style>

兄弟之間傳遞信息：

首先先創(chuàng)建一個js文件作為兩兄弟之間傳輸?shù)募~扣，這里起名為msg.js

//創(chuàng)建并暴露vue import Vue from 'vue';
export default new Vue

兄弟組件Goods：

<template>
  <div>
        <button @click="deliver">點(diǎn)擊</button>
  </div>
</template>

<script> import MSG from '../msg';
export default {
  data(){ return{
      msg:'hahah' }
  },
  methods:{
    deliver() {
        MSG.$emit('showMsg',this.msg)
    }
  }

}
</script>
<style>

</style>

兄弟組件Fruits:

<template>
  <div>
      <div class="fruit">
          {{text}}
      </div>
  </div>
</template>
<script> import MSG from '../msg';
export default {
    data(){ return{
        text:'' }
    },
    created(){ this.getMsg()
    },
    methods:{
      getMsg(){
        MSG.$on('showMsg',(message)=>{ this.text = message
        })
      }
    }
}
</script>
<style>
</style>

在App組件中的代碼：

點(diǎn)擊按鈕:

藍(lán)藍(lán)設(shè)計( sillybuy.com )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)

一套 UI 界面當(dāng)中，核心的 APP 圖標(biāo)是用戶每天都要接觸、經(jīng)常使用的視覺組件和交互對象。設(shè)計圖標(biāo)的時候，要用到大家最熟悉的元素才能貼合用戶認(rèn)知，要醒目、統(tǒng)一，也要足夠「隱形」，避免喧賓奪主。今天這篇文章，來自著名的 Tubik Studio 團(tuán)隊，他們?yōu)槿A為旗下的 EMUI 10 系統(tǒng)設(shè)計了核心的圖標(biāo)系統(tǒng)，來看看他們的設(shè)計過程吧。

我們總不會低估一個操作系統(tǒng)基礎(chǔ)圖標(biāo)，對于產(chǎn)品的可用性和合意性的影響?；A(chǔ)圖標(biāo)雖然小巧，但是對于整個操作系統(tǒng)而言，總是極具影響力的，因?yàn)樗麄兪怯脩艚缑娴暮诵脑?，幫助用戶快速直觀地在系統(tǒng)中定位、瀏覽、導(dǎo)航。但是，對于設(shè)計師而言，圖標(biāo)的設(shè)計始終是挑戰(zhàn)，它看起來最為簡單，但實(shí)則為最為艱難的工作。

圖標(biāo)需要，讓人一目了然，但是也要具備良好的可識別性，在傳統(tǒng)和創(chuàng)新之間達(dá)到平衡。這一次，Tubik Studio 設(shè)計團(tuán)隊將要給華為的 EMUI 10 來設(shè)計圖標(biāo)，而這篇文章將會為你揭示背后的設(shè)計過程。

這次的項(xiàng)目主要是由 Sergii Valiukh 、Arthur Avakyan 和 Polina Taran 來負(fù)責(zé)。這次的設(shè)計項(xiàng)目從最初的探索構(gòu)思入手，逐漸開始繪制草圖，探索樣式，一直到最后打磨，完成設(shè)計。

項(xiàng)目內(nèi)容

為華為 EMUI 10 系統(tǒng)的用戶界面設(shè)計基礎(chǔ)的圖標(biāo)

客戶介紹

我們在 2019 年夏季，收到了來自華為的邀約，這次的項(xiàng)目要重新設(shè)計 EMUI 這套基于 Android 系統(tǒng)的用戶界面基礎(chǔ)圖標(biāo)，這套圖標(biāo)會用來適配華為旗下的旗艦手機(jī)，這些圖標(biāo)將會隨著新版的系統(tǒng)部署到這些手機(jī)產(chǎn)品當(dāng)中。我們的任務(wù)，是創(chuàng)建總計 54 款符合當(dāng)下潮流趨勢的圖標(biāo)，這些圖標(biāo)要能夠貼合品牌和已有用戶的偏好，并且能夠吸引新的用戶。

這個圖標(biāo)設(shè)計項(xiàng)目如今已經(jīng)在當(dāng)下的華為旗下手機(jī)產(chǎn)品中應(yīng)用且部署好了，最早使用這套圖標(biāo)的智能手機(jī)型號為 Mate 30 ，緊接其后的是 P40。

設(shè)計過程

在整個操作系統(tǒng)中，這些圖標(biāo)是始終位于用戶視野以內(nèi)、最基礎(chǔ)的最核心的交互元素，通常用戶每天都會同這些核心的基礎(chǔ) APP 進(jìn)行交互，有時候一天多達(dá)幾十次，因此它們應(yīng)當(dāng)具備良好的功能性，還應(yīng)該足夠美觀，給用戶帶來滿足感。同時，這套圖標(biāo)的設(shè)計，也應(yīng)當(dāng)足夠統(tǒng)一，以協(xié)調(diào)的體驗(yàn)切入到整個 EMUI 的設(shè)計系統(tǒng)當(dāng)中，貼合整體的樣式特征。

所以，我們使用了一整套圖標(biāo)網(wǎng)格系統(tǒng)，應(yīng)對不同需求，在設(shè)計的過程中，這套網(wǎng)格有助于確保所有圖標(biāo)外部尺寸的一致性，也保證了內(nèi)部元素的統(tǒng)一性。

為了發(fā)掘全新的視角，我們決定從傳統(tǒng)的手繪圖標(biāo)開始，尋找重新塑造圖標(biāo)設(shè)計的方法。這些圖標(biāo)所涉及到的元素，早已為全球數(shù)百萬用戶所熟知，要重新設(shè)計圖標(biāo)外觀，并且還要成套且統(tǒng)一，這本身就是一個巨大的挑戰(zhàn)。

比如「電話」圖標(biāo)所對應(yīng)的聽筒元素、「信息」圖標(biāo)所對應(yīng)的氣泡對話框這樣的元素，是不可能完全拋棄重新創(chuàng)造的，所以我們的真正的切入點(diǎn)是在形態(tài)和色彩上尋求解決方案。

越是簡單的東西，重塑起來就越難。

在實(shí)際的設(shè)計過程中，我們嘗試了數(shù)以百計的造型變體，從完全放飛、非常規(guī)的的外部造型，到極其常規(guī)，大家熟知的造型解決方案，我們都逐一試過。而在色彩上的嘗試相對會顯得更加具有實(shí)驗(yàn)性：我們嘗試使用明亮的紫羅蘭色、栗色和淺綠色來進(jìn)行混搭。

當(dāng)然，我們很清楚，這樣的實(shí)驗(yàn)性的工作是探索過程中的一小步，但是它是必須的，是創(chuàng)造新設(shè)計的種子，是尋求正確答案的必經(jīng)之路。

在設(shè)計過程在，有一件有趣的事情發(fā)生在設(shè)計「相機(jī)」圖標(biāo)的過程中。我們嘗試過很多不同的圖標(biāo)造型，不同的元素，不同的樣式，但是其中始終有一個細(xì)節(jié)是不變的，那就是右上角的小紅點(diǎn)。這是為了暗示用戶，華為的攝像頭模組來自徠卡，這個紅色的小點(diǎn)就是向其致敬的標(biāo)識。

而下面的概念設(shè)計，則是強(qiáng)化了圖標(biāo)之間的幾何輪廓的差異，從而提升圖標(biāo)在智能手機(jī)屏幕上的對比度和識別度。

下一步，我們基于幾何圖形外觀差異性，設(shè)計了多種造型不同但同樣優(yōu)雅的圖標(biāo)。在基于這種風(fēng)格概念進(jìn)行延伸的過程中，我們會優(yōu)先考慮圓形的元素。而「天氣」圖標(biāo)明顯既不適合圓形也不適合方形來呈現(xiàn)，所以我們使用的是云和太陽兩種元素的組合。「錢包」圖標(biāo)使用的是矩形，然后搭配卡片的組合。盡管造型整體上是相對自由的，但是所有的圖標(biāo)都是遵循圖標(biāo)網(wǎng)格，并且在視覺權(quán)重上盡可能統(tǒng)一。

在色彩和樣式上，我們則更加傾向于漸變。沒有色彩漸變，純扁平的圖標(biāo)顯得過于幼稚和「古早」，沒有足夠的品質(zhì)感，所以，我們在新的圖標(biāo)設(shè)計上，開始加入漸變色彩，提升質(zhì)感。

不過，在最終版本當(dāng)中，我們還是保留了圖標(biāo)外部的圓角矩形的外輪廓，然后將圖標(biāo)元素的內(nèi)徑進(jìn)行了適當(dāng)?shù)乜s減，漸變和核心的簡約幾何特征依然是整套設(shè)計的最高優(yōu)先級。

這套設(shè)計方案展現(xiàn)了在整套 UI 界面中，圖標(biāo)這個小元素的設(shè)計上所需要投入的精力和潛在的難度。想要圖標(biāo)足夠協(xié)調(diào)、美觀、易用還要貼合品牌特征、還要區(qū)別于以往，是一件相當(dāng)不容易的事情。

細(xì)節(jié)里藏著魔鬼，任何細(xì)小的元素、線條輪廓、色彩的變化都可能會在屏幕上放大、被感知到。

藍(lán)藍(lán)設(shè)計( sillybuy.com )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)

作為公民，我們在用我們擅長的設(shè)計去服務(wù)社會，在這個過程中形成自己的積淀。這是不可用金錢來衡量的價值。

作者：藍(lán)藍(lán)

  藍(lán)藍(lán)設(shè)計( sillybuy.com )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)

文章來源：站酷    作者：百度MEUX

藍(lán)藍(lán)設(shè)計( sillybuy.com )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)

我們先看?組來??優(yōu)的2019年6?的調(diào)研數(shù)據(jù)：70%的美國?認(rèn)為，與5年前相?個?信息變得更不安全。尤其是?學(xué)歷?收?群體。由此可??戶對個?信息數(shù)據(jù)的隱私擔(dān)憂?以往更甚。

?戶隱私安全很重要，涉及的范圍和?度也很多。本次的分析從?戶體驗(yàn)?度切?，涉及如下三個??：

1. Incognito Mode匿名模式；

2. Reducing Permanence減少永久性；

3. Reducing Publicity減少公開性。

01 匿名模式

下圖是Google系A(chǔ)pp(Google AppChromeYouTubeandGoogle Map)匿名模式切換，從交互體驗(yàn)上來說有如下?個特點(diǎn)：

1. 統(tǒng)?在右上?；

2. 可以便捷切換?匿名模式，反過來也很容易切回登陸狀態(tài)；

3. 匿名模式的狀態(tài)提示，例如YouTube 在匿名模式下在界?底部有?字提示“您 當(dāng)前處于匿名模式”。

匿名模式不是最近才流?的功能，最早提供隱匿模式的是蘋果safari瀏覽器，早在 2005年就?持了匿名模式。Chrome瀏覽器在2008年就開始?持此模式。雖然由來已久，為什么到了2020年，匿名模式依然是國外互聯(lián)???趨勢呢？

我們看?組數(shù)據(jù)：

這是來?DuckDuckGo 2019年9?的調(diào)研（DuckDuckGo是美國的?款不記錄?戶?為保護(hù)?戶隱私的搜索引擎）。樣本來?美國、英國、德國和澳?利亞的成年??戶，共計3,411?的調(diào)研得出。各國?戶對使?搜索引擎的個?隱私安全?常在意（是否搜集個?的數(shù)據(jù)和記錄搜索?為）。

2020年5?DuckDuckGo?均搜索次數(shù)為6200萬。對?看2019年11?底?均搜索次數(shù)4900萬，2018年10?是2900萬。

最近?年的持續(xù)活躍度?幅增?證明了不記錄個?隱私的搜素引擎越來越受到?戶的?睞。

國內(nèi)，頭條、UC瀏覽器在搜索框輸?狀態(tài)也提供了“?痕瀏覽”??。

不僅是搜索引擎領(lǐng)域，保護(hù)?戶隱私也成為Facebook最重要的戰(zhàn)略?向之?。Facebook CEO Mark Zuckerberg在2019年 F8開發(fā)者?會上喊出“THE FUTURE IS PRIVATE”。2019年3?Mark Zuckerberg發(fā)?，主題就是《聚焦于保護(hù)隱私的社交?絡(luò)》。

02 減少永久性

我們先看國外社交媒體Stories（?故事）產(chǎn)品形態(tài)的流?。

?們總是對于所分享的內(nèi)容永遠(yuǎn)記錄在?上感到擔(dān)憂。Stories24?時消失緩解了?們的隱私顧慮，這讓?戶更安?地?然分享。

Stories由Snapchat?創(chuàng)，由 Facebook發(fā)揚(yáng)光?。早在2019年4?，F(xiàn)acebook+Messenger Stories, Instagram Stories?活?戶數(shù)就突破5億。 2020年2-3?LinkedIn，Twitter也先后宣布將上線類似功能。

03 減少公開性

來??優(yōu)的調(diào)研報告：41%的美國?經(jīng)歷過?絡(luò)騷擾，最常?的就是在社交媒體上。23%的?戶最近經(jīng)歷的?絡(luò)騷擾來?評論區(qū)的評論內(nèi)容。27%的?戶經(jīng)歷?絡(luò)騷擾后決定不再發(fā)布任何內(nèi)容。

我們以限定評論互動的公開性為例：

2020年5?Twitter上線了新的評論功能，可以限定誰可以回復(fù)帖?的功能，提供了三種選項(xiàng)：誰都可以評論，只有被關(guān)注者可以評論，只有被提及者可以評論三種公開度的限定。

Instagram也在測試“評論限制”新功能，批量屏蔽/限制評論。?前已經(jīng)上線的?個例?：?戶（評論發(fā)布者）如果發(fā)布的評論含有攻擊性敏感詞，發(fā)布前伴有提示，提醒評論含有攻擊性敏感詞是否真的要發(fā)布。

注重隱私提供僅好友可?/僅??可?/僅作者可?/等多重維度的隱私設(shè)定有助于?戶更安?地參與互動。

另外?個例?是付費(fèi)頻道會員：付費(fèi)頻道會員-限定頻道的公開性讓內(nèi)容創(chuàng)作者減輕隱私顧慮不僅能獲得?告收?，也能得到來?會員、會費(fèi)的收?，形成“忠實(shí)粉絲”社區(qū)，有助于內(nèi)容?態(tài)的社區(qū)化建設(shè)。

我們主要看YouTube的頻道會員案例：

YouTube有兩種會員模式。?種是YouTube整個平臺的付費(fèi)會員，去?告，看原創(chuàng)美劇影視，消費(fèi)?樂，可下載內(nèi)容的模式。第?種模式是Youtuber個?頻道付費(fèi)會員，吸引忠實(shí)粉絲加?。我想說的就是第?種。

為什么?V?紅有意愿開通頻道會員？

除了獲得忠實(shí)粉絲收?變現(xiàn)的商業(yè)價值以及付費(fèi)頻道會員可以為忠實(shí)粉絲提供各種專屬功能，背后也和?紅?V對個?隱私顧慮有關(guān)。

?紅?V在完全公開的社交?絡(luò)上需要始終保持?夠克制謹(jǐn)慎，避免引起爭議。但在忠實(shí)粉絲付費(fèi)頻道專屬會員群中，?紅?V會減輕隱私顧慮，更加回歸?我。

?如在頻道會員中發(fā)布更多與個??活相關(guān)的內(nèi)容，表達(dá)更多不便在完全公開的社交?絡(luò)中的想法和感受等，因?yàn)橹覍?shí)粉絲通常更具包容度，更不容易引起爭議。

YouTube頻道會員費(fèi)?可以從三種會費(fèi)（按?）區(qū)間選擇，?持多選：

1. 低階 Low Levels $0.99~3.99;

2. 中階 Medium Levels $4.99~14.99;

3. ?階 High Levels $19.99~49.99;

頻道會員功能在2018年開始測試，?向粉絲數(shù)過10萬的YouTuber開放。

以上綜述，我們可以說：

1.匿名模式：

雖然匿名模式由來已久，但仍然是當(dāng)前的??基本?戶體驗(yàn)設(shè)計趨勢，尤其是匿名模式的切換便捷性?常重要。

2.減少永久性：

Stories?故事24?時消失緩解了?們的隱私顧慮，這讓?戶更安?地?然分享,已經(jīng)成為國外社交媒體平臺的必備功能，F(xiàn)acebook， Instagram平臺的最主要、最具影響?的功能之?。

3.減少公開性：

?戶總是對在社交媒體平臺發(fā)表評論有所顧忌，限定評論的公開性能夠有助于促進(jìn)?戶發(fā)帖表達(dá)，其他?戶也可以更安?地參與互動。

付費(fèi)頻道會員可以限定頻道的公開性，讓內(nèi)容創(chuàng)作者減輕隱私顧慮不僅能獲得?告收?，也能得到來?會員會費(fèi)的收?，形成“忠實(shí)粉絲”社區(qū)，有助于內(nèi)容?態(tài)的社區(qū)化建設(shè)。

從UE?度，我們可以為頻道會員提供專屬身份設(shè)計例如專屬徽章，專屬表情等。

THE FUTURE IS PRIVATE， 注重?戶隱私的體驗(yàn)設(shè)計越來越重要！

文章來源：站酷    作者：百度MEUX

藍(lán)藍(lán)設(shè)計( sillybuy.com )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)

凡是要知其然知其所以然

文件上傳相信很多朋友都有遇到過，那或許你也遇到過當(dāng)上傳大文件時，上傳時間較長，且經(jīng)常失敗的困擾，并且失敗后，又得重新上傳很是煩人。那我們先了解下失敗的原因吧！

據(jù)我了解大概有以下原因：

服務(wù)器配置:例如在PHP中默認(rèn)的文件上傳大小為8M【post_max_size = 8m】，若你在一個請求體中放入8M以上的內(nèi)容時，便會出現(xiàn)異常

請求超時：當(dāng)你設(shè)置了接口的超時時間為10s，那么上傳大文件時，一個接口響應(yīng)時間超過10s，那么便會被Faild掉。

網(wǎng)絡(luò)波動：這個就屬于不可控因素，也是較常見的問題。

基于以上原因，聰明的人們就想到了，將文件拆分多個小文件，依次上傳，不就解決以上1,2問題嘛，這便是分片上傳。 網(wǎng)絡(luò)波動這個實(shí)在不可控，也許一陣大風(fēng)刮來，就斷網(wǎng)了呢。那這樣好了，既然斷網(wǎng)無法控制，那我可以控制只上傳已經(jīng)上傳的文件內(nèi)容，不就好了，這樣大大加快了重新上傳的速度。所以便有了“斷點(diǎn)續(xù)傳”一說。此時，人群中有人插了一嘴，有些文件我已經(jīng)上傳一遍了，為啥還要在上傳，能不能不浪費(fèi)我流量和時間。喔...這個嘛，簡單，每次上傳時判斷下是否存在這個文件，若存在就不重新上傳便可，于是又有了“秒傳”一說。從此這"三兄弟" 便自行CP，統(tǒng)治了整個文件界?！?

注意文中的代碼并非實(shí)際代碼，請移步至github查看代碼

https://github.com/pseudo-god...

分片上傳

HTML

原生INPUT樣式較丑，這里通過樣式疊加的方式，放一個Button.

 <div class="btns">

   <el-button-group>

     <el-button :disabled="changeDisabled">

       <i class="el-icon-upload2 el-icon--left" size="mini"></i>選擇文件

       <input

         v-if="!changeDisabled"

         type="file"

         :multiple="multiple"

         class="select-file-input"

         :accept="accept"

         @change="handleFileChange"

       />

     </el-button>

     <el-button :disabled="uploadDisabled" @click="handleUpload()"><i class="el-icon-upload el-icon--left" size="mini"></i>上傳</el-button>

     <el-button :disabled="pauseDisabled" @click="handlePause"><i class="el-icon-video-pause el-icon--left" size="mini"></i>暫停</el-button>

     <el-button :disabled="resumeDisabled" @click="handleResume"><i class="el-icon-video-play el-icon--left" size="mini"></i>恢復(fù)</el-button>

     <el-button :disabled="clearDisabled" @click="clearFiles"><i class="el-icon-video-play el-icon--left" size="mini"></i>清空</el-button>

   </el-button-group>

   <slot

//data 數(shù)據(jù)

var chunkSize = 10 * 1024 * 1024; // 切片大小

var fileIndex = 0; // 當(dāng)前正在被遍歷的文件下標(biāo)

data: () => ({

   container: {

     files: null

   },

   tempFilesArr: [], // 存儲files信息

   cancels: [], // 存儲要取消的請求

   tempThreads: 3,

   // 默認(rèn)狀態(tài)

   status: Status.wait

 }),

一個稍微好看的UI就出來了。

選擇文件

選擇文件過程中，需要對外暴露出幾個鉤子，熟悉elementUi的同學(xué)應(yīng)該很眼熟，這幾個鉤子基本與其一致。onExceed:文件超出個數(shù)限制時的鉤子、beforeUpload：文件上傳之前

fileIndex 這個很重要，因?yàn)槭嵌辔募蟼?，所以定位?dāng)前正在被上傳的文件就很重要，基本都靠它

handleFileChange(e) {

 const files = e.target.files;

 if (!files) return;

 Object.assign(this.$data, this.$options.data()); // 重置data所有數(shù)據(jù)

 fileIndex = 0; // 重置文件下標(biāo)

 this.container.files = files;

 // 判斷文件選擇的個數(shù)

 if (this.limit && this.container.files.length > this.limit) {

   this.onExceed && this.onExceed(files);

   return;

 }

 // 因filelist不可編輯，故拷貝filelist 對象

 var index = 0; // 所選文件的下標(biāo)，主要用于剔除文件后，原文件list與臨時文件list不對應(yīng)的情況

 for (const key in this.container.files) {

   if (this.container.files.hasOwnProperty(key)) {

     const file = this.container.files[key];

     if (this.beforeUpload) {

       const before = this.beforeUpload(file);

       if (before) {

         this.pushTempFile(file, index);

       }

     }

     if (!this.beforeUpload) {

       this.pushTempFile(file, index);

     }

     index++;

   }

 }

},

// 存入 tempFilesArr，為了上面的鉤子，所以將代碼做了拆分

pushTempFile(file, index) {

 // 額外的初始值

 const obj = {

   status: fileStatus.wait,

   chunkList: [],

   uploadProgress: 0,

   hashProgress: 0,

   index

 };

 for (const k in file) {

   obj[k] = file[k];

 }

 console.log('pushTempFile -> obj', obj);

 this.tempFilesArr.push(obj);

}

分片上傳

創(chuàng)建切片，循環(huán)分解文件即可

 createFileChunk(file, size = chunkSize) {

   const fileChunkList = [];

   var count = 0;

   while (count < file.size) {

     fileChunkList.push({

       file: file.slice(count, count + size)

     });

     count += size;

   }

   return fileChunkList;

 }

循環(huán)創(chuàng)建切片,既然咱們做的是多文件，所以這里就有循環(huán)去處理，依次創(chuàng)建文件切片，及切片的上傳。

async handleUpload(resume) {

 if (!this.container.files) return;

 this.status = Status.uploading;

 const filesArr = this.container.files;

 var tempFilesArr = this.tempFilesArr;

 for (let i = 0; i < tempFilesArr.length; i++) {

   fileIndex = i;

   //創(chuàng)建切片

   const fileChunkList = this.createFileChunk(

     filesArr[tempFilesArr[i].index]

   );

   tempFilesArr[i].fileHash ='xxxx'; // 先不用看這個，后面會講，占個位置

   tempFilesArr[i].chunkList = fileChunkList.map(({ file }, index) => ({

     fileHash: tempFilesArr[i].hash,

     fileName: tempFilesArr[i].name,

     index,

     hash: tempFilesArr[i].hash + '-' + index,

     chunk: file,

     size: file.size,

     uploaded: false,

     progress: 0, // 每個塊的上傳進(jìn)度

     status: 'wait' // 上傳狀態(tài)，用作進(jìn)度狀態(tài)顯示

   }));

   //上傳切片

   await this.uploadChunks(this.tempFilesArr[i]);

 }

}

上傳切片，這個里需要考慮的問題較多，也算是核心吧，uploadChunks方法只負(fù)責(zé)構(gòu)造傳遞給后端的數(shù)據(jù)，核心上傳功能放到sendRequest方法中

async uploadChunks(data) {

 var chunkData = data.chunkList;

 const requestDataList = chunkData

   .map(({ fileHash, chunk, fileName, index }) => {

     const formData = new FormData();

     formData.append('md5', fileHash);

     formData.append('file', chunk);

     formData.append('fileName', index); // 文件名使用切片的下標(biāo)

     return { formData, index, fileName };

   });

 try {

   await this.sendRequest(requestDataList, chunkData);

 } catch (error) {

   // 上傳有被reject的

   this.$message.error('親 上傳失敗了,考慮重試下呦' + error);

   return;

 }

 // 合并切片

 const isUpload = chunkData.some(item => item.uploaded === false);

 console.log('created -> isUpload', isUpload);

 if (isUpload) {

   alert('存在失敗的切片');

 } else {

   // 執(zhí)行合并

   await this.mergeRequest(data);

 }

}

sendReques。上傳這是最重要的地方，也是容易失敗的地方,假設(shè)有10個分片，那我們?nèi)羰侵苯影l(fā)10個請求的話，很容易達(dá)到瀏覽器的瓶頸，所以需要對請求進(jìn)行并發(fā)處理。

并發(fā)處理：這里我使用for循環(huán)控制并發(fā)的初始并發(fā)數(shù)，然后在 handler 函數(shù)里調(diào)用自己，這樣就控制了并發(fā)。在handler中，通過數(shù)組API.shift模擬隊列的效果，來上傳切片。

重試: retryArr 數(shù)組存儲每個切片文件請求的重試次數(shù)，做累加。比如[1,0,2],就是第0個文件切片報錯1次，第2個報錯2次。為保證能與文件做對應(yīng)，const index = formInfo.index; 我們直接從數(shù)據(jù)中拿之前定義好的index。 若失敗后，將失敗的請求重新加入隊列即可。

關(guān)于并發(fā)及重試我寫了一個小Demo,若不理解可以自己在研究下，文件地址：https://github.com/pseudo-god... , 重試代碼好像被我弄丟了，大家要是有需求，我再補(bǔ)吧！

   // 并發(fā)處理

sendRequest(forms, chunkData) {

 var finished = 0;

 const total = forms.length;

 const that = this;

 const retryArr = []; // 數(shù)組存儲每個文件hash請求的重試次數(shù)，做累加 比如[1,0,2],就是第0個文件切片報錯1次，第2個報錯2次

 return new Promise((resolve, reject) => {

   const handler = () => {

     if (forms.length) {

       // 出棧

       const formInfo = forms.shift();

       const formData = formInfo.formData;

       const index = formInfo.index;

       instance.post('fileChunk', formData, {

         onUploadProgress: that.createProgresshandler(chunkData[index]),

         cancelToken: new CancelToken(c => this.cancels.push(c)),

         timeout: 0

       }).then(res => {

         console.log('handler -> res', res);

         // 更改狀態(tài)

         chunkData[index].uploaded = true;

         chunkData[index].status = 'success';

         finished++;

         handler();

       })

         .catch(e => {

           // 若暫停，則禁止重試

           if (this.status === Status.pause) return;

           if (typeof retryArr[index] !== 'number') {

             retryArr[index] = 0;

           }

           // 更新狀態(tài)

           chunkData[index].status = 'warning';

           // 累加錯誤次數(shù)

           retryArr[index]++;

           // 重試3次

           if (retryArr[index] >= this.chunkRetry) {

             return reject('重試失敗', retryArr);

           }

           this.tempThreads++; // 釋放當(dāng)前占用的通道

           // 將失敗的重新加入隊列

           forms.push(formInfo);

           handler();

         });

     }

     if (finished >= total) {

       resolve('done');

     }

   };

   // 控制并發(fā)

   for (let i = 0; i < this.tempThreads; i++) {

     handler();

   }

 });

}

切片的上傳進(jìn)度，通過axios的onUploadProgress事件，結(jié)合createProgresshandler方法進(jìn)行維護(hù)

// 切片上傳進(jìn)度

createProgresshandler(item) {

 return p => {

   item.progress = parseInt(String((p.loaded / p.total) * 100));

   this.fileProgress();

 };

}

Hash計算

其實(shí)就是算一個文件的MD5值，MD5在整個項(xiàng)目中用到的地方也就幾點(diǎn)。

秒傳，需要通過MD5值判斷文件是否已存在。

續(xù)傳：需要用到MD5作為key值，當(dāng)唯一值使用。

本項(xiàng)目主要使用worker處理，性能及速度都會有很大提升.

由于是多文件，所以HASH的計算進(jìn)度也要體現(xiàn)在每個文件上，所以這里使用全局變量fileIndex來定位當(dāng)前正在被上傳的文件

執(zhí)行計算hash

正在上傳文件

// 生成文件 hash（web-worker）

calculateHash(fileChunkList) {

 return new Promise(resolve => {

   this.container.worker = new Worker('./hash.js');

   this.container.worker.postMessage({ fileChunkList });

   this.container.worker.onmessage = e => {

     const { percentage, hash } = e.data;

     if (this.tempFilesArr[fileIndex]) {

       this.tempFilesArr[fileIndex].hashProgress = Number(

         percentage.toFixed(0)

       );

     }

     if (hash) {

       resolve(hash);

     }

   };

 });

}

因使用worker，所以我們不能直接使用NPM包方式使用MD5。需要單獨(dú)去下載spark-md5.js文件，并引入

//hash.js

self.importScripts("/spark-md5.min.js"); // 導(dǎo)入腳本

// 生成文件 hash

self.onmessage = e => {

 const { fileChunkList } = e.data;

 const spark = new self.SparkMD5.ArrayBuffer();

 let percentage = 0;

 let count = 0;

 const loadNext = index => {

   const reader = new FileReader();

   reader.readAsArrayBuffer(fileChunkList[index].file);

   reader.onload = e => {

     count++;

     spark.append(e.target.result);

     if (count === fileChunkList.length) {

       self.postMessage({

         percentage: 100,

         hash: spark.end()

       });

       self.close();

     } else {

       percentage += 100 / fileChunkList.length;

       self.postMessage({

         percentage

       });

       loadNext(count);

     }

   };

 };

 loadNext(0);

};

文件合并

當(dāng)我們的切片全部上傳完畢后，就需要進(jìn)行文件的合并，這里我們只需要請求接口即可

mergeRequest(data) {

  const obj = {

    md5: data.fileHash,

    fileName: data.name,

    fileChunkNum: data.chunkList.length

  };

  instance.post('fileChunk/merge', obj,

    {

      timeout: 0

    })

    .then((res) => {

      this.$message.success('上傳成功');

    });

}

Done: 至此一個分片上傳的功能便已完成

斷點(diǎn)續(xù)傳

顧名思義，就是從那斷的就從那開始，明確思路就很簡單了。一般有2種方式，一種為服務(wù)器端返回，告知我從那開始，還有一種是瀏覽器端自行處理。2種方案各有優(yōu)缺點(diǎn)。本項(xiàng)目使用第二種。

思路：已文件HASH為key值，每個切片上傳成功后，記錄下來便可。若需要續(xù)傳時，直接跳過記錄中已存在的便可。本項(xiàng)目將使用Localstorage進(jìn)行存儲,這里我已提前封裝好addChunkStorage、getChunkStorage方法。

存儲在Stroage的數(shù)據(jù)

緩存處理

在切片上傳的axios成功回調(diào)中，存儲已上傳成功的切片

instance.post('fileChunk', formData, )

 .then(res => {

   // 存儲已上傳的切片下標(biāo)

+ this.addChunkStorage(chunkData[index].fileHash, index);

   handler();

 })

在切片上傳前，先看下localstorage中是否存在已上傳的切片,并修改uploaded

   async handleUpload(resume) {

+      const getChunkStorage = this.getChunkStorage(tempFilesArr[i].hash);

     tempFilesArr[i].chunkList = fileChunkList.map(({ file }, index) => ({

+        uploaded: getChunkStorage && getChunkStorage.includes(index), // 標(biāo)識：是否已完成上傳

+        progress: getChunkStorage && getChunkStorage.includes(index) ? 100 : 0,

+        status: getChunkStorage && getChunkStorage.includes(index)? 'success'

+              : 'wait' // 上傳狀態(tài)，用作進(jìn)度狀態(tài)顯示

     }));

   }

構(gòu)造切片數(shù)據(jù)時，過濾掉uploaded為true的

async uploadChunks(data) {

 var chunkData = data.chunkList;

 const requestDataList = chunkData

+    .filter(({ uploaded }) => !uploaded)

   .map(({ fileHash, chunk, fileName, index }) => {

     const formData = new FormData();

     formData.append('md5', fileHash);

     formData.append('file', chunk);

     formData.append('fileName', index); // 文件名使用切片的下標(biāo)

     return { formData, index, fileName };

   })

}

垃圾文件清理

隨著上傳文件的增多，相應(yīng)的垃圾文件也會增多，比如有些時候上傳一半就不再繼續(xù)，或上傳失敗，碎片文件就會增多。解決方案我目前想了2種

前端在localstorage設(shè)置緩存時間，超過時間就發(fā)送請求通知后端清理碎片文件，同時前端也要清理緩存。

前后端都約定好，每個緩存從生成開始，只能存儲12小時，12小時后自動清理

以上2中方案似乎都有點(diǎn)問題，極有可能造成前后端因時間差，引發(fā)切片上傳異常的問題，后面想到合適的解決方案再來更新吧。

Done: 續(xù)傳到這里也就完成了。

秒傳

這算是最簡單的，只是聽起來很厲害的樣子。原理：計算整個文件的HASH，在執(zhí)行上傳操作前，向服務(wù)端發(fā)送請求，傳遞MD5值，后端進(jìn)行文件檢索。若服務(wù)器中已存在該文件，便不進(jìn)行后續(xù)的任何操作，上傳也便直接結(jié)束。大家一看就明白

async handleUpload(resume) {

   if (!this.container.files) return;

   const filesArr = this.container.files;

   var tempFilesArr = this.tempFilesArr;

   for (let i = 0; i < tempFilesArr.length; i++) {

     const fileChunkList = this.createFileChunk(

       filesArr[tempFilesArr[i].index]

     );

     // hash校驗(yàn)，是否為秒傳

+      tempFilesArr[i].hash = await this.calculateHash(fileChunkList);

+      const verifyRes = await this.verifyUpload(

+        tempFilesArr[i].name,

+        tempFilesArr[i].hash

+      );

+      if (verifyRes.data.presence) {

+       tempFilesArr[i].status = fileStatus.secondPass;

+       tempFilesArr[i].uploadProgress = 100;

+      } else {

       console.log('開始上傳切片文件----》', tempFilesArr[i].name);

       await this.uploadChunks(this.tempFilesArr[i]);

     }

   }

 }

 // 文件上傳之前的校驗(yàn)： 校驗(yàn)文件是否已存在

 verifyUpload(fileName, fileHash) {

   return new Promise(resolve => {

     const obj = {

       md5: fileHash,

       fileName,

       ...this.uploadArguments //傳遞其他參數(shù)

     };

     instance

       .post('fileChunk/presence', obj)

       .then(res => {

         resolve(res.data);

       })

       .catch(err => {

         console.log('verifyUpload -> err', err);

       });

   });

 }

Done: 秒傳到這里也就完成了。

后端處理

文章好像有點(diǎn)長了，具體代碼邏輯就先不貼了，除非有人留言要求，嘻嘻，有時間再更新

Node版

請前往 https://github.com/pseudo-god... 查看

JAVA版

下周應(yīng)該會更新處理

PHP版

1年多沒寫PHP了，抽空我會慢慢補(bǔ)上來

待完善

切片的大?。哼@個后面會做出動態(tài)計算的。需要根據(jù)當(dāng)前所上傳文件的大小，自動計算合適的切片大小。避免出現(xiàn)切片過多的情況。

文件追加：目前上傳文件過程中，不能繼續(xù)選擇文件加入隊列。（這個沒想好應(yīng)該怎么處理。）

更新記錄

組件已經(jīng)運(yùn)行一段時間了，期間也測試出幾個問題，本來以為沒BUG的，看起來BUG都挺嚴(yán)重

BUG-1：當(dāng)同時上傳多個內(nèi)容相同但是文件名稱不同的文件時，出現(xiàn)上傳失敗的問題。

預(yù)期結(jié)果：第一個上傳成功后，后面相同的問文件應(yīng)該直接秒傳

實(shí)際結(jié)果：第一個上傳成功后，其余相同的文件都失敗，錯誤信息，塊數(shù)不對。

原因：當(dāng)?shù)谝粋€文件塊上傳完畢后，便立即進(jìn)行了下一個文件的循環(huán)，導(dǎo)致無法及時獲取文件是否已秒傳的狀態(tài)，從而導(dǎo)致失敗。

解決方案：在當(dāng)前文件分片上傳完畢并且請求合并接口完畢后，再進(jìn)行下一次循環(huán)。

將子方法都改為同步方式，mergeRequest 和 uploadChunks 方法

BUG-2: 當(dāng)每次選擇相同的文件并觸發(fā)beforeUpload方法時，若第二次也選擇了相同的文件，beforeUpload方法失效，從而導(dǎo)致整個流程失效。

原因：之前每次選擇文件時，沒有清空上次所選input文件的數(shù)據(jù)，相同數(shù)據(jù)的情況下，是不會觸發(fā)input的change事件。

解決方案：每次點(diǎn)擊input時，清空數(shù)據(jù)即可。我順帶優(yōu)化了下其他的代碼，具體看提交記錄吧。

<input

 v-if="!changeDisabled"

 type="file"

 :multiple="multiple"

 class="select-file-input"

 :accept="accept"

+  οnclick="f.outerHTML=f.outerHTML"

 @change="handleFileChange"/>

重寫了暫停和恢復(fù)的功能，實(shí)際上，主要是增加了暫停和恢復(fù)的狀態(tài)

之前的處理邏輯太簡單粗暴，存在諸多問題。現(xiàn)在將狀態(tài)定位在每一個文件之上，這樣恢復(fù)上傳時，直接跳過即可

封裝組件

寫了一大堆，其實(shí)以上代碼你直接復(fù)制也無法使用，這里我將此封裝了一個組件。大家可以去github下載文件，里面有使用案例 ，若有用記得隨手給個star，謝謝!

偷個懶，具體封裝組件的代碼就不列出來了，大家直接去下載文件查看,若有不明白的，可留言。

組件文檔

Attribute

參數(shù) 類型 說明 默認(rèn) 備注

headers Object 設(shè)置請求頭

before-upload Function 上傳文件前的鉤子，返回false則停止上傳

accept String 接受上傳的文件類型

upload-arguments Object 上傳文件時攜帶的參數(shù)

with-credentials Boolean 是否傳遞Cookie false

limit Number 最大允許上傳個數(shù) 0 0為不限制

on-exceed Function 文件超出個數(shù)限制時的鉤子

multiple Boolean 是否為多選模式 true

base-url String 由于本組件為內(nèi)置的AXIOS，若你需要走代理，可以直接在這里配置你的基礎(chǔ)路徑

chunk-size Number 每個切片的大小 10M

threads Number 請求的并發(fā)數(shù) 3 并發(fā)數(shù)越高，對服務(wù)器的性能要求越高，盡可能用默認(rèn)值即可

chunk-retry Number 錯誤重試次數(shù) 3 分片請求的錯誤重試次數(shù)

Slot

方法名 說明 參數(shù) 備注

header 按鈕區(qū)域 無

tip 提示說明文字 無

后端接口文檔：按文檔實(shí)現(xiàn)即可

藍(lán)藍(lán)設(shè)計( sillybuy.com )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)