隨著項(xiàng)目體積的增加，參與到項(xiàng)目中的同學(xué)越來(lái)越多，每個(gè)人都有自己的打 git log 的習(xí)慣：

• 格式 1: add: 添加...
• 格式 2: [add]: 添加...
• 格式 3: Add 添加...

為了形成統(tǒng)一的規(guī)范，達(dá)成共識(shí)，從而降低協(xié)作開(kāi)發(fā)成本，需要對(duì) git commit 記錄進(jìn)行規(guī)范。

規(guī)范 git commit 記錄

規(guī)范 git commit 記錄，需要做兩件事情：

• 通過(guò)交互式命令行，自動(dòng)生成符合指定規(guī)范的 commit 記錄
• 提交記錄后，在 git hooks 中進(jìn)行 commit 記錄格式檢查

問(wèn)：既然已經(jīng)交互式生成了規(guī)范記錄，為什么需要在 hooks 進(jìn)行檢查？

交互式生成 commit 記錄，需要用戶調(diào)用自定義的 npm scripts，例如npm run commit。但還是可以直接調(diào)用原生 git 命令 git commit 來(lái)提交記錄。而檢查是在正式提交前進(jìn)行的，因此不符合要求的記錄不會(huì)生效，需要重新 commit。

調(diào)研：交互式 commit log 規(guī)范方案

前期調(diào)研結(jié)果，關(guān)于 commit 提示有兩種做法：

1. 直接使用 commitizen 中常用的 adapter
2. 根據(jù)團(tuán)隊(duì)的需要，自定義 adapter

方法 1 的優(yōu)缺點(diǎn)：

優(yōu)點(diǎn) 1: 直接安裝對(duì)應(yīng)的 adapter 即可

優(yōu)點(diǎn) 2: 無(wú)開(kāi)發(fā)成本

缺點(diǎn) 1: 無(wú)法定制，不一定滿足團(tuán)隊(duì)需要

方法 2 的優(yōu)缺點(diǎn)：

優(yōu)點(diǎn) 1: 可定制，滿足開(kāi)發(fā)需求

優(yōu)點(diǎn) 2: 單獨(dú)成庫(kù)，發(fā)布 tnpm，作為技術(shù)建設(shè)

缺點(diǎn) 1: 需要單獨(dú)一個(gè)倉(cāng)庫(kù)（但開(kāi)發(fā)成本不高）

代碼實(shí)現(xiàn)

在實(shí)際工作中，發(fā)現(xiàn)方法 1 中的常用規(guī)范，足夠覆蓋團(tuán)隊(duì)日常開(kāi)發(fā)場(chǎng)景。所以，選擇了方法 1.

step1: 安裝 npm 包

npm i --save-dev commitizen cz-conventional-changelog @commitlint/cli @commitlint/config-conventional husky

添加 package.json 的配置：

"scripts": { "commit": "git-cz" }, "husky": { "hooks": { "commit-msg": "commitlint -E HUSKY_GIT_PARAMS" }
}, "config": { "commitizen": { "path": "./node_modules/cz-conventional-changelog" }
}

在項(xiàng)目根目錄下創(chuàng)建commitlint.config.js：

module.exports = { extends: ["@commitlint/config-conventional"]
};

使用方法：不再使用git commit -m ...，而是調(diào)用npm run commit。

<img src="https://tva1.sinaimg.cn/large/006tNbRwly1gbjcfr3xb5j30cw00tjrd.jpg" style="width: 100% !important;"/>

醫(yī)療行業(yè)的交互設(shè)計(jì)，跟其他行業(yè)有何不同？有什么要特別考慮的點(diǎn)？設(shè)計(jì)師應(yīng)該注意哪些方面？

X與行業(yè)

產(chǎn)品體驗(yàn)設(shè)計(jì)通道中有條簡(jiǎn)單好記的定義： 1+X。

「X」這個(gè)字母常被定義為更多可能性，它的誕生往往是為了更好地服務(wù)行業(yè)與產(chǎn)品。

例如在醫(yī)療健康行業(yè)中，不再只有C端用戶，我們要面對(duì)醫(yī)院管理人--員、患者、醫(yī)護(hù)人員還有企業(yè)用戶等；環(huán)境也不單是線上場(chǎng)景，它可能是醫(yī)院、企業(yè)大樓、社康、疾控中心等等；合作方式同樣獨(dú)特，我們做出的任何一個(gè)設(shè)計(jì)都是需要客戶過(guò)目的，每一個(gè)字段甚至都涉及到生命健康與安全，所以會(huì)要求我更高標(biāo)準(zhǔn)地了解行業(yè)與用戶，促使我們?cè)陧?xiàng)目前期去不斷學(xué)習(xí)和應(yīng)用一些用戶研究知識(shí)，使設(shè)計(jì)更加貼近用戶。

交互設(shè)計(jì)師在用戶研究領(lǐng)域的探索

過(guò)往經(jīng)歷中，總結(jié)了用戶研究在各階段的介入場(chǎng)景和方法，接下來(lái)會(huì)具體講下在醫(yī)療健康項(xiàng)目中的運(yùn)用。

1. 企業(yè)健康場(chǎng)景案例

企業(yè)健康項(xiàng)目是從一個(gè)合作開(kāi)始的，公司的行政部門想要通過(guò)我們提供的健康管理產(chǎn)品來(lái)提升員工整體的健康水平，并將該方案進(jìn)行復(fù)制從而提供一個(gè)企業(yè)健康管理的行業(yè)解決方案。

的確，員工是一個(gè)企業(yè)的寶貴財(cái)富，健康有活力的員工群體對(duì)提升企業(yè)生命力有著非同一般的影響。通過(guò)網(wǎng)絡(luò)文獻(xiàn)調(diào)研，我發(fā)現(xiàn)國(guó)內(nèi)企業(yè)的亞健康狀況并不樂(lè)觀。

△ 國(guó)內(nèi)企業(yè)健康現(xiàn)狀

第一階段用研——產(chǎn)品定義與設(shè)計(jì)方向

為了更了解員工和企業(yè)的真實(shí)情況和痛點(diǎn)，我們規(guī)劃了用研計(jì)劃，列出了三個(gè)用研目標(biāo)：

• 了解員工們的主要健康問(wèn)題
• 了解企業(yè)服務(wù)存在的問(wèn)題和改善方向
• 確立產(chǎn)品目標(biāo)與設(shè)計(jì)目標(biāo)

目標(biāo)1: 員工們的主要健康問(wèn)題都是什么？

通過(guò)和企業(yè)方的溝通，我們發(fā)現(xiàn)員工的體檢報(bào)告是挖掘健康問(wèn)題的源頭，于是我們由此開(kāi)始研究。

首先，我們拿到了歷年的公司員工體檢數(shù)據(jù)統(tǒng)計(jì)（脫敏分析），整理出體檢問(wèn)題的Top10。

△ 騰訊2018年體檢數(shù)據(jù)統(tǒng)計(jì)

獲許可，我們也隨機(jī)向外發(fā)放問(wèn)卷，了解到一些公司職工最想要改善的問(wèn)題。

△ 某大廈的用研報(bào)告（僅作為分析用）

目標(biāo)2：企業(yè)現(xiàn)在所提供的服務(wù)有哪些問(wèn)題，該如何改善？

B端: 由于這是一個(gè)B to C的項(xiàng)目，我們優(yōu)先會(huì)去采訪企業(yè)端遇到的問(wèn)題，溝通發(fā)現(xiàn)企業(yè)都會(huì)投資提供的健康設(shè)施（體檢，食堂，健身房等），其中很多設(shè)施并沒(méi)有被充分利用，或是沒(méi)有得到合理的分配，現(xiàn)有的線上預(yù)約流程也存在很大的后臺(tái)計(jì)算成本。

△ 騰訊提供的健康服務(wù)與設(shè)施（非疫情期間拍攝）

C端: 通過(guò)公司內(nèi)部招募和訪談了20名員工，我們總結(jié)為三個(gè)主要痛點(diǎn)：

• 體檢套餐不知怎么選最適合自己，體驗(yàn)不流暢
• 體檢后看不懂報(bào)告也不知道該如何改善
• 知道改善方向卻不知如何落地和規(guī)劃，或是沒(méi)有堅(jiān)持下去。

△ 員工在體檢健康中遇到的痛點(diǎn)

以上，我們也對(duì)企業(yè)客戶與員工用戶的訴求有了初步的了解。

△ B&amp;amp;amp;amp;C兩端訴求分析

目標(biāo)3：如何定義產(chǎn)品目標(biāo)與設(shè)計(jì)目標(biāo)？

通過(guò)以上分析，和其他合作團(tuán)隊(duì)一同討論了體檢與健康管理行業(yè)的現(xiàn)狀和盈利點(diǎn)，我們最終確定了產(chǎn)品方向：通過(guò)加入AI技術(shù)，分析用戶過(guò)往體檢數(shù)據(jù)來(lái)給用戶推薦最合適的體檢套餐，幫助用戶解析體檢報(bào)告轉(zhuǎn)化為更加易懂的方式，加強(qiáng)與醫(yī)療服務(wù)的定制化連接；并智能定制最適合員工的管理方式和行為，充分利用起公司資源。

△ 產(chǎn)品形象與定義

通過(guò)對(duì)整體流程的用戶情緒地圖分析，我們得出設(shè)計(jì)的關(guān)鍵詞：專業(yè)，貼心，安全

△ 階段情緒地圖分析

知識(shí)點(diǎn)1: 訪談與問(wèn)卷調(diào)研

不要一上來(lái)就直奔主題，可以先問(wèn)一些簡(jiǎn)單回答的問(wèn)題和閑聊，讓用戶進(jìn)入放松狀態(tài)時(shí)再聊重點(diǎn)問(wèn)題。且要時(shí)刻關(guān)注受訪用戶的狀態(tài)，比如：是不是開(kāi)始疲憊，回答過(guò)于發(fā)散以及表達(dá)意思模糊等等。遇到這些問(wèn)題，需要隨時(shí)做調(diào)整。

訪談的時(shí)候最好不要單獨(dú)行動(dòng)，要有1個(gè)主導(dǎo)訪談的，一個(gè)記錄的。如果訪問(wèn)過(guò)程很長(zhǎng)，有條件以及受訪者允許的情況下，可以進(jìn)行錄音有助于后期的整理。

訪談結(jié)束后，最好是當(dāng)場(chǎng)，或者至少應(yīng)該是當(dāng)天就完成本場(chǎng)次的訪談?dòng)涗浐涂偨Y(jié)工作。因?yàn)楦鶕?jù)遺忘曲線，人在20分鐘后將遺忘42%的內(nèi)容，而1天后則將遺忘74%。即使有錄音筆記錄，你也會(huì)忘掉很多細(xì)節(jié)的，諸如表情，用戶的潛臺(tái)詞等等。想到的設(shè)計(jì)解決方案也可以先記錄下來(lái)但不急于放到總結(jié)當(dāng)中去。

第二階段用研——產(chǎn)品與設(shè)計(jì)驗(yàn)證

確立了目標(biāo)和方向，我開(kāi)始從體檢預(yù)約和檢后管理兩部分來(lái)進(jìn)行設(shè)計(jì)，由于在前期建立了用研機(jī)制，我們會(huì)定期對(duì)重要版本的內(nèi)容和信息設(shè)計(jì)進(jìn)行測(cè)試驗(yàn)證，并讓用戶基于我們定義的設(shè)計(jì)標(biāo)準(zhǔn)來(lái)打分，判斷是否達(dá)到了專業(yè)，貼心與安全。

卡片分類-測(cè)試內(nèi)容與排序

在檢后的體檢報(bào)告解讀中，我們需要對(duì)解讀結(jié)果進(jìn)行結(jié)構(gòu)化展示，方便用戶快速獲取有用信息，提高閱讀效率，由此我們運(yùn)用了卡片分類法，讓用戶對(duì)其重要性的排序，得知對(duì)用戶來(lái)說(shuō)體檢異常中的單項(xiàng)的指標(biāo)解釋>危害性>指導(dǎo)措施。

△ 卡片測(cè)試與分析

可用性測(cè)試-測(cè)試架構(gòu)與信息形態(tài)

體檢解讀的首頁(yè)我們繪制了三個(gè)版本的方案，來(lái)突出不同的信息通過(guò)制作原型demo來(lái)進(jìn)行可用性測(cè)試，讓用戶選出最喜歡的并說(shuō)明原因，最終選擇出一個(gè)最優(yōu)方案。

△ 體檢解讀首頁(yè)可用性測(cè)試與分析

從彈窗內(nèi)容組合到內(nèi)容的體檢解讀指標(biāo)的可視化設(shè)計(jì)我們都做了用研測(cè)試版本

△ 體檢解讀內(nèi)頁(yè)信息測(cè)試稿

最終得到更加符合用戶認(rèn)知的體檢解讀設(shè)計(jì)。

△ 體檢解讀設(shè)計(jì)

灰度測(cè)試與深度訪談

由于某些需求時(shí)間緊迫，例如體檢預(yù)約，當(dāng)時(shí)很快就要到體檢季，于是我們快速搭建框架和基礎(chǔ)功能的設(shè)計(jì)，細(xì)節(jié)疑問(wèn)點(diǎn)列出后進(jìn)行灰度版本測(cè)試，并對(duì)前期招募的種子用戶進(jìn)行測(cè)試訪談，總結(jié)現(xiàn)存版本的問(wèn)題，同時(shí)我們也訪問(wèn)了企業(yè)側(cè)，把他們的優(yōu)化訴求納入考慮。

△ 體檢預(yù)約訪談腳本與測(cè)試結(jié)論

比如企業(yè)要求突出安全感，福利感與智能推薦，減少后臺(tái)結(jié)算成本等，我們便通過(guò)明確隱私授權(quán)認(rèn)知的全頁(yè)面彈窗以及簡(jiǎn)化體檢預(yù)約流程，2步變1步，增強(qiáng)頁(yè)面福利與智能推薦的感知渲染來(lái)滿足客戶要求，也得到了滿意的贊賞。

△ 隱私授權(quán)設(shè)計(jì)

△ 體檢預(yù)約設(shè)計(jì)

以上的用研方法其實(shí)可以運(yùn)用在大多數(shù)的項(xiàng)目中，于是我在后續(xù)的騰訊健康模塊設(shè)計(jì)中也常會(huì)去使用，例如疫苗設(shè)計(jì)中的閃屏方案測(cè)試等等。需要注意的是用研應(yīng)該被列入到日常的流程中去，而不能作為臨時(shí)安插，需要在項(xiàng)目實(shí)施前就進(jìn)行用研計(jì)劃的擬訂，才能保證我們和用研同學(xué)有條理地客觀的進(jìn)行調(diào)研和驗(yàn)證。

知識(shí)點(diǎn)2:卡片與可用性測(cè)試

• 研究員不要引導(dǎo)和干擾受訪者，特別是不要在過(guò)程中對(duì)某些詞匯進(jìn)行解釋。
• 開(kāi)放式卡片分類法中，卡片數(shù)量不宜太多，簡(jiǎn)單的卡片測(cè)試建議在20以內(nèi)。難度會(huì)隨著數(shù)量的新增而成倍增加。
• 記得要首先詢問(wèn)用戶對(duì)于卡片上詞匯的理解，看是否有偏差。當(dāng)對(duì)方問(wèn)到的時(shí)候，可以先不著急回答，先問(wèn)問(wèn)他是如何理解的。內(nèi)容的設(shè)計(jì)是設(shè)計(jì)師容易忽略但非常重要的一點(diǎn)。
• 可用性測(cè)試的環(huán)境要保證安靜無(wú)干擾。自己做的設(shè)計(jì)往往會(huì)容易有一些主觀的想法和情緒，需要盡量克制，比如可以讓用研同學(xué)做主導(dǎo)，自己做記錄和觀察即可。

2. 就醫(yī)服務(wù)場(chǎng)景案例

就醫(yī)流程是看似并不陌生的場(chǎng)景，痛點(diǎn)也非常明顯，就是常被提到的「三長(zhǎng)一短」問(wèn)題（掛號(hào)時(shí)間長(zhǎng)，支付時(shí)間長(zhǎng)，問(wèn)診時(shí)間短），于是在進(jìn)行線上就醫(yī)服務(wù)設(shè)計(jì)時(shí)，很多人會(huì)認(rèn)為沒(méi)什么好特別調(diào)研的，競(jìng)品也非常多。

然而其實(shí)在設(shè)計(jì)中，最害怕的就是「我以為」。記得在做某醫(yī)院的就醫(yī)服務(wù)項(xiàng)目時(shí)，由于就醫(yī)環(huán)境和用戶非常復(fù)雜，所以我們?cè)谧鲞@個(gè)項(xiàng)目時(shí)堅(jiān)持去到了前線進(jìn)行了實(shí)地考察與影子觀察法，才發(fā)現(xiàn)了新的洞察。

實(shí)地考察中的望聞問(wèn)切

說(shuō)來(lái)很巧，現(xiàn)場(chǎng)的調(diào)研方法其實(shí)和中醫(yī)中的「望聞問(wèn)切」有異曲同工之妙。

△ 醫(yī)療場(chǎng)景用研方法

「望」：可理解為影子觀察法：選擇最能反映問(wèn)題的時(shí)間和場(chǎng)景去觀察用戶行為，發(fā)現(xiàn)痛點(diǎn)，經(jīng)過(guò)幾天的觀察我們發(fā)現(xiàn)早上8-10點(diǎn)是醫(yī)院看病的高峰期，也是排隊(duì)最嚴(yán)重，院內(nèi)最擁擠的時(shí)期，所以我會(huì)在這兩個(gè)小時(shí)集中觀察和記錄患者以及醫(yī)生的狀態(tài)。

「聞」：即為傾聽(tīng)，其實(shí)也是訪談法中很重要的一個(gè)原則，多讓用戶去訴說(shuō)，減少自己的主觀判斷干擾用戶的完整陳述，如果記不下可以錄音。

「問(wèn)」：根據(jù)我們想要了解和觀察到用戶的行為進(jìn)行提問(wèn)。

「切」：這里和中醫(yī)中的切診接觸不同。是指切身去體驗(yàn)患者的感受，比如我會(huì)根據(jù)自己身體的某些不舒服去掛號(hào)體驗(yàn)流程，情景帶入。

以上的實(shí)地考察后，我在第一時(shí)間用我們?cè)O(shè)計(jì)師的手法來(lái)記錄整理：體驗(yàn)地圖分析，并通過(guò)討論提煉出設(shè)計(jì)的關(guān)鍵點(diǎn)：引導(dǎo)，連接，合并與轉(zhuǎn)化。

△ 用戶體驗(yàn)地圖與關(guān)鍵點(diǎn)分析

知識(shí)點(diǎn)3:影子觀察法

• 需要選取事件發(fā)生的典型場(chǎng)景和時(shí)間，即所觀察的場(chǎng)景和用戶是最具有代表性的，才能最反映問(wèn)題所在。
• 像一個(gè)隱形人一樣去觀察，不要主動(dòng)打擾和詢問(wèn)用戶，才能最客觀的記錄狀態(tài)和行為，避免變形。

用戶體驗(yàn)地圖的落地應(yīng)用

這四個(gè)設(shè)計(jì)關(guān)鍵點(diǎn)其實(shí)來(lái)源于痛點(diǎn)描述中的一些高頻提到的情況，拿引導(dǎo)和連接這兩個(gè)點(diǎn)來(lái)說(shuō)明。

引導(dǎo)：通過(guò)觀察發(fā)現(xiàn)，用戶在嘈雜的就醫(yī)環(huán)境中本處于極度焦慮緊張的狀態(tài)，對(duì)信息閱讀和處理的速度低于平時(shí)的好幾倍，因此我們需要提供具體的，正向的引導(dǎo)。

△ 精準(zhǔn)預(yù)約設(shè)計(jì)

連接：通過(guò)訪談和自己實(shí)際的體驗(yàn)發(fā)現(xiàn)，許多線上和線下的服務(wù)之間是斷層的，一方面需要流程上連接我付了款下一步要去哪，怎么拿藥；另一方面我們也發(fā)現(xiàn)線下的引導(dǎo)設(shè)計(jì)是一個(gè)非常重要的連接機(jī)會(huì)點(diǎn)。

于是我們從線上和線下兩方面進(jìn)行了連接，提供了一套整體的解決方案。

△ 候診與取藥簽到設(shè)計(jì)

△ 醫(yī)院物料布局與落地布置

通過(guò)用戶關(guān)系圖了解了每個(gè)相關(guān)利益人的人群要素和訴求，在設(shè)計(jì)中不僅會(huì)考慮針對(duì)他們的設(shè)計(jì)，也結(jié)合體驗(yàn)地圖中的機(jī)會(huì)點(diǎn)引出了設(shè)計(jì)原則，作為設(shè)計(jì)的指導(dǎo)和驗(yàn)證標(biāo)準(zhǔn)。

△ 相關(guān)利益人分析與設(shè)計(jì)原則

測(cè)試與收獲

上線后，我們穿上志愿者的衣服，去往前線進(jìn)行現(xiàn)場(chǎng)解說(shuō)和用戶測(cè)試，經(jīng)過(guò)一個(gè)月的努力，真實(shí)感受到了現(xiàn)場(chǎng)效率的提升和滿意度的提高，院方和使用過(guò)的用戶都非常滿意，這也讓我們?cè)O(shè)計(jì)師切實(shí)感受到了欣慰和成就感。

△復(fù)旦大學(xué)附屬腫瘤醫(yī)院病理會(huì)診 整體服務(wù)上線前后對(duì)比

這得益于我們能長(zhǎng)時(shí)間與用戶在一起，真實(shí)地聽(tīng)到了他們的聲音與感受，也把想法落地去幫助他們解決了問(wèn)題。這個(gè)過(guò)程中，讓我們發(fā)現(xiàn)類似的垂直領(lǐng)域需要去到前線自己去感受，而不是隔著屏幕去觀察，每個(gè)人的思考角度會(huì)不同，會(huì)發(fā)現(xiàn)新的問(wèn)題和洞察。

知識(shí)點(diǎn)4:用戶體驗(yàn)地圖

• 不要為了畫流程而畫，最終還是要通過(guò)圖形化的記憶更好的還原記憶細(xì)節(jié)。
• 重點(diǎn)要放在痛點(diǎn)與機(jī)會(huì)點(diǎn)的一些突出共性上，提煉是關(guān)鍵步驟。
• 不要忽略不同接觸點(diǎn)的洞察，它們均可以作為設(shè)計(jì)的載體。

3. 醫(yī)療數(shù)據(jù)分析場(chǎng)景案例

在醫(yī)療數(shù)據(jù)分析的場(chǎng)景中，我們面對(duì)的客戶是政府和醫(yī)院領(lǐng)導(dǎo)。相信在做TO B設(shè)計(jì)的小伙伴經(jīng)常會(huì)遇到這樣的問(wèn)題：客戶時(shí)間比較難約，給的調(diào)研時(shí)間有限；決策層客戶思考的比較廣而泛，很難深入用研。

基于這樣的問(wèn)題，我們想出了一個(gè)根據(jù)客戶群體層級(jí)，區(qū)別調(diào)研的方法。

梳理角色

去年年初，我們?cè)咴L多家公立和私立醫(yī)院，優(yōu)先通過(guò)管理層梳理出了關(guān)于數(shù)據(jù)處理上報(bào)的流程。他們對(duì)數(shù)據(jù)的關(guān)注度和處理順序往往是有一個(gè)自下而上的上報(bào)過(guò)程，基層人員進(jìn)行每個(gè)月度和季度的數(shù)據(jù)匯總，分析與簡(jiǎn)單的可視化表現(xiàn)，上報(bào)給部門管理和上級(jí)管理者進(jìn)行審核提煉，最終給到管理決策者一些關(guān)鍵現(xiàn)象和趨勢(shì)和對(duì)比。

由此提醒了我們，想要提供一個(gè)完整的數(shù)據(jù)解決方案，就需要繪制角色面板，區(qū)別調(diào)研目的與手段。

△ 醫(yī)院層針對(duì)數(shù)據(jù)的處理流程

分角色的溝通用研

我們確立了針對(duì)基層人員，中層管理者以及決策管理者的用研目標(biāo)并展開(kāi)了差異化的溝通用研，我們會(huì)每個(gè)角色找1-2人和我們3-4個(gè)同事坐在一起，以焦點(diǎn)小組的方法一同腦暴某一數(shù)據(jù)場(chǎng)景和所需數(shù)據(jù)。

• 基層人員 用研目標(biāo)：了解常用基礎(chǔ)數(shù)據(jù)的模塊與細(xì)節(jié)匯總
• 中層管理 用研目標(biāo)：常關(guān)注的關(guān)鍵指標(biāo)模塊與提煉形態(tài)（對(duì)比，警示，峰值，占比）
• 決策管理者 用研目標(biāo)：看數(shù)據(jù)的目的，常關(guān)注的關(guān)鍵指標(biāo)與形態(tài)的驗(yàn)證，后續(xù)操作

△ 醫(yī)院數(shù)據(jù)現(xiàn)場(chǎng)用研

數(shù)據(jù)研究與總結(jié)應(yīng)用

根據(jù)對(duì)醫(yī)院不同角色的溝通梳理出了一些總結(jié)點(diǎn)，運(yùn)用到了產(chǎn)品和設(shè)計(jì)中。

第一：我們發(fā)現(xiàn)了管理者們最關(guān)注的一些醫(yī)院數(shù)據(jù)的形態(tài)，并打算把基礎(chǔ)數(shù)據(jù)盡量以對(duì)比，警示等手段進(jìn)行分析與場(chǎng)景描述。便于管理者直觀獲取他想要獲取的輔助決策信息。

第二：根據(jù)不同角色提供針對(duì)性的角色面板，并梳理出個(gè)角色關(guān)注的數(shù)據(jù)模塊和現(xiàn)象。

第三：各角色具體數(shù)據(jù)字段的梳理與總結(jié)，并進(jìn)行了頻率的標(biāo)注便于后續(xù)的設(shè)計(jì)面板規(guī)劃。

第四：調(diào)研中發(fā)現(xiàn)領(lǐng)導(dǎo)層在看數(shù)據(jù)時(shí)需要來(lái)回切換系統(tǒng)，且看起來(lái)沒(méi)有一個(gè)統(tǒng)一的路徑和條理，因此我們也和對(duì)方溝通，通過(guò)故事化的手法進(jìn)行數(shù)據(jù)分析的流程體驗(yàn)設(shè)計(jì)，層層深入和下鉆，從現(xiàn)象挖掘到問(wèn)題本質(zhì)。更加符合了用戶看數(shù)據(jù)的順序和認(rèn)知。

△ 長(zhǎng)沙超腦項(xiàng)目設(shè)計(jì)版圖

除此之外，我們后面的產(chǎn)品和設(shè)計(jì)的匯報(bào)也會(huì)根據(jù)角色的差異來(lái)進(jìn)行內(nèi)容的調(diào)整，讓聽(tīng)我們說(shuō)話的人可以快速理解我們想要達(dá)成共識(shí)的內(nèi)容，加快溝通效率，提升了在客戶心里的印象。

這個(gè)過(guò)程中，通過(guò)用研讓用戶感覺(jué)到我們懂他們，并讓其增加了參與感，對(duì)產(chǎn)品和設(shè)計(jì)都是一個(gè)推進(jìn)器。

知識(shí)點(diǎn)5：TO B/G客戶用研

• 事前理清楚項(xiàng)目中會(huì)接觸的各個(gè)角色，并進(jìn)行初步了解，制定不同的用研目標(biāo)再進(jìn)行溝通。
• 探討的過(guò)程，要給足客戶參與感，例如使用焦點(diǎn)小組的調(diào)研方式，提升好印象。

如何持續(xù)提升技能——讀書有感

說(shuō)了那么多設(shè)計(jì)師在用研技能上的應(yīng)用，也許有人會(huì)有這樣的疑問(wèn)：如何可以不斷提升自己在各方面學(xué)到的技能呢？一年前讀到《刻意練習(xí)》這本書，給了我一些啟發(fā)，在此總結(jié)給大家，希望對(duì)你們有幫助：

1. 制定具有定義明確的特定目標(biāo)

「提升專業(yè)」是個(gè)很大的詞，所以我們往往定了一個(gè)很大的目標(biāo)，然后被各種事情拖著然后拋之腦后。因此拆分目標(biāo)才是第一步。比如最開(kāi)始做交互時(shí)我發(fā)現(xiàn)自己在歸納場(chǎng)景時(shí)總會(huì)缺失，再比如每次自己在匯報(bào)總結(jié)時(shí)，耗時(shí)過(guò)長(zhǎng)，缺乏重點(diǎn)，那么這些都可以被列入要提升的小目標(biāo)，總之目標(biāo)不要太泛太難實(shí)現(xiàn)，這樣實(shí)現(xiàn)起來(lái)會(huì)更加容易，也更容易堅(jiān)持和自我激勵(lì)。

2. 持續(xù)學(xué)習(xí)與專注練習(xí)

研讀多本相關(guān)專業(yè)書籍，并應(yīng)用的項(xiàng)目中去。這是我的一個(gè)目標(biāo)也是方法。投入項(xiàng)目后，我們往往會(huì)陷入事件當(dāng)中，甚至?xí)鸵粋€(gè)點(diǎn)和產(chǎn)品爭(zhēng)論不休。但其實(shí)跳出來(lái)，去看些新思路不妨為一個(gè)好方法。

比如我最近在讀《感官心理學(xué)》這本書，提到人們對(duì)于「軟」和「硬」的觸感印象會(huì)延伸到女性和男性的聯(lián)想上，提到女性人們自然都會(huì)有柔軟的印象，男性則會(huì)有剛硬事物的聯(lián)想，這也就充分佐證了對(duì)于不同性別上的設(shè)計(jì)形態(tài)差異。類似的小實(shí)驗(yàn)可以幫助我們的設(shè)計(jì)更有說(shuō)服力。

大多時(shí)候理論知識(shí)很枯燥，也難以一時(shí)間就可以用到，但只要你讀過(guò)，在需要的時(shí)候它就會(huì)突然跑出來(lái)給你靈感。

專注是我一個(gè)單線程人的特點(diǎn)，我很難在一個(gè)時(shí)間里同時(shí)處理多件事，所以我會(huì)每天根據(jù)要完成的訓(xùn)練目標(biāo)，把時(shí)間進(jìn)行劃分，個(gè)人感覺(jué)這的確產(chǎn)出效率也會(huì)高一些。

3. 一定要有反饋

每一次的練習(xí)必須要得到反饋，這也是評(píng)審的重要性。但其實(shí)不同的目標(biāo)點(diǎn)可以對(duì)應(yīng)方面的專家，不僅限于leader了，同事也是很好的老師，比如我會(huì)去發(fā)現(xiàn)身邊匯報(bào)比較厲害的同事，幫我把關(guān)。只要遇到問(wèn)題，一定不會(huì)放過(guò)去問(wèn)用戶研究同學(xué)的機(jī)會(huì)。

某方面沒(méi)有老師怎么辦？讓用戶告訴你！首先我會(huì)常用可用性測(cè)試的方式去檢測(cè)自己的方案中的信息傳達(dá)，交互反饋等等在進(jìn)步，另外我也會(huì)在每個(gè)項(xiàng)目后整理一個(gè)小總結(jié)，來(lái)記錄自己的思考與進(jìn)步

另外，以下是我在用戶研究學(xué)習(xí)中讀過(guò)的幾本書，推薦給大家～

結(jié)語(yǔ)

面對(duì)飛速發(fā)展的現(xiàn)在，各行業(yè)的產(chǎn)品也都在積極轉(zhuǎn)型，例如開(kāi)始涉足TO B行業(yè)和客戶，開(kāi)始研究00后的新生代用戶，面對(duì)新事物我們?cè)O(shè)計(jì)師更要保持敏銳的眼光，利用自身的設(shè)計(jì)洞察能力去挖掘新的問(wèn)題與方法，于是新的技能和方式也開(kāi)始出現(xiàn)，所以我們一直認(rèn)為產(chǎn)品體驗(yàn)設(shè)計(jì)師沒(méi)有一個(gè)固定的能力模型，還是要根據(jù)你所從事的行業(yè)和產(chǎn)品來(lái)發(fā)現(xiàn)所需的技能點(diǎn)去發(fā)揮價(jià)值。學(xué)習(xí)的過(guò)程中，我們成就項(xiàng)目的同時(shí)也在慢慢成就自己。

文章來(lái)源：優(yōu)設(shè)    作者：騰訊 April

最近身邊的一些小伙伴，總會(huì)遇見(jiàn)B端設(shè)計(jì)工作，對(duì)于這種偏后臺(tái)設(shè)計(jì)的B端設(shè)計(jì)，總會(huì)有大量的表單設(shè)計(jì)需要做，結(jié)合以前自己也有過(guò)不少表單設(shè)計(jì)的工作，在這里給大家分享一下自己對(duì)于PC端表單設(shè)計(jì)的研究，聊一聊表單在PC端中的運(yùn)用。

表單的作用

商業(yè)離不開(kāi)數(shù)據(jù)，而數(shù)據(jù)總會(huì)依賴不同的表現(xiàn)形式，不管是word文檔，還是數(shù)據(jù)可視化，都是瀏覽者通過(guò)表現(xiàn)形式來(lái)對(duì)數(shù)據(jù)進(jìn)行閱讀和分析，因此表單的設(shè)計(jì)就是一種表現(xiàn)形式，我們將捋一捋如何通過(guò)表單更好的讓用戶閱讀順暢、操作方便、總而言之就是更好用啦。

表單信息的分割方式

無(wú)線分割：顧名思義，列表的信息之間正常情況下沒(méi)有分割線等方法來(lái)分隔，僅僅是用間距來(lái)分隔開(kāi)內(nèi)容。好處是元素更少，畫面更簡(jiǎn)潔，但是視覺(jué)可能就沒(méi)那么清晰了，使用的出場(chǎng)率一般。

有線分割：同樣字面意思，就是通過(guò)簡(jiǎn)單的分割線來(lái)分割列表中的信息，讓視線左右移動(dòng)的時(shí)候更加穩(wěn)定、輕松，在表單設(shè)計(jì)中使用的出場(chǎng)率非常高。

斑馬線：通過(guò)深淺交替的色塊，以及色塊產(chǎn)生的對(duì)比來(lái)分隔列表中的信息，深淺深淺的循環(huán)就好像斑馬線，使用時(shí)是通過(guò)色塊產(chǎn)生對(duì)比，所以也可以使用帶有適量飽和度的色塊來(lái)區(qū)分，占頁(yè)面面積比例較大，適當(dāng)用色可以使得畫面更加活潑、豐滿，斑馬線也是出場(chǎng)率極高的一種展現(xiàn)形式。

斑馬線+分割線：很容易理解，就是斑馬線風(fēng)格+分割線的結(jié)合，用色塊區(qū)分的同時(shí)又加了分割線，信息之間的區(qū)分對(duì)比更加強(qiáng)烈，但是畫面層級(jí)就多了一些，沒(méi)有其他的看起來(lái)簡(jiǎn)潔，使用出場(chǎng)率也一般。

卡片式：跟卡片式風(fēng)格其他設(shè)計(jì)一樣，分別用懸浮的色塊來(lái)區(qū)分，間隔的地方是背景色，分隔的力度比較強(qiáng)，內(nèi)容區(qū)分的很清晰，弊端是更加占畫面的位置，尤其在信息很多列的時(shí)候，會(huì)增加大量的高度，用戶需要更多時(shí)間進(jìn)行下翻的操作。使用出場(chǎng)率相對(duì)其他形式來(lái)說(shuō)稍低。

可控制頁(yè)面顯示數(shù)量

場(chǎng)景：用戶需要閱讀大量的表單數(shù)據(jù)，且需要頻繁的翻頁(yè)、跳轉(zhuǎn)。

如圖，左下角可以設(shè)置界面中每頁(yè)顯示信息數(shù)量的多少，用戶可以根據(jù)自己的需要自由設(shè)置，當(dāng)瀏覽的數(shù)據(jù)較多的時(shí)候，不再需要頻繁點(diǎn)擊下一頁(yè)來(lái)瀏覽信息，只需把每頁(yè)顯示的數(shù)量調(diào)高，如此便減少了大量的操作次數(shù)。

像這樣允許用戶可以自由編輯來(lái)改進(jìn)體驗(yàn)的方式還有很多，比如可以設(shè)置顯示密度，就是以一樣的方式自由調(diào)整信息與分割線的間距。除了行間距，有的可以自由設(shè)置每一列的列間距，用戶可以根據(jù)自己的習(xí)慣來(lái)設(shè)置。

列表+可視化

場(chǎng)景：用戶需要瀏覽大量的數(shù)據(jù)，并需要對(duì)數(shù)據(jù)反復(fù)進(jìn)行計(jì)算、分析。

在使用大量的文字列表展示數(shù)據(jù)的同時(shí)，使用數(shù)據(jù)可視化加以配合，用戶可以更好的預(yù)覽到數(shù)據(jù)的大致情況，又可以在列表表單中閱讀到詳細(xì)的數(shù)據(jù)。

根據(jù)條件排序

場(chǎng)景：用戶想根據(jù)某種條件的大小排序，來(lái)先后閱讀數(shù)據(jù)。

通過(guò)點(diǎn)擊第一排小標(biāo)題行，可以選擇不同的方式調(diào)整信息的排序方式，就和電商商品排序一樣，可以選擇金額高到低或者低到高排序，也可以選擇別的方式進(jìn)行排序，從而更快找到自己所需要的內(nèi)容。

篩選過(guò)濾

場(chǎng)景：從一大堆混雜的數(shù)據(jù)當(dāng)中，尋找符合條件的自己所需要的數(shù)據(jù)。

添加篩選功能，過(guò)濾掉自己不想瀏覽的內(nèi)容，通過(guò)條件篩選，更快的更的找到自己想要的內(nèi)容、縮小查找范圍、減少達(dá)到目的所花的時(shí)間。一般通過(guò)下拉按鈕的形式選擇不同的條件來(lái)進(jìn)行篩選過(guò)濾。

關(guān)鍵字搜索

場(chǎng)景：已知列表中某信息的名稱關(guān)鍵字，想從大量混雜的列表中快速找到。

跟篩選過(guò)濾一樣，添加關(guān)鍵字搜索功能，用戶提供部分關(guān)鍵字，可通過(guò)關(guān)鍵字查詢，最快最的找到想要的那一條內(nèi)容。一般該目標(biāo)內(nèi)容是用戶已知的，有時(shí)候是針對(duì)性的。

懸停展現(xiàn)操作

場(chǎng)景：精簡(jiǎn)設(shè)計(jì)風(fēng)格的界面，不想界面中內(nèi)容過(guò)于繁多。

如圖，鼠標(biāo)懸停在哪一行，哪一行才會(huì)顯示該列表后面的操作按鈕，好處是減少了視覺(jué)干擾，能更快的找到捕捉到操作位置，弊端是用戶不進(jìn)行交互的時(shí)候無(wú)法發(fā)現(xiàn)操作按鈕如何出現(xiàn)。

可展開(kāi)列表

場(chǎng)景：想快速獲取列表中某信息的其他附屬內(nèi)容。

如圖，點(diǎn)擊某一行后，展現(xiàn)該行的一些附屬信息?？梢圆挥锰D(zhuǎn)頁(yè)面而進(jìn)一步了解該行信息的詳情。

可編輯列表

場(chǎng)景：在瀏覽列表的同時(shí)，需要頻繁的對(duì)列表中的信息進(jìn)行編輯。

用戶可以直接對(duì)列表信息進(jìn)行修改、編輯，省去了跳轉(zhuǎn)再編輯的麻煩步驟，更節(jié)約時(shí)間，用戶操作起來(lái)更加方便。

快速預(yù)覽

場(chǎng)景：需要充分了解列表中不同信息的詳細(xì)說(shuō)明，頻繁跳轉(zhuǎn)又過(guò)于麻煩。

和可展開(kāi)列表的作用類似，但是可展開(kāi)列表顯示的內(nèi)容有限，快速預(yù)覽的功能可以用側(cè)彈框的方式、彈出對(duì)話窗口的方式、以及其他方式對(duì)選中的內(nèi)容直接展示詳細(xì)信息。用戶不需要跳轉(zhuǎn)至詳情頁(yè)就可以了解到大量信息，省去繁瑣的交互流程。不再需要頻繁的跳轉(zhuǎn)到詳情-返回-跳轉(zhuǎn)到另一個(gè)詳情-返回-跳轉(zhuǎn)-返回。使用快速預(yù)覽的功能就可以很好的解決這一問(wèn)題。

（PS：彈出對(duì)話窗口的方式，可以同時(shí)彈出好幾項(xiàng)列表的詳情信息進(jìn)行對(duì)比，但是側(cè)彈框因?yàn)楦叨葍?yōu)勢(shì)，可以展現(xiàn)更多內(nèi)容）

自定義列

場(chǎng)景：列表中每條內(nèi)容顯示信息參數(shù)過(guò)多，且很多不想瀏覽。

自定義列表功能是用戶可以自由設(shè)置每行信息參數(shù)的內(nèi)容，比如我不想列表中顯示金額這一項(xiàng)，就可以刪除，想要的時(shí)候可以添加回來(lái)，這樣用戶可以保留自己想要的那幾項(xiàng)內(nèi)容，可以更快更方便的閱讀到自己關(guān)心的那幾項(xiàng)參數(shù)，節(jié)省了用戶的有效時(shí)間。

固定頭部

場(chǎng)景：列表橫向或者縱向過(guò)多，下翻或橫拉的時(shí)候標(biāo)題頭被隱藏，不知道自己當(dāng)前瀏覽到的參數(shù)屬于哪一項(xiàng)。

交互過(guò)程中，可以把第一排重要的東西固定，列表內(nèi)容翻動(dòng)的同時(shí)，第一排仍然在原位不移動(dòng)而且覆蓋列表中的其他信息，很多自帶的框架都是這樣的形式，使用的出場(chǎng)率也是非常高，這樣用戶可以隨時(shí)查看到自己看到的內(nèi)容是屬于哪一項(xiàng)屬性，或者是屬于哪一條信息，可以是橫向固定，也可以固定豎直的第一排標(biāo)題，也可以固定最后一塊操作點(diǎn)擊區(qū)域，具體如何固定、是否固定，根據(jù)整體的需求來(lái)選擇。

間距的規(guī)則

通常表單都是大量的文字，大多數(shù)的文字高度都在該行高度的三分之一左右。過(guò)于緊密用戶瀏覽不順暢，過(guò)于分開(kāi)顯得畫面過(guò)于松散，不同的分割方式，間距也會(huì)有所不同。

總結(jié)

其實(shí)上面的每一條都是一個(gè)小總結(jié)，每一條在大部分的列表中都可以用到，主要還是根據(jù)實(shí)際需求來(lái)運(yùn)用這幾點(diǎn)，比如分割的方式根據(jù)主體風(fēng)格來(lái)搭配，不要為了設(shè)計(jì)而設(shè)計(jì)盲目運(yùn)用，畢竟設(shè)計(jì)都是以內(nèi)容為主，尤其是表單設(shè)計(jì)，本身就是更好的表達(dá)內(nèi)容。

本文發(fā)布于人人都是產(chǎn)品經(jīng)理。

轉(zhuǎn)自：站酷-

微信小程序的wxss、阿里旗下淘寶、支付寶小程序的acss等等語(yǔ)法很類似原生css，但是在web開(kāi)發(fā)里用慣了動(dòng)態(tài)css語(yǔ)言，再寫回原生css很不習(xí)慣，尤其是父子樣式的嵌套寫法非常繁瑣。

因此，我希望能有一個(gè)自動(dòng)化構(gòu)建方案，能夠簡(jiǎn)單地將scss轉(zhuǎn)換成小程序的樣式語(yǔ)言。

方案1

以前寫微信小程序的依賴庫(kù)時(shí)用過(guò)，使用gulp編譯，將源碼和編譯后的代碼分別放到src和dist兩個(gè)目錄。gulp會(huì)處理src下面的所有文件，將其中的scss轉(zhuǎn)換成css，并將其他所有文件原封不動(dòng)挪到dist下相應(yīng)位置。

這里就不詳細(xì)說(shuō)了，代碼參考Wux。

方案2

非常簡(jiǎn)單直接，使用Webstorm/IDEA的File Watchers功能實(shí)時(shí)轉(zhuǎn)換。

安裝Ruby和sass

確保命令行輸入sass -v能出現(xiàn)版本號(hào)，安裝過(guò)程略。

安裝File Watchers

到插件市場(chǎng)上搜索并安裝（已安裝則跳過(guò)）

添加scss的轉(zhuǎn)換腳本

現(xiàn)在安裝完插件打開(kāi)項(xiàng)目會(huì)自動(dòng)彈出scss轉(zhuǎn)css的向?qū)?，方便了很多。但還需要做一些修改，配置如下：

首先要將生成文件的后綴名改掉，比如這里我的淘寶小程序就得是acss。

其次，將Arguments改為:

$FileName$:$FileNameWithoutExtension$.acss --no-cache --sourcemap=none --default-encoding utf-8 --style expanded

如果不加--no-cache，scss文件同目錄下會(huì)出現(xiàn)一個(gè).sass-cache目錄。

如果不加--sourcemap=none, scss文件同目錄下會(huì)出現(xiàn)一個(gè).map文件。

如果不加--default-encoding utf-8, scss文件如果有中文注釋轉(zhuǎn)換就會(huì)報(bào)錯(cuò)。

style可不加，這里用的是無(wú)縮進(jìn)和壓縮的風(fēng)格，反正小程序打包發(fā)布時(shí)還會(huì)壓，這里保持可讀性。

現(xiàn)在這個(gè)scss轉(zhuǎn)換是單獨(dú)作用于項(xiàng)目的，如果新建一個(gè)小程序項(xiàng)目，就需要重新添加（不建議設(shè)置成global，容易誤傷）。

注意到File Watchers列表的右側(cè)操作欄下方有導(dǎo)入導(dǎo)出按鈕，可以將現(xiàn)在配好的設(shè)置導(dǎo)出保存，將來(lái)新建項(xiàng)目時(shí)只要導(dǎo)入一下就行了。

之后還有一個(gè)問(wèn)題，如果我手動(dòng)將編譯后的css（即wxss或者acss，下略）文件刪除，scss文件不改動(dòng)的話，就不會(huì)重新編譯出css文件。
或者萬(wàn)一監(jiān)聽(tīng)失效或者不夠及時(shí)，css還有可能是舊的。
所以還需要一個(gè)命令，用來(lái)將整個(gè)目錄下的scss文件統(tǒng)一轉(zhuǎn)換，確保沒(méi)有遺漏和保持代碼。

不過(guò)我看了半天sass和sass-convert的文檔，沒(méi)有找到一個(gè)可用的寫法，能讓命令行遍歷指定目錄下的所有scss文件，將其轉(zhuǎn)換成css放到源文件所在目錄，并且將后綴名改為wxss或者acss。

所以遍歷這個(gè)行為只能交給nodejs來(lái)實(shí)現(xiàn)，代碼如下：

創(chuàng)建編譯腳本build/scss-convert.js：

var path = require("path") var fs = require("fs") const { exec } = require('child_process') const basePath = path.resolve(__dirname, '../') function mapDir(dir, callback, finish) {
  fs.readdir(dir, function(err, files) { if (err) { console.error(err) return }
    files.forEach((filename, index) => { let pathname = path.join(dir, filename)
      fs.stat(pathname, (err, stats) => { // 讀取文件信息 if (err) { console.log('獲取文件stats失敗') return } if (stats.isDirectory()) {
          mapDir(pathname, callback, finish)
        } else if (stats.isFile()) { if (!['.scss'].includes(path.extname(pathname))) { return }
          callback(pathname)
        }
      }) if (index === files.length - 1) {
        finish && finish()
      }
    })
  })
}

mapDir(
  basePath, function (file) { const newFileWithoutExt = path.basename(file, '.scss') if (newFileWithoutExt.startsWith('_')) { return // 按照scss規(guī)則，下劃線開(kāi)頭的文件不會(huì)生成css } // exec可以讓nodejs執(zhí)行外部命令 exec(`sass --no-cache --sourcemap=none --default-encoding utf-8 --style expanded ${file}:${newFileWithoutExt}.acss`, { cwd: path.dirname(file) // 不寫這個(gè)會(huì)導(dǎo)致生成的文件出現(xiàn)在根目錄 }, (err, stdout, stderr) => { if (err) { console.log(err) return } console.log(`stdout: ${stdout}`)
    })
  }, function() { // console.log('xxx文件目錄遍歷完了') }
)

在package.json里添加一條script:

 "scripts": { "scss": "node build/scss-convert",
  },

定義

ES6 允許按照一定模式，從數(shù)組和對(duì)象中提取值，對(duì)變量進(jìn)行賦值，這被稱為解構(gòu)（Destructuring）



本質(zhì)上，這種寫法屬于“模式匹配”，只要等號(hào)兩邊的模式相同，左邊的變量就會(huì)被賦予對(duì)應(yīng)的值

如果解構(gòu)不成功，變量的值就等于undefined

解構(gòu)賦值的規(guī)則是，只要等號(hào)右邊的值不是對(duì)象或數(shù)組，就先將其轉(zhuǎn)為對(duì)象。由于undefined和null無(wú)法轉(zhuǎn)為對(duì)象，所以對(duì)它們進(jìn)行解構(gòu)賦值，都會(huì)報(bào)錯(cuò)、

解構(gòu)賦值的用途：

交換變量的值

例如：let x=1,y=2;[x,y] = [y,x]



從函數(shù)返回多個(gè)值

函數(shù)只能返回一個(gè)值，如果要返回多個(gè)值，只能將它們放在數(shù)組或?qū)ο罄锓祷?。有了解?gòu)賦值，取出這些值就非常方便



函數(shù)參數(shù)的定義

解構(gòu)賦值可以方便地將一組參數(shù)與變量名對(duì)應(yīng)起來(lái)



提取 JSON 數(shù)據(jù)，很多接口數(shù)據(jù)只需要其中某部分

例如aa.axios.get(res=>{let {data:result}=res;}),則res.data.result = result了



函數(shù)參數(shù)的默認(rèn)值

指定參數(shù)的默認(rèn)值，就避免了在函數(shù)體內(nèi)部再寫var foo = config.foo || ‘default foo’;這樣的語(yǔ)句



遍歷 Map 結(jié)構(gòu)

Map 結(jié)構(gòu)原生支持 Iterator 接口，配合變量的解構(gòu)賦值，獲取鍵名和鍵值就非常方便



輸入模塊的指定方法

加載模塊時(shí)，往往需要指定輸入哪些方法。解構(gòu)賦值使得輸入語(yǔ)句非常清晰。* const { SourceMapConsumer, SourceNode } = require(“source-map”);

1、數(shù)組的解構(gòu)賦值

左右兩側(cè)數(shù)據(jù)解構(gòu)須得吻合,或者等號(hào)左邊的模式，只匹配一部分的等號(hào)右邊的數(shù)組（屬于不完全解構(gòu)）



特殊情況使用…擴(kuò)展運(yùn)算符，無(wú)值是空數(shù)組



左右兩邊等式的性質(zhì)要相同，等號(hào)的右邊不是數(shù)組（或者嚴(yán)格地說(shuō)，不是可遍歷的結(jié)構(gòu)），那么將會(huì)報(bào)錯(cuò)，只要某種數(shù)據(jù)結(jié)構(gòu)具有 Iterator



接口，都可以采用數(shù)組形式的解構(gòu)賦值，例如Set結(jié)構(gòu)



解構(gòu)賦值允許指定默認(rèn)值，當(dāng)一個(gè)數(shù)組成員嚴(yán)格等于undefined，默認(rèn)值才會(huì)生效,否則取賦值的值；如果默認(rèn)值是一個(gè)表達(dá)式，那么這個(gè)表達(dá)式是惰性求值的，即只有在用到的時(shí)候，才會(huì)求值；默認(rèn)值可以引用解構(gòu)賦值的其他變量，但該變量必須已經(jīng)聲明

// 數(shù)組的解構(gòu)賦值
 let [a,b] = [1,2];
 console.log([a,b],a);//[1, 2] 1
 let [aa] = [11,22];
 console.log(aa)//11
 let [aaa,bbb] = [111];
 console.log(aaa,bbb)//111 undefined
 let [head, ...tail] = [1, 2, 3, 4];
 console.log(head,tail)//1,[2,3,4]
 let [x, y, ...z] = ['a'];
 console.log(x,y,z)//a undefined []
 // 等號(hào)右邊不是數(shù)組會(huì)報(bào)錯(cuò)
 // let [ab] = 121;
 // conosle.log(ab)//TypeError: 121 is not iterable
 // let [abc] = {}
 // conosle.log(abc)//TypeError: {} is not iterable
 // 默認(rèn)值賦值
 let [zz = 1] = [undefined];
 console.log(zz)//1
 let [zzz = 1] = [null];
 console.log(zzz)//null
 let [foo = true] = [];
 console.log(foo)// true
 let [xxx, yyy = 'b'] = ['a'];
 console.log(xxx,yyy)//a,b
 let [xxxx, yyyy = 'b'] = ['a', undefined]; 
 console.log(xxxx,yyyy)//a,b
 function f() {
   console.log('aaa');
 }
 let [xx = f()] = [1];
 console.log(xx)//1
 let [qq=ww,ww=11] = [23,44];
 console.log(qq,ww)//23,44,因?yàn)閣w申明比qq晚所以是undefined；

2、對(duì)象的解構(gòu)賦值
對(duì)象的解構(gòu)賦值的內(nèi)部機(jī)制，是先找到同名屬性，然后再賦給對(duì)應(yīng)的變量。真正被賦值的是后者，而不是前者

數(shù)組是按照位置區(qū)分，對(duì)象則是按照鍵名區(qū)分的,同樣的解構(gòu)失敗則為undefine
可將已有方法對(duì)象解構(gòu)賦值
嵌套賦值，注意是變量是否被賦值是模式還是鍵值
對(duì)象的解構(gòu)賦值可以取到繼承的屬性
如果要將一個(gè)已經(jīng)聲明的變量用于解構(gòu)賦值，必須非常小心
let xx; // {xx} = {xx: 1}這樣會(huì)報(bào)錯(cuò)，

解構(gòu)賦值允許等號(hào)左邊的模式之中，不放置任何變量名。因此，可以寫出非常古怪的賦值表達(dá)式
({} = [true, false]);//可執(zhí)行

由于數(shù)組本質(zhì)是特殊的對(duì)象，因此可以對(duì)數(shù)組進(jìn)行對(duì)象屬性的解構(gòu)

objFuc(){
            // 對(duì)象解構(gòu)賦值
            let {b,a} = {a:1}
            console.log(a,b)//1 undefined
            // 已有對(duì)象解構(gòu)賦值
            let { sin, cos } = Math;//將Math對(duì)象的對(duì)數(shù)、正弦、余弦三個(gè)方法，賦值到對(duì)應(yīng)的變量上
            console.log(sin);//log() { [native code] }
            const { log } = console;
            log('hello') // hello
            // 
            let { foo: baz } = { foo: 'aaa', bar: 'bbb' };
            console.log(baz);//aaa
            // 嵌套賦值
            let obj = {
              p: [
                'Hello',
                { y: 'World' }
              ]
            };
            let { p,p:[x, { y }] } = obj;
            console.log(x,y,p)//Hello World p: ['Hello',{ y: 'World' }]
            //繼承賦值
            const obj1 = {};
            const obj2 = { foo: 'bar' };
            Object.setPrototypeOf(obj1, obj2);//obj1繼承obj2
            const { foo } = obj1;
            console.log(foo) // "bar"
            // 默認(rèn)值
            // 錯(cuò)誤的寫法
            let xx;
            // {xx} = {xx: 1};// SyntaxError: syntax error,Uncaught SyntaxError: Unexpected token '='
            ({xx} = {xx: 1});//正確寫法
            console.log(xx)
            // 古怪的，等式左邊可為空
            // ({} = [true, false]);
            // 對(duì)象可解構(gòu)數(shù)組
            let arr = [1, 2, 3];
            let {0 : first, [arr.length - 1] : last} = arr;
            console.log(first,last)//1 3
        },

3、字符串的解構(gòu)賦值

• 字符串賦值
• 類似數(shù)組的對(duì)象都有一個(gè)length屬性，因此還可以對(duì)這個(gè)屬性解構(gòu)賦值

strFuc(){
            // str:'yan_yan'
            let [a,b,c,d,e,f,g] = this.str;
            console.log(a,b,c,d,e,f,g)//y a n _ y a n
            // 對(duì)數(shù)組屬性解構(gòu)賦值
            let {length} = this.str;
            console.log(length)//7
        },

    

        4、數(shù)值和布爾值的解構(gòu)賦值
    

    


        

            解構(gòu)賦值時(shí)，如果等號(hào)右邊是數(shù)值和布爾值，則會(huì)先轉(zhuǎn)為對(duì)象
        

        

            解構(gòu)賦值的規(guī)則是，只要等號(hào)右邊的值不是對(duì)象或數(shù)組，就先將其轉(zhuǎn)為對(duì)象。由于undefined和null無(wú)法轉(zhuǎn)為對(duì)象，所以對(duì)它們進(jìn)行解構(gòu)賦值，都會(huì)報(bào)錯(cuò)
        

    

let {toString: s} = 123;
console.log(s === Number.prototype.toString,s)//true ? toString() { [native code] }
let {toString: ss} = true;
console.log(ss === Boolean.prototype.toString,ss)// true ? toString() { [native code] }
// 右側(cè)必須是數(shù)組或?qū)ο螅瑄ndefined和null無(wú)法轉(zhuǎn)為對(duì)象，所以對(duì)它們進(jìn)行解構(gòu)賦值，都會(huì)報(bào)錯(cuò)
// let { prop: x } = undefined; // TypeError
// let { prop: y } = null; // TypeError

    

        5、函數(shù)參數(shù)的解構(gòu)賦值
    

    


        

            也可使用默認(rèn)值，注意默認(rèn)值是指實(shí)參的默認(rèn)值而不是形參的默認(rèn)值
        

    

// 函數(shù)的解構(gòu)賦值可使用默認(rèn)值，注意默認(rèn)值是指實(shí)參的默認(rèn)值而不是形參的默認(rèn)值
            function move({x=1, y=1}={}) {
              return [x, y];
            }
            function move1({x, y} = { x: 0, y: 0 }) {
              return [x, y];
            }
            function move2({x, y=1} = { x: 0, y: 0 }) {
              return [x, y];
            }
            console.log(move({x: 3, y: 8})); // [3, 8]
            console.log(move({x: 3})); // [3, 1]
            console.log(move({})); // [1, 1]
            console.log(move()); // [1,1]
            console.log(move1({x: 3, y: 8})); // [3, 8]
            console.log(move1({x: 3})); // [3, 1]
            console.log(move1({})); // [undefined, 1]
            console.log(move1()); // [0,0]
            console.log(move2({x: 3, y: 8})); // [3, 8]
            console.log(move2({x: 3})); // [3, 1]
            console.log(move2({})); // [undefined, 1]
            console.log(move2()); // [0,0]

6、圓括號(hào)問(wèn)題
解構(gòu)賦值雖然很方便，但是解析起來(lái)并不容易。對(duì)于編譯器來(lái)說(shuō)，一個(gè)式子到底是模式，還是表達(dá)式，沒(méi)有辦法從一開(kāi)始就知道，必須解析到（或解析不到）等號(hào)才能知道。
由此帶來(lái)的問(wèn)題是，如果模式中出現(xiàn)圓括號(hào)怎么處理。ES6 的規(guī)則是，只要有可能導(dǎo)致解構(gòu)的歧義，就不得使用圓括號(hào)。
可以使用圓括號(hào)的情況只有一種：賦值語(yǔ)句的非模式部分，可以使用圓括號(hào)
總結(jié)：
不管是哪一類的解構(gòu)賦值，等式右邊的數(shù)據(jù)必須是對(duì)象形式（數(shù)組也是一種對(duì)象形式）
————————————————
版權(quán)聲明：本文為CSDN博主「Yan_an_n」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/weixin_44258964/article/details/105643553

目錄

HTTP協(xié)議

HTTP請(qǐng)求：

HTTP響應(yīng)：

會(huì)話與會(huì)話狀態(tài)：

Cookie

Session

Cookie和Session的區(qū)別

HTTP協(xié)議


 HTTP請(qǐng)求：
Post /test.php HTTP/1.1                               //請(qǐng)求行以一個(gè)方法符號(hào)開(kāi)頭，以空格分開(kāi)，后面跟著請(qǐng)求的URI和協(xié)議的版本

Host: www.test.com                                       //請(qǐng)求頭

User-agent:mozilla/5.0(windows NT 6.1: rv: 15.0)

Gecko/20100101 firefox15.0

                                                                                    //空白行，代表請(qǐng)求頭結(jié)束

Username=admin&passwd=admin                             //請(qǐng)求正文

HTTP請(qǐng)求方法



GET       請(qǐng)求獲取Request-URI所標(biāo)識(shí)的資源

POST     在Request-URI所標(biāo)識(shí)的資源后附加新的數(shù)據(jù)

HEAD    請(qǐng)求獲取由Request-URI所標(biāo)識(shí)的資源的響應(yīng)消息報(bào)頭

PUT       請(qǐng)求服務(wù)器存儲(chǔ)一個(gè)資源，并用Request-URI作為其標(biāo)識(shí)

常用的為GET和POST；GET和POST的區(qū)別：

GET提交的內(nèi)容會(huì)直接顯示在URL中，私密性較差，可以用于顯示一些公共資源；但是GET效率會(huì)比較高。

POST不會(huì)將內(nèi)容顯示在URL中，可以用于提交一些敏感數(shù)據(jù)，例如用戶名或密碼。

HTTP響應(yīng)：
HTTP/1.1 200 OK                                         //響應(yīng)行由協(xié)議版本號(hào)，響應(yīng)狀態(tài)碼和文本描述組成

Data：sun，15 nov 2018 11:02:04  GMT    //響應(yīng)頭

Server：bfe/1.0.8.9

……

Connection: keep-alive

                                                                      //空白行，代表響應(yīng)頭結(jié)束

<html>

</html><title>index.heml</title>                  //響應(yīng)正文

HTTP的狀態(tài)碼：

狀態(tài)代碼由三位數(shù)字組成，第一個(gè)數(shù)字定義了響應(yīng)的類別，且有五種可能取值。

1xx：指示信息 —— 表示請(qǐng)求已接收，繼續(xù)處理。

2xx：成功 —— 表示請(qǐng)求已被成功接收、理解、接受。

3xx：重定向 —— 要完成請(qǐng)求必須進(jìn)行更進(jìn)一步的操作。

4xx：客戶端錯(cuò)誤 —— 請(qǐng)求有語(yǔ)法錯(cuò)誤或請(qǐng)求無(wú)法實(shí)現(xiàn)。

5xx：服務(wù)器端錯(cuò)誤 —— 服務(wù)器未能實(shí)現(xiàn)合法的請(qǐng)求。

常見(jiàn)狀態(tài)代碼、狀態(tài)描述的說(shuō)明如下。

200 OK：客戶端請(qǐng)求成功。

400 Bad Request：客戶端請(qǐng)求有語(yǔ)法錯(cuò)誤，不能被服務(wù)器所理解。

401 Unauthorized：請(qǐng)求未經(jīng)授權(quán)，這個(gè)狀態(tài)代碼必須和 WWW-Authenticate 報(bào)頭域一起使用。

403 Forbidden：服務(wù)器收到請(qǐng)求，但是拒絕提供服務(wù)。

404 Not Found：請(qǐng)求資源不存在，舉個(gè)例子：輸入了錯(cuò)誤的URL。

500 Internal Server Error：服務(wù)器發(fā)生不可預(yù)期的錯(cuò)誤。

503 Server Unavailable：服務(wù)器當(dāng)前不能處理客戶端的請(qǐng)求，一段時(shí)間后可能恢復(fù)正常。

會(huì)話與會(huì)話狀態(tài)：
       Web中的會(huì)話是指一個(gè)客戶端瀏覽器與web服務(wù)器之間連續(xù)發(fā)生一系列請(qǐng)求和響應(yīng)過(guò)程。會(huì)話狀態(tài)是指在會(huì)話過(guò)程中產(chǎn)生的狀態(tài)信息；借助會(huì)話狀態(tài)，web服務(wù)器能夠把屬于同一會(huì)話中的一系列的請(qǐng)求和響應(yīng)關(guān)聯(lián)起來(lái)。

Cookie
概述

       Cookie是一種在客戶端保持HTTP狀態(tài)信息的技術(shù)，它好比商場(chǎng)發(fā)放的優(yōu)惠卡。在瀏覽器訪問(wèn)Web服務(wù)器的某個(gè)資源時(shí)，由Web服務(wù)器在在HTTP響應(yīng)頭中附帶傳送給瀏覽器一片數(shù)據(jù)，web服務(wù)器傳送給各個(gè)客戶端瀏覽器的數(shù)據(jù)是可以各不相同的。

       一旦Web瀏覽器保存了某個(gè)Cookie，那么它在以后每次訪問(wèn)該Web服務(wù)器是都應(yīng)在HTTP請(qǐng)求頭中將這個(gè)Cookie回傳個(gè)Web服務(wù)器。Web服務(wù)器通過(guò)在HTTP響應(yīng)消息中增加Set-Cookie響應(yīng)頭字段將CooKie信息發(fā)送給瀏覽器，瀏覽器則通過(guò)在HTTP請(qǐng)求消息中增加Cookie請(qǐng)求頭字段將Cookie回傳給Web服務(wù)器。

       一個(gè)Cookie只能標(biāo)識(shí)一種信息，它至少含有一個(gè)標(biāo)識(shí)該消息的名稱（NAME）和和設(shè)置值（VALUE）。一個(gè)Web瀏覽器也可以存儲(chǔ)多個(gè)Web站點(diǎn)提供的Cookie。瀏覽器一般只允許存放300個(gè)Cookie，每個(gè)站點(diǎn)最多存放20個(gè)Cookie，每個(gè)Cookie的大小限制為4KB。

傳送示意圖



特點(diǎn)

存儲(chǔ)于瀏覽器頭部/傳輸與HTTP頭部，寫時(shí)帶屬性，讀時(shí)無(wú)屬性。由三元【name，domain，path】唯一確定Cookie。

Set-Cookie2響應(yīng)頭字段

Set-Cookie2頭字段用于指定WEB服務(wù)器向客戶端傳送的Cookie內(nèi)容，但是按照Netscape規(guī)范實(shí)現(xiàn)Cookie功能的WEB服務(wù)器， 使用的是Set-Cookie頭字段，兩者的語(yǔ)法和作用類似。Set-Cookie2頭字段中設(shè)置的cookie內(nèi)容是具有一定格式的字符串，它必須以Cookie的名稱和設(shè)置值開(kāi)頭，格式為"名稱=值”,后面可以加上0個(gè)或多個(gè)以分號(hào)(;) 和空格分隔的其它可選屬性，屬性格式一般為 "屬性名=值”。

除了“名稱=值”對(duì)必須位于最前面外，其他的可選屬性可以任意。Cookie的名稱只能由普通的英文ASCII字符組成，瀏覽器不用關(guān)心和理解Cookie的值部分的意義和格式，只要WEB服務(wù)器能理解值部分的意義就行。大多數(shù)現(xiàn)有的WEB服務(wù)器都是采用某種編碼方式將值部分的內(nèi)容編碼成可打印的ASCII字符，RFC 2965規(guī)范中沒(méi)有明確限定編碼方式。

舉例:   Set-Cookie2: user-hello; Version=1; Path=/

Cookie請(qǐng)求頭字段

Cookie請(qǐng)求頭字段中的每個(gè)Cookie之間用逗號(hào)（，）或分號(hào)（；）分隔。在Cookie請(qǐng)求字段中除了必須有“名稱=值”的設(shè)置外，還可以有Version、path、domain、port等屬性；在Version、path、domain、port等屬性名之前，都要增加一個(gè)“$”字符作為前綴。Version屬性只能出現(xiàn)一次，且要位于Cookie請(qǐng)求頭字段設(shè)置值的最前面，如果需要設(shè)置某個(gè)Cookie信息的Path、Domain、Port等屬性，它們必須位于該Cookie信息的“名稱=值”設(shè)置之后。

       瀏覽器使用Cookie請(qǐng)求頭字段將Cookie信息會(huì)送給Web服務(wù)器；多個(gè)Cookie信息通過(guò)一個(gè)Cookie請(qǐng)求頭字段會(huì)送給Web服務(wù)器。

瀏覽器會(huì)根據(jù)下面幾個(gè)規(guī)則決定是否發(fā)送某個(gè)Cookie信息：

       1、請(qǐng)求主機(jī)名是否與某個(gè)存儲(chǔ)的Cookie的Domain屬性匹配

       2、請(qǐng)求的端口號(hào)是否在該Cookie的Port屬性列表中

       3、請(qǐng)求的資源路徑是否在該Cookie的Path屬性指定的目錄及子目錄中

       4、該Cookie的有效期是否已過(guò)

Path屬性的指向子目錄的Cookie排在Path屬性指向父目錄的Cookie之前

舉例: Cookie: $Version=1; Course=Java; $Path=/hello/lesson;Course=vc; $Path=/hello

Cookie的安全屬性

secure屬性

當(dāng)設(shè)置為true時(shí)，表示創(chuàng)建的Cookie會(huì)被以安全的形式向服務(wù)器傳輸，也就是只能在HTTPS連接中被瀏覽器傳遞到服務(wù)器端進(jìn)行會(huì)話驗(yàn)證，如果是HTTP連接則不會(huì)傳遞該信息，所以不會(huì)被竊取到Cookie的具體內(nèi)容。

 HttpOnly屬性

如果在Cookie中設(shè)置了"HttpOnly"屬性，那么通過(guò)程序(JS腳本、Applet等)將無(wú)法讀取到Cookie信息，這樣能有效的防止XSS攻擊。

總結(jié)：secure屬性 是防止信息在傳遞的過(guò)程中被監(jiān)聽(tīng)捕獲后信息泄漏，HttpOnly屬性的目的是防止程序獲取cookie后進(jìn)行攻擊這兩個(gè)屬性并不能解決cookie在本機(jī)出現(xiàn)的信息泄漏的問(wèn)題(FireFox的插件FireBug能直接看到cookie的相關(guān)信息)。

Session
使用Cookie和附加URL參數(shù)都可以將上一-次請(qǐng)求的狀態(tài)信息傳遞到下一次請(qǐng)求中，但是如果傳遞的狀態(tài)信息較多，將極大降低網(wǎng)絡(luò)傳輸效率和增大服務(wù)器端程序處理的難度。

概述

Session技術(shù)是一種將會(huì)話狀態(tài)保存在服務(wù)器端的技術(shù)，它可以比喻成是醫(yī)院發(fā)放給病人的病歷卡和醫(yī)院為每個(gè)病人保留的病歷檔案的結(jié)合方式?？蛻舳诵枰邮?、記憶和回送Session的會(huì)話標(biāo)識(shí)號(hào)，Session可以且通常是借助Cookie來(lái)傳遞會(huì)話標(biāo)識(shí)號(hào)。



Session的跟蹤機(jī)制

HttpSession對(duì)象是保持會(huì)話狀態(tài)信息的存儲(chǔ)結(jié)構(gòu)，一個(gè)客戶端在WEB服務(wù)器端對(duì)應(yīng)一個(gè)各自的HttpSession對(duì)象。WEB服務(wù)器并不會(huì)在客戶端開(kāi)始訪問(wèn)它時(shí)就創(chuàng)建HttpSession對(duì)象，只有客戶端訪問(wèn)某個(gè)能與客戶端開(kāi)啟會(huì)話的服務(wù)端程序時(shí)，WEB應(yīng)用程序才會(huì)創(chuàng)建一個(gè)與該客戶端對(duì)應(yīng)的HttpSession對(duì)象。WEB服務(wù)器為HttpSession對(duì)象分配一個(gè)獨(dú)一無(wú)的會(huì)話標(biāo)識(shí)號(hào)， 然后在響應(yīng)消息中將這個(gè)會(huì)話標(biāo)識(shí)號(hào)傳遞給客戶端?？蛻舳诵枰涀?huì)話標(biāo)識(shí)號(hào)，并在后續(xù)的每次訪問(wèn)請(qǐng)求中都把這個(gè)會(huì)話標(biāo)識(shí)號(hào)傳送給WEB服務(wù)器，WEB服務(wù)器端程序依據(jù)回傳的會(huì)話標(biāo)識(shí)號(hào)就知道這次請(qǐng)求是哪個(gè)客戶端發(fā)出的，從而選擇與之對(duì)應(yīng)的HttpSession對(duì)象。

WEB應(yīng)用程序創(chuàng)建了與某個(gè)客戶端對(duì)應(yīng)的HttpSession對(duì)象后，只要沒(méi)有超出一個(gè)限定的空閑時(shí)間段，HttpSession對(duì)象就駐留在WEB服務(wù)器內(nèi)存之中，該客戶端此后訪問(wèn)任意的Servlet程序時(shí)，它們都使用與客戶端對(duì)應(yīng)的那個(gè)已存在的HttpSession對(duì)象。

Session是實(shí)現(xiàn)網(wǎng)上商城的購(gòu)物車的最佳方案，存儲(chǔ)在某個(gè)客戶Session中的一個(gè)集合對(duì)象就可充當(dāng)該客戶的一個(gè)購(gòu)物車。

超時(shí)管理

WEB服務(wù)器無(wú)法判斷當(dāng)前的客戶端瀏覽器是否還會(huì)繼續(xù)訪問(wèn)，也無(wú)法檢測(cè)客戶端瀏覽器是否關(guān)閉，所以，即使客戶已經(jīng)離開(kāi)或關(guān)閉了瀏覽器，WEB服務(wù)器還要保留與之對(duì)應(yīng)的HttpSession對(duì)象。隨著時(shí)間的推移而不斷增加新的訪問(wèn)客戶端，WEB服務(wù)器內(nèi)存中將會(huì)因此積累起大量的不再被使用的HttpSession對(duì)象，并將最終導(dǎo)致服務(wù)器內(nèi)存耗盡。WEB服務(wù)器采用“超時(shí)限制”的辦法來(lái)判斷客戶端是否還在繼續(xù)訪問(wèn)如果某個(gè)客戶端在一定的時(shí)間之 內(nèi)沒(méi)有發(fā)出后續(xù)請(qǐng)求，WEB服務(wù)器則認(rèn)為客戶端已經(jīng)停止了活動(dòng)，結(jié)束與該客戶端的會(huì)話并將與之對(duì)應(yīng)的HttpSession對(duì)象變成垃圾。

如果客戶端瀏覽器超時(shí)后再次發(fā)出訪問(wèn)請(qǐng)求，Web服務(wù)器則認(rèn)為這是一個(gè)新的會(huì)話開(kāi)始，將為之創(chuàng)建新的Httpsession對(duì)象和分配新的會(huì)話標(biāo)識(shí)號(hào)。

利用Cookie實(shí)現(xiàn)Session的跟蹤

如果WEB服務(wù)器處理某個(gè)訪問(wèn)請(qǐng)求時(shí)創(chuàng)建了新的HttpSession對(duì)象，它將把會(huì)話標(biāo)識(shí)號(hào)作為一個(gè)Cookie項(xiàng)加入到響應(yīng)消息中，通常情況下，瀏覽器在隨后發(fā)出的訪問(wèn)請(qǐng)求中又將會(huì)話標(biāo)識(shí)號(hào)以Cookie的形式回傳給WEB服務(wù)器。WEB服務(wù)器端程序依據(jù)回傳的會(huì)話標(biāo)識(shí)號(hào)就知道以前已經(jīng)為該客戶端創(chuàng)建了HttpSession對(duì)象，不必再為該客戶端創(chuàng)建新的HttpSession對(duì)象，而是直接使用與該會(huì)話標(biāo)識(shí)號(hào)匹配的HttpSession對(duì)象，通過(guò)這種方式就實(shí)現(xiàn)了對(duì)同一個(gè)客戶端的會(huì)話狀態(tài)的跟蹤。

利用URL重寫實(shí)現(xiàn)Session跟蹤

Servlet規(guī)范中引入了一種補(bǔ)充的會(huì)話管理機(jī)制，它允許不支持Cookie的瀏覽器也可以與WEB服務(wù)器保持連續(xù)的會(huì)話。這種補(bǔ)充機(jī)制要求在響應(yīng)消息的實(shí)體內(nèi)容中必須包含下一 次請(qǐng)求的超鏈接，并將會(huì)話標(biāo)識(shí)號(hào)作為超鏈接的URL地址的一個(gè)特殊參數(shù)。將會(huì)話標(biāo)識(shí)號(hào)以參數(shù)形式附加在超鏈接的URL地址后面的技術(shù)稱為URL重寫。 如果在瀏覽器不支持Cookie或者關(guān)閉了Cookie功能的情況下，WEB服務(wù)器還要能夠與瀏覽器實(shí)現(xiàn)有狀態(tài)的會(huì)話，就必須對(duì)所有能被客戶端訪問(wèn)的請(qǐng)求路徑(包括超鏈接、form表單的action屬性設(shè)置和重定向的URL)進(jìn)行URL重寫。

Cookie和Session的區(qū)別
session和cookies同樣都是針對(duì)單獨(dú)用戶的變量(或者說(shuō)是對(duì)象好像更合適點(diǎn))，不同的用戶在訪問(wèn)網(wǎng)站的時(shí)候都會(huì)擁有各自的session或者cookies,不同用戶之間互不干擾。

他們的不同點(diǎn)是:

1,存儲(chǔ)位置不同

session在服務(wù)器端存儲(chǔ)，比較安全，但是如果session較多則會(huì)影響性能

cookies在客戶端存儲(chǔ)，存在較大的安全隱患

2，生命周期不同

session生命周期在指定的時(shí)間(如20分鐘) 到了之后會(huì)結(jié)束，不到指定的時(shí)間，也會(huì)隨著瀏覽器進(jìn)程的結(jié)束而結(jié)束。

cookies默認(rèn)情況下也隨著瀏覽器進(jìn)程結(jié)束而結(jié)束，但如果手動(dòng)指定時(shí)間，則不受瀏覽器進(jìn)程結(jié)束的影響。

總結(jié)：簡(jiǎn)而言之，兩者都是保存了用戶操作的歷史信息，但是存在的地方不同；而且session和cookie的目的相同，都是為了克服HTTP協(xié)議無(wú)狀態(tài)的缺陷，但是完成方法不同。Session通過(guò)cookie在客戶端保存session id，將用戶的其他會(huì)話消息保存在服務(wù)端的session對(duì)象中；而cookie需要將所有信息都保存在客戶端，因此存在著一定的安全隱患，例如本地Cookie中可能保存著用戶名和密碼，容易泄露。
————————————————
版權(quán)聲明：本文為CSDN博主「悲觀的樂(lè)觀主義者」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/weixin_43997530/article/details/105650267

js中cookie的使用（設(shè)置和獲取cookie緩存）
生為一個(gè)已經(jīng)入職一年多的前端小白，第一次寫博客還有點(diǎn)小激動(dòng)，有不足的地方還希望大家多多指出，因?yàn)樽罱?xiàng)目有涉及到利用cookie緩存數(shù)據(jù)，所以在這邊再鞏固一下。

1、cookie的定義
在使用瀏覽器中，經(jīng)常涉及到數(shù)據(jù)的交換，比如你登錄系統(tǒng)賬號(hào)，登錄一個(gè)頁(yè)面。我們經(jīng)常會(huì)在此時(shí)設(shè)置記住賬號(hào)啥的，或者自動(dòng)登錄選項(xiàng)。那這些都是怎么實(shí)現(xiàn)的呢，答案就是今天的主角cookie了，Cookie是由HTTP服務(wù)器設(shè)置的，保存在瀏覽器中，但HTTP協(xié)議是一種無(wú)狀態(tài)協(xié)議，在數(shù)據(jù)交換完畢后，服務(wù)器端和客戶端的鏈接就會(huì)關(guān)閉，每次交換數(shù)據(jù)都需要建立新的鏈接。
從JavaScript的角度看，cookie 就是一些字符串信息。這些信息存放在客戶端的計(jì)算機(jī)中，用于客戶端計(jì)算機(jī)與服務(wù)器之間傳遞信息。
在JavaScript中可以通過(guò) document.cookie 來(lái)讀取或設(shè)置這些信息。由于 cookie 多用在客戶端和服務(wù)端之間進(jìn)行通信，所以除了JavaScript以外，服務(wù)端的語(yǔ)言（如PHP）也可以存取 cookie。

2、cookie的使用
設(shè)置cookie
function setCookie(c_name, value, expiredays) {
       var exdate = new Date()
       exdate.setDate(exdate.getDate() + expiredays)
       document.cookie = c_name + "=" + escape(value) +
           ((expiredays == null) ? "" : ";expires=" + exdate.toGMTString())+";path=/";
   }
1
2
3
4
5
6
調(diào)用該方法如：

var userId="123456";
setCookie("userId", userId, 30);
1
2
下面是里面參數(shù)的意義

參數(shù) 含義
c_name 自己定義的cookie名稱
value 需要放在定義的c_name 中的值
expiredays cookie的有效期
這里有一個(gè)要注意點(diǎn)就是 " path=/"
" path=/"是只存下的cookie再該項(xiàng)目所有頁(yè)面都能去獲取，如果你想只存到弄個(gè)特定目錄可以在path中指定路徑，如：“path=/views/myHomePage”,z這樣你可以在/views/myHomePage文件下所有頁(yè)面都能取到你存的cookie了。

取回cookie
 function getCookie(c_name) {
        if (document.cookie.length > 0) {
            c_start = document.cookie.indexOf(c_name + "=")
            if (c_start != -1) {
                c_start = c_start + c_name.length + 1
                c_end = document.cookie.indexOf(";", c_start)
                if (c_end == -1) c_end = document.cookie.length
                return unescape(document.cookie.substring(c_start, c_end))
            }
        }
        return ""
    }
1
2
3
4
5
6
7
8
9
10
11
12
調(diào)用該方法如：

var newUserId= getCookie("userId");
console.log(newUserId)
alert(newUserId)
————————————————
版權(quán)聲明：本文為CSDN博主「前端陳偉霆」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/weixin_43927397/article/details/105658614

痛點(diǎn)

目前眾多的網(wǎng)文產(chǎn)品中，設(shè)計(jì)同質(zhì)化比較高，無(wú)論是產(chǎn)品視覺(jué)或是品牌運(yùn)營(yíng)視覺(jué)大多都缺乏獨(dú)創(chuàng)性與統(tǒng)一性。番茄小說(shuō)想要從眾多產(chǎn)品中脫穎而出就需要走出一條合而不同的設(shè)計(jì)道路。因此提升產(chǎn)品的識(shí)別度與消費(fèi)者對(duì)品牌的認(rèn)知?jiǎng)菰诒匦?，設(shè)計(jì)需探索構(gòu)建一套屬于產(chǎn)品的語(yǔ)言體系。

解決方法

探索番茄小說(shuō)的設(shè)計(jì)語(yǔ)言，建立產(chǎn)品認(rèn)知

1. 文學(xué)特性——傳統(tǒng)、網(wǎng)絡(luò)的冷與熱

傳統(tǒng)文學(xué)

文學(xué)分為兩類，嚴(yán)肅文學(xué)（看重語(yǔ)言和細(xì)節(jié)）、通俗文學(xué)（注重情節(jié)和故事，淺顯易懂）。

周憲《文學(xué)理論導(dǎo)引》里定義「文學(xué)是以精致語(yǔ)言書寫的具有藝術(shù)價(jià)值的以文本為中心的文化系統(tǒng)。」通過(guò)定義可以概括出文學(xué)的特點(diǎn)就是具有藝術(shù)價(jià)值，并且能夠通過(guò)文字內(nèi)容帶人用戶反思或者收獲。當(dāng)人們?cè)陂喿x文學(xué)書籍時(shí)是冷靜的，只有在這樣的心境下讀者才能更好的獨(dú)立思考與分析。因此在氛圍上需要給用戶提供一個(gè)相對(duì)沉浸的空間、安逸的環(huán)境，通過(guò)分析可以提煉出的傳統(tǒng)文學(xué)情緒關(guān)鍵詞：沉浸、冷靜、舒適、價(jià)值

網(wǎng)絡(luò)文學(xué)

不同于傳統(tǒng)文學(xué)，網(wǎng)絡(luò)文學(xué)是順應(yīng)市場(chǎng)價(jià)值而誕生，是文學(xué)創(chuàng)作的平民化，讓大家能夠以網(wǎng)絡(luò)為載體而發(fā)表的文字內(nèi)容。廣義來(lái)說(shuō)，網(wǎng)絡(luò)文學(xué)屬于通俗文學(xué)的一類，注重情節(jié)和故事，通過(guò)文字傳遞的內(nèi)容更加的樸實(shí)、接地氣，在創(chuàng)作分類上也更加的多樣化，作者可以天馬行空的表達(dá)自己感受，可以說(shuō)是在傳統(tǒng)文學(xué)的基礎(chǔ)上，給文字增加了幾分煙火氣息，也多了幾分熱鬧的感受。

因此通過(guò)文學(xué)關(guān)鍵詞可擴(kuò)展出網(wǎng)絡(luò)文學(xué)情緒關(guān)鍵詞：沉浸、愉悅、煙火氣

2. 調(diào)研分析

前期通過(guò)對(duì)小說(shuō)用戶群體與市場(chǎng)的走訪調(diào)研，并通過(guò)數(shù)據(jù)分析，我們得到了如下結(jié)論：

產(chǎn)品用戶類型

12-50歲青中年人；后GenX時(shí)代；一二三線城市有閱讀小說(shuō)習(xí)慣的人群；目前為對(duì)生活充滿向往的學(xué)生與藍(lán)領(lǐng)

產(chǎn)品品牌人格

樂(lè)觀愉悅（輕松）；品質(zhì)（書好）；親民、豐富（書多）

產(chǎn)品視覺(jué)風(fēng)格

品牌色貫穿產(chǎn)品，但不過(guò)分使用；視覺(jué)為產(chǎn)品功能服務(wù)，不做多余的設(shè)計(jì)；視覺(jué)表現(xiàn)多樣化，但需要表達(dá)相同的產(chǎn)品氣質(zhì)；適度的留白，增強(qiáng)設(shè)計(jì)空間感

3. 小說(shuō)產(chǎn)品特性

產(chǎn)品核心詞：「沉浸中的愉悅」

正如我們對(duì)文學(xué)的分析，小說(shuō)閱讀同樣是一種獨(dú)立個(gè)體的行為方式，在讀書時(shí)，我們不希望被人打擾，不希望被瑣事細(xì)節(jié)阻斷，我們希望在一個(gè)相對(duì)安靜、舒適的環(huán)境下閱讀，這是一種沉浸式的感受。

因此這里我們就根據(jù)用戶的想要的感受，引入「沉浸」的概念——希望能夠給讀者留下一定的空間，并拋除繁雜打擾，讓大家享受閱讀與獨(dú)立思考。其核心是圍繞信息內(nèi)容本身而呈現(xiàn)，設(shè)計(jì)不再作為獨(dú)立于內(nèi)容之外的元素存在，而將著眼于內(nèi)容本身，為用戶打造直觀的視覺(jué)體驗(yàn)。拉大層級(jí)對(duì)比，增加適當(dāng)?shù)牧舭祝谝欢ǔ潭壬显黾由僭S修飾，打破絕對(duì)的冷淡。其既能體現(xiàn)出文學(xué)的特點(diǎn)，又能夠在簡(jiǎn)約的基礎(chǔ)上增加畫面的構(gòu)成感，給用戶愉悅的感受。

觸感

網(wǎng)絡(luò)小說(shuō)與傳統(tǒng)文學(xué)另外一個(gè)最大的區(qū)別是觸感。

傳統(tǒng)文學(xué)大多以實(shí)體書籍紙張為承載，而網(wǎng)絡(luò)文學(xué)來(lái)自于互聯(lián)網(wǎng)是虛擬的。我們?cè)陂喿x時(shí)，觸摸紙張與書本樸實(shí)的質(zhì)感，也能夠給讀者帶來(lái)額外的舒適感受，因此如果能以視覺(jué)的形式還原用戶對(duì)書籍的「觸感」，不僅能夠?qū)⒕W(wǎng)絡(luò)與實(shí)體相鏈接，也可以幫助用戶增加電子閱讀的樂(lè)趣。

4. 建立番茄小說(shuō)情緒版

根據(jù)歸納出的文學(xué)特征，以及調(diào)研用戶年齡層與喜好，我們可以歸納出番茄小說(shuō)基礎(chǔ)原生關(guān)鍵詞。

基礎(chǔ)原生關(guān)鍵詞

拓展衍生關(guān)鍵詞

根據(jù)網(wǎng)絡(luò)文學(xué)原生關(guān)鍵詞，我們拓展出衍生詞

• 沉浸：安靜、干凈、整潔、內(nèi)部、深色
• 煙火氣：城市、中國(guó)風(fēng)、武俠、繪畫、美女
• 愉悅：跳躍、陽(yáng)光、水果、溫暖、火熱
• 觸感：紙張、磨砂、紋理、褶皺、斑駁

圖片搜索、提取情緒版

根據(jù)相關(guān)的衍生關(guān)鍵詞，我們收集大量的視覺(jué)圖片并將其匯總，借以分析其視覺(jué)特征

色彩提取

視覺(jué)映射

通過(guò)對(duì)情緒版的分析，我們可以得出結(jié)論并整理出番茄小說(shuō)設(shè)計(jì)語(yǔ)言，輕量的色彩、寫意式元素、非對(duì)稱布局、紙紋理噪點(diǎn)

番茄小說(shuō)設(shè)計(jì)語(yǔ)言

將傳統(tǒng)的冷靜沉浸與網(wǎng)絡(luò)文學(xué)的熱鬧向融合是番茄小說(shuō)設(shè)計(jì)語(yǔ)言的重要視覺(jué)呈現(xiàn)方式風(fēng)格

多元化的簡(jiǎn)約設(shè)計(jì)+情感化修飾

• 簡(jiǎn)潔：簡(jiǎn)約，做不飽和的設(shè)計(jì)，給用戶空間感、想象的余地
• 趣味：暖色+趣味，體現(xiàn)產(chǎn)品的溫度與友好
• 風(fēng)格多樣化：視覺(jué)多樣化體現(xiàn)小說(shuō)多樣性、市井特點(diǎn)
• 質(zhì)感：增加視覺(jué)紋理，給用戶帶來(lái)真實(shí)閱讀的感受

Logo

番茄的品牌名稱基于「、優(yōu)質(zhì)」的產(chǎn)品理念，服務(wù)于產(chǎn)品設(shè)計(jì)、品牌設(shè)計(jì)中。番茄相對(duì)于紅果是一個(gè)更加具象的表達(dá)，不僅可提高用戶對(duì)產(chǎn)品的認(rèn)知，也能傳遞小說(shuō)品牌的理念和態(tài)度?；诖?，這個(gè)理念框架是講述品牌故事的關(guān)鍵載體。

logo動(dòng)畫展示

小說(shuō)相關(guān)產(chǎn)品logo匯總

在logo的設(shè)計(jì)上我們將番茄的圖形概念化，保留番茄籽，局部的留白讓標(biāo)志同樣能表達(dá)空間與白的概念。我們選擇在白色底上用紅色非對(duì)稱性式logo ，既區(qū)別了市面上大多產(chǎn)品logo樣式，又能夠加深用戶對(duì)產(chǎn)品的印象，突出了「愉悅」的特性。

選定 logo 并設(shè)計(jì)圖形+文字組合：

在文字設(shè)計(jì)上，相比正常宋體弱化文字襯線，為了突出空間感，我們擴(kuò)大了字面拉伸了中宮的占比，這樣做不僅提高文字識(shí)別度，整體氣質(zhì)也也能夠與沉浸的定義相耦合。

品牌色

前期通過(guò)情緒版的分析，摘取關(guān)鍵詞配色，綜合歸納出符合番茄小說(shuō)特性的的色彩搭配

通過(guò)對(duì)情緒版色彩的歸納，我們抽取具有代表性的顏色，作為番茄小說(shuō)的品牌色

輔助圖形

從logo中番茄圖形的概念出發(fā)，提取出以圓、番茄籽、番茄輪廓為基本型的品牌圖形元素

官方字體

考慮到官方字體在沉浸式頁(yè)面中的運(yùn)用，番茄官方字體的選擇與品牌屬性相契合的蘋方體、宋體。

VI 呈現(xiàn)：

品牌視覺(jué)感受：

品牌體現(xiàn)—產(chǎn)品場(chǎng)景

番茄小說(shuō)給人的感覺(jué)是安靜、平和、友好。因此在顏色使用中以品牌色配合低飽和度背景色做搭配，突出產(chǎn)品的帶給用戶的沉浸、愉悅感。

運(yùn)營(yíng)場(chǎng)景—運(yùn)營(yíng)設(shè)計(jì)對(duì)品牌塑造的意義

第一眼的感受，往往決定了用戶對(duì)產(chǎn)品的整體印象。目前在番茄小說(shuō)的產(chǎn)品中，最直觀的品牌視覺(jué)展示主要以書單活動(dòng)banner為載體，其做為活動(dòng)入口本身就處在一個(gè)前置的位置，占用空間大且更能吸引到用戶的注意。因此，需要對(duì)運(yùn)營(yíng)焦點(diǎn)圖設(shè)計(jì)精細(xì)化的打磨，讓用戶在打開(kāi)產(chǎn)品的瞬間，快速塑造產(chǎn)品在用戶心中的視覺(jué)形象。

番茄小說(shuō)運(yùn)營(yíng)設(shè)計(jì)——和而不同

運(yùn)營(yíng)設(shè)計(jì)的基本原則

• 信息快速傳達(dá)
• 促使用戶行動(dòng)

因此番茄小說(shuō)的運(yùn)營(yíng)視覺(jué)需要緊密圍繞在這個(gè)大前提下進(jìn)行設(shè)計(jì)，快速傳達(dá)信息=保證信息的簡(jiǎn)單化、文字有效性，促使用戶行動(dòng)=畫面內(nèi)容的趣味性、吸引性。

視覺(jué)呈現(xiàn)形式

遵循番茄體系，體現(xiàn)小說(shuō)內(nèi)核的「煙火」氣質(zhì)，視覺(jué)呈現(xiàn)多元化。以運(yùn)營(yíng)文案為中心，畫面設(shè)計(jì)貼近內(nèi)容，降低用戶信息識(shí)別成本。

品牌運(yùn)營(yíng)視覺(jué)一期構(gòu)建：手繪元素+非對(duì)稱構(gòu)圖+質(zhì)感

設(shè)計(jì)規(guī)范

運(yùn)營(yíng)視覺(jué)與品牌調(diào)性應(yīng)是統(tǒng)一的，因此在運(yùn)營(yíng)設(shè)計(jì)的色彩選擇需要與品牌配色相呼應(yīng)，保證視覺(jué)與整個(gè)產(chǎn)品的和諧性。

運(yùn)營(yíng)插圖案例

在運(yùn)營(yíng)活動(dòng)中，依然要以產(chǎn)品所傳遞的氣質(zhì)來(lái)進(jìn)行畫面設(shè)計(jì)，即是保留沉浸的前提下，抽取關(guān)鍵詞的某個(gè)方向來(lái)表達(dá)品牌運(yùn)營(yíng)所傳遞的理念。在色彩的使用上可以圍繞關(guān)鍵詞的方向來(lái)選擇顏色，以表達(dá)內(nèi)容所傳遞的信息，可適當(dāng)使用品牌色作為點(diǎn)綴，但依然需要的保持視覺(jué)給人帶來(lái)的平和感。

總結(jié)

作為一個(gè)從 0 到1的品牌，番茄小說(shuō)的設(shè)計(jì)語(yǔ)言依然在不斷的打磨、優(yōu)化。整體清晰的品牌規(guī)劃能夠保證線上、線下、產(chǎn)品與營(yíng)銷的各個(gè)視覺(jué)設(shè)計(jì)環(huán)節(jié)更加統(tǒng)一，同時(shí)也為后續(xù)的設(shè)計(jì)指明方向，助力業(yè)務(wù)持續(xù)發(fā)展。

文章來(lái)源：優(yōu)設(shè)    作者：今日頭條UED