隨著項目體積的增加，參與到項目中的同學越來越多，每個人都有自己的打 git log 的習慣：

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

為了形成統一的規范，達成共識，從而降低協作開發成本，需要對 git commit 記錄進行規范。

規范 git commit 記錄

規范 git commit 記錄，需要做兩件事情：

• 通過交互式命令行，自動生成符合指定規范的 commit 記錄
• 提交記錄后，在 git hooks 中進行 commit 記錄格式檢查

問：既然已經交互式生成了規范記錄，為什么需要在 hooks 進行檢查？

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

調研：交互式 commit log 規范方案

前期調研結果，關于 commit 提示有兩種做法：

1. 直接使用 commitizen 中常用的 adapter
2. 根據團隊的需要，自定義 adapter

方法 1 的優缺點：

優點 1: 直接安裝對應的 adapter 即可

優點 2: 無開發成本

缺點 1: 無法定制，不一定滿足團隊需要

方法 2 的優缺點：

優點 1: 可定制，滿足開發需求

優點 2: 單獨成庫，發布 tnpm，作為技術建設

缺點 1: 需要單獨一個倉庫（但開發成本不高）

代碼實現

在實際工作中，發現方法 1 中的常用規范，足夠覆蓋團隊日常開發場景。所以，選擇了方法 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" }
}

在項目根目錄下創建commitlint.config.js：

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

使用方法：不再使用git commit -m ...，而是調用npm run commit。

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

醫療行業的交互設計，跟其他行業有何不同？有什么要特別考慮的點？設計師應該注意哪些方面？

X與行業

產品體驗設計通道中有條簡單好記的定義： 1+X。

「X」這個字母常被定義為更多可能性，它的誕生往往是為了更好地服務行業與產品。

例如在醫療健康行業中，不再只有C端用戶，我們要面對醫院管理人--員、患者、醫護人員還有企業用戶等；環境也不單是線上場景，它可能是醫院、企業大樓、社康、疾控中心等等；合作方式同樣獨特，我們做出的任何一個設計都是需要客戶過目的，每一個字段甚至都涉及到生命健康與安全，所以會要求我更高標準地了解行業與用戶，促使我們在項目前期去不斷學習和應用一些用戶研究知識，使設計更加貼近用戶。

交互設計師在用戶研究領域的探索

過往經歷中，總結了用戶研究在各階段的介入場景和方法，接下來會具體講下在醫療健康項目中的運用。

1. 企業健康場景案例

企業健康項目是從一個合作開始的，公司的行政部門想要通過我們提供的健康管理產品來提升員工整體的健康水平，并將該方案進行復制從而提供一個企業健康管理的行業解決方案。

的確，員工是一個企業的寶貴財富，健康有活力的員工群體對提升企業生命力有著非同一般的影響。通過網絡文獻調研，我發現國內企業的亞健康狀況并不樂觀。

△ 國內企業健康現狀

第一階段用研——產品定義與設計方向

為了更了解員工和企業的真實情況和痛點，我們規劃了用研計劃，列出了三個用研目標：

• 了解員工們的主要健康問題
• 了解企業服務存在的問題和改善方向
• 確立產品目標與設計目標

目標1: 員工們的主要健康問題都是什么？

通過和企業方的溝通，我們發現員工的體檢報告是挖掘健康問題的源頭，于是我們由此開始研究。

首先，我們拿到了歷年的公司員工體檢數據統計（脫敏分析），整理出體檢問題的Top10。

△ 騰訊2018年體檢數據統計

獲許可，我們也隨機向外發放問卷，了解到一些公司職工最想要改善的問題。

△ 某大廈的用研報告（僅作為分析用）

目標2：企業現在所提供的服務有哪些問題，該如何改善？

B端: 由于這是一個B to C的項目，我們優先會去采訪企業端遇到的問題，溝通發現企業都會投資提供的健康設施（體檢，食堂，健身房等），其中很多設施并沒有被充分利用，或是沒有得到合理的分配，現有的線上預約流程也存在很大的后臺計算成本。

△ 騰訊提供的健康服務與設施（非疫情期間拍攝）

C端: 通過公司內部招募和訪談了20名員工，我們總結為三個主要痛點：

• 體檢套餐不知怎么選最適合自己，體驗不流暢
• 體檢后看不懂報告也不知道該如何改善
• 知道改善方向卻不知如何落地和規劃，或是沒有堅持下去。

△ 員工在體檢健康中遇到的痛點

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

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

目標3：如何定義產品目標與設計目標？

通過以上分析，和其他合作團隊一同討論了體檢與健康管理行業的現狀和盈利點，我們最終確定了產品方向：通過加入AI技術，分析用戶過往體檢數據來給用戶推薦最合適的體檢套餐，幫助用戶解析體檢報告轉化為更加易懂的方式，加強與醫療服務的定制化連接；并智能定制最適合員工的管理方式和行為，充分利用起公司資源。

△ 產品形象與定義

通過對整體流程的用戶情緒地圖分析，我們得出設計的關鍵詞：專業，貼心，安全

△ 階段情緒地圖分析

知識點1: 訪談與問卷調研

不要一上來就直奔主題，可以先問一些簡單回答的問題和閑聊，讓用戶進入放松狀態時再聊重點問題。且要時刻關注受訪用戶的狀態，比如：是不是開始疲憊，回答過于發散以及表達意思模糊等等。遇到這些問題，需要隨時做調整。

訪談的時候最好不要單獨行動，要有1個主導訪談的，一個記錄的。如果訪問過程很長，有條件以及受訪者允許的情況下，可以進行錄音有助于后期的整理。

訪談結束后，最好是當場，或者至少應該是當天就完成本場次的訪談記錄和總結工作。因為根據遺忘曲線，人在20分鐘后將遺忘42%的內容，而1天后則將遺忘74%。即使有錄音筆記錄，你也會忘掉很多細節的，諸如表情，用戶的潛臺詞等等。想到的設計解決方案也可以先記錄下來但不急于放到總結當中去。

第二階段用研——產品與設計驗證

確立了目標和方向，我開始從體檢預約和檢后管理兩部分來進行設計，由于在前期建立了用研機制，我們會定期對重要版本的內容和信息設計進行測試驗證，并讓用戶基于我們定義的設計標準來打分，判斷是否達到了專業，貼心與安全。

卡片分類-測試內容與排序

在檢后的體檢報告解讀中，我們需要對解讀結果進行結構化展示，方便用戶快速獲取有用信息，提高閱讀效率，由此我們運用了卡片分類法，讓用戶對其重要性的排序，得知對用戶來說體檢異常中的單項的指標解釋>危害性>指導措施。

△ 卡片測試與分析

可用性測試-測試架構與信息形態

體檢解讀的首頁我們繪制了三個版本的方案，來突出不同的信息通過制作原型demo來進行可用性測試，讓用戶選出最喜歡的并說明原因，最終選擇出一個最優方案。

△ 體檢解讀首頁可用性測試與分析

從彈窗內容組合到內容的體檢解讀指標的可視化設計我們都做了用研測試版本

△ 體檢解讀內頁信息測試稿

最終得到更加符合用戶認知的體檢解讀設計。

△ 體檢解讀設計

灰度測試與深度訪談

由于某些需求時間緊迫，例如體檢預約，當時很快就要到體檢季，于是我們快速搭建框架和基礎功能的設計，細節疑問點列出后進行灰度版本測試，并對前期招募的種子用戶進行測試訪談，總結現存版本的問題，同時我們也訪問了企業側，把他們的優化訴求納入考慮。

△ 體檢預約訪談腳本與測試結論

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

△ 隱私授權設計

△ 體檢預約設計

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

知識點2:卡片與可用性測試

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

2. 就醫服務場景案例

就醫流程是看似并不陌生的場景，痛點也非常明顯，就是常被提到的「三長一短」問題（掛號時間長，支付時間長，問診時間短），于是在進行線上就醫服務設計時，很多人會認為沒什么好特別調研的，競品也非常多。

然而其實在設計中，最害怕的就是「我以為」。記得在做某醫院的就醫服務項目時，由于就醫環境和用戶非常復雜，所以我們在做這個項目時堅持去到了前線進行了實地考察與影子觀察法，才發現了新的洞察。

實地考察中的望聞問切

說來很巧，現場的調研方法其實和中醫中的「望聞問切」有異曲同工之妙。

△ 醫療場景用研方法

「望」：可理解為影子觀察法：選擇最能反映問題的時間和場景去觀察用戶行為，發現痛點，經過幾天的觀察我們發現早上8-10點是醫院看病的高峰期，也是排隊最嚴重，院內最擁擠的時期，所以我會在這兩個小時集中觀察和記錄患者以及醫生的狀態。

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

「問」：根據我們想要了解和觀察到用戶的行為進行提問。

「切」：這里和中醫中的切診接觸不同。是指切身去體驗患者的感受，比如我會根據自己身體的某些不舒服去掛號體驗流程，情景帶入。

以上的實地考察后，我在第一時間用我們設計師的手法來記錄整理：體驗地圖分析，并通過討論提煉出設計的關鍵點：引導，連接，合并與轉化。

△ 用戶體驗地圖與關鍵點分析

知識點3:影子觀察法

• 需要選取事件發生的典型場景和時間，即所觀察的場景和用戶是最具有代表性的，才能最反映問題所在。
• 像一個隱形人一樣去觀察，不要主動打擾和詢問用戶，才能最客觀的記錄狀態和行為，避免變形。

用戶體驗地圖的落地應用

這四個設計關鍵點其實來源于痛點描述中的一些高頻提到的情況，拿引導和連接這兩個點來說明。

引導：通過觀察發現，用戶在嘈雜的就醫環境中本處于極度焦慮緊張的狀態，對信息閱讀和處理的速度低于平時的好幾倍，因此我們需要提供具體的，正向的引導。

△ 精準預約設計

連接：通過訪談和自己實際的體驗發現，許多線上和線下的服務之間是斷層的，一方面需要流程上連接我付了款下一步要去哪，怎么拿藥；另一方面我們也發現線下的引導設計是一個非常重要的連接機會點。

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

△ 候診與取藥簽到設計

△ 醫院物料布局與落地布置

通過用戶關系圖了解了每個相關利益人的人群要素和訴求，在設計中不僅會考慮針對他們的設計，也結合體驗地圖中的機會點引出了設計原則，作為設計的指導和驗證標準。

△ 相關利益人分析與設計原則

測試與收獲

上線后，我們穿上志愿者的衣服，去往前線進行現場解說和用戶測試，經過一個月的努力，真實感受到了現場效率的提升和滿意度的提高，院方和使用過的用戶都非常滿意，這也讓我們設計師切實感受到了欣慰和成就感。

△復旦大學附屬腫瘤醫院病理會診 整體服務上線前后對比

這得益于我們能長時間與用戶在一起，真實地聽到了他們的聲音與感受，也把想法落地去幫助他們解決了問題。這個過程中，讓我們發現類似的垂直領域需要去到前線自己去感受，而不是隔著屏幕去觀察，每個人的思考角度會不同，會發現新的問題和洞察。

知識點4:用戶體驗地圖

• 不要為了畫流程而畫，最終還是要通過圖形化的記憶更好的還原記憶細節。
• 重點要放在痛點與機會點的一些突出共性上，提煉是關鍵步驟。
• 不要忽略不同接觸點的洞察，它們均可以作為設計的載體。

3. 醫療數據分析場景案例

在醫療數據分析的場景中，我們面對的客戶是政府和醫院領導。相信在做TO B設計的小伙伴經常會遇到這樣的問題：客戶時間比較難約，給的調研時間有限；決策層客戶思考的比較廣而泛，很難深入用研。

基于這樣的問題，我們想出了一個根據客戶群體層級，區別調研的方法。

梳理角色

去年年初，我們曾走訪多家公立和私立醫院，優先通過管理層梳理出了關于數據處理上報的流程。他們對數據的關注度和處理順序往往是有一個自下而上的上報過程，基層人員進行每個月度和季度的數據匯總，分析與簡單的可視化表現，上報給部門管理和上級管理者進行審核提煉，最終給到管理決策者一些關鍵現象和趨勢和對比。

由此提醒了我們，想要提供一個完整的數據解決方案，就需要繪制角色面板，區別調研目的與手段。

△ 醫院層針對數據的處理流程

分角色的溝通用研

我們確立了針對基層人員，中層管理者以及決策管理者的用研目標并展開了差異化的溝通用研，我們會每個角色找1-2人和我們3-4個同事坐在一起，以焦點小組的方法一同腦暴某一數據場景和所需數據。

• 基層人員 用研目標：了解常用基礎數據的模塊與細節匯總
• 中層管理 用研目標：常關注的關鍵指標模塊與提煉形態（對比，警示，峰值，占比）
• 決策管理者 用研目標：看數據的目的，常關注的關鍵指標與形態的驗證，后續操作

△ 醫院數據現場用研

數據研究與總結應用

根據對醫院不同角色的溝通梳理出了一些總結點，運用到了產品和設計中。

第一：我們發現了管理者們最關注的一些醫院數據的形態，并打算把基礎數據盡量以對比，警示等手段進行分析與場景描述。便于管理者直觀獲取他想要獲取的輔助決策信息。

第二：根據不同角色提供針對性的角色面板，并梳理出個角色關注的數據模塊和現象。

第三：各角色具體數據字段的梳理與總結，并進行了頻率的標注便于后續的設計面板規劃。

第四：調研中發現領導層在看數據時需要來回切換系統，且看起來沒有一個統一的路徑和條理，因此我們也和對方溝通，通過故事化的手法進行數據分析的流程體驗設計，層層深入和下鉆，從現象挖掘到問題本質。更加符合了用戶看數據的順序和認知。

△ 長沙超腦項目設計版圖

除此之外，我們后面的產品和設計的匯報也會根據角色的差異來進行內容的調整，讓聽我們說話的人可以快速理解我們想要達成共識的內容，加快溝通效率，提升了在客戶心里的印象。

這個過程中，通過用研讓用戶感覺到我們懂他們，并讓其增加了參與感，對產品和設計都是一個推進器。

知識點5：TO B/G客戶用研

• 事前理清楚項目中會接觸的各個角色，并進行初步了解，制定不同的用研目標再進行溝通。
• 探討的過程，要給足客戶參與感，例如使用焦點小組的調研方式，提升好印象。

如何持續提升技能——讀書有感

說了那么多設計師在用研技能上的應用，也許有人會有這樣的疑問：如何可以不斷提升自己在各方面學到的技能呢？一年前讀到《刻意練習》這本書，給了我一些啟發，在此總結給大家，希望對你們有幫助：

1. 制定具有定義明確的特定目標

「提升專業」是個很大的詞，所以我們往往定了一個很大的目標，然后被各種事情拖著然后拋之腦后。因此拆分目標才是第一步。比如最開始做交互時我發現自己在歸納場景時總會缺失，再比如每次自己在匯報總結時，耗時過長，缺乏重點，那么這些都可以被列入要提升的小目標，總之目標不要太泛太難實現，這樣實現起來會更加容易，也更容易堅持和自我激勵。

2. 持續學習與專注練習

研讀多本相關專業書籍，并應用的項目中去。這是我的一個目標也是方法。投入項目后，我們往往會陷入事件當中，甚至會就一個點和產品爭論不休。但其實跳出來，去看些新思路不妨為一個好方法。

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

大多時候理論知識很枯燥，也難以一時間就可以用到，但只要你讀過，在需要的時候它就會突然跑出來給你靈感。

專注是我一個單線程人的特點，我很難在一個時間里同時處理多件事，所以我會每天根據要完成的訓練目標，把時間進行劃分，個人感覺這的確產出效率也會高一些。

3. 一定要有反饋

每一次的練習必須要得到反饋，這也是評審的重要性。但其實不同的目標點可以對應方面的專家，不僅限于leader了，同事也是很好的老師，比如我會去發現身邊匯報比較厲害的同事，幫我把關。只要遇到問題，一定不會放過去問用戶研究同學的機會。

某方面沒有老師怎么辦？讓用戶告訴你！首先我會常用可用性測試的方式去檢測自己的方案中的信息傳達，交互反饋等等在進步，另外我也會在每個項目后整理一個小總結，來記錄自己的思考與進步

另外，以下是我在用戶研究學習中讀過的幾本書，推薦給大家～

結語

面對飛速發展的現在，各行業的產品也都在積極轉型，例如開始涉足TO B行業和客戶，開始研究00后的新生代用戶，面對新事物我們設計師更要保持敏銳的眼光，利用自身的設計洞察能力去挖掘新的問題與方法，于是新的技能和方式也開始出現，所以我們一直認為產品體驗設計師沒有一個固定的能力模型，還是要根據你所從事的行業和產品來發現所需的技能點去發揮價值。學習的過程中，我們成就項目的同時也在慢慢成就自己。

文章來源：優設    作者：騰訊 April

最近身邊的一些小伙伴，總會遇見B端設計工作，對于這種偏后臺設計的B端設計，總會有大量的表單設計需要做，結合以前自己也有過不少表單設計的工作，在這里給大家分享一下自己對于PC端表單設計的研究，聊一聊表單在PC端中的運用。

表單的作用

商業離不開數據，而數據總會依賴不同的表現形式，不管是word文檔，還是數據可視化，都是瀏覽者通過表現形式來對數據進行閱讀和分析，因此表單的設計就是一種表現形式，我們將捋一捋如何通過表單更好的讓用戶閱讀順暢、操作方便、總而言之就是更好用啦。

表單信息的分割方式

無線分割：顧名思義，列表的信息之間正常情況下沒有分割線等方法來分隔，僅僅是用間距來分隔開內容。好處是元素更少，畫面更簡潔，但是視覺可能就沒那么清晰了，使用的出場率一般。

有線分割：同樣字面意思，就是通過簡單的分割線來分割列表中的信息，讓視線左右移動的時候更加穩定、輕松，在表單設計中使用的出場率非常高。

斑馬線：通過深淺交替的色塊，以及色塊產生的對比來分隔列表中的信息，深淺深淺的循環就好像斑馬線，使用時是通過色塊產生對比，所以也可以使用帶有適量飽和度的色塊來區分，占頁面面積比例較大，適當用色可以使得畫面更加活潑、豐滿，斑馬線也是出場率極高的一種展現形式。

斑馬線+分割線：很容易理解，就是斑馬線風格+分割線的結合，用色塊區分的同時又加了分割線，信息之間的區分對比更加強烈，但是畫面層級就多了一些，沒有其他的看起來簡潔，使用出場率也一般。

卡片式：跟卡片式風格其他設計一樣，分別用懸浮的色塊來區分，間隔的地方是背景色，分隔的力度比較強，內容區分的很清晰，弊端是更加占畫面的位置，尤其在信息很多列的時候，會增加大量的高度，用戶需要更多時間進行下翻的操作。使用出場率相對其他形式來說稍低。

可控制頁面顯示數量

場景：用戶需要閱讀大量的表單數據，且需要頻繁的翻頁、跳轉。

如圖，左下角可以設置界面中每頁顯示信息數量的多少，用戶可以根據自己的需要自由設置，當瀏覽的數據較多的時候，不再需要頻繁點擊下一頁來瀏覽信息，只需把每頁顯示的數量調高，如此便減少了大量的操作次數。

像這樣允許用戶可以自由編輯來改進體驗的方式還有很多，比如可以設置顯示密度，就是以一樣的方式自由調整信息與分割線的間距。除了行間距，有的可以自由設置每一列的列間距，用戶可以根據自己的習慣來設置。

列表+可視化

場景：用戶需要瀏覽大量的數據，并需要對數據反復進行計算、分析。

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

根據條件排序

場景：用戶想根據某種條件的大小排序，來先后閱讀數據。

通過點擊第一排小標題行，可以選擇不同的方式調整信息的排序方式，就和電商商品排序一樣，可以選擇金額高到低或者低到高排序，也可以選擇別的方式進行排序，從而更快找到自己所需要的內容。

篩選過濾

場景：從一大堆混雜的數據當中，尋找符合條件的自己所需要的數據。

添加篩選功能，過濾掉自己不想瀏覽的內容，通過條件篩選，更快的更的找到自己想要的內容、縮小查找范圍、減少達到目的所花的時間。一般通過下拉按鈕的形式選擇不同的條件來進行篩選過濾。

關鍵字搜索

場景：已知列表中某信息的名稱關鍵字，想從大量混雜的列表中快速找到。

跟篩選過濾一樣，添加關鍵字搜索功能，用戶提供部分關鍵字，可通過關鍵字查詢，最快最的找到想要的那一條內容。一般該目標內容是用戶已知的，有時候是針對性的。

懸停展現操作

場景：精簡設計風格的界面，不想界面中內容過于繁多。

如圖，鼠標懸停在哪一行，哪一行才會顯示該列表后面的操作按鈕，好處是減少了視覺干擾，能更快的找到捕捉到操作位置，弊端是用戶不進行交互的時候無法發現操作按鈕如何出現。

可展開列表

場景：想快速獲取列表中某信息的其他附屬內容。

如圖，點擊某一行后，展現該行的一些附屬信息?？梢圆挥锰D頁面而進一步了解該行信息的詳情。

可編輯列表

場景：在瀏覽列表的同時，需要頻繁的對列表中的信息進行編輯。

用戶可以直接對列表信息進行修改、編輯，省去了跳轉再編輯的麻煩步驟，更節約時間，用戶操作起來更加方便。

快速預覽

場景：需要充分了解列表中不同信息的詳細說明，頻繁跳轉又過于麻煩。

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

（PS：彈出對話窗口的方式，可以同時彈出好幾項列表的詳情信息進行對比，但是側彈框因為高度優勢，可以展現更多內容）

自定義列

場景：列表中每條內容顯示信息參數過多，且很多不想瀏覽。

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

固定頭部

場景：列表橫向或者縱向過多，下翻或橫拉的時候標題頭被隱藏，不知道自己當前瀏覽到的參數屬于哪一項。

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

間距的規則

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

總結

其實上面的每一條都是一個小總結，每一條在大部分的列表中都可以用到，主要還是根據實際需求來運用這幾點，比如分割的方式根據主體風格來搭配，不要為了設計而設計盲目運用，畢竟設計都是以內容為主，尤其是表單設計，本身就是更好的表達內容。

本文發布于人人都是產品經理。

轉自：站酷-

微信小程序的wxss、阿里旗下淘寶、支付寶小程序的acss等等語法很類似原生css，但是在web開發里用慣了動態css語言，再寫回原生css很不習慣，尤其是父子樣式的嵌套寫法非常繁瑣。

因此，我希望能有一個自動化構建方案，能夠簡單地將scss轉換成小程序的樣式語言。

方案1

以前寫微信小程序的依賴庫時用過，使用gulp編譯，將源碼和編譯后的代碼分別放到src和dist兩個目錄。gulp會處理src下面的所有文件，將其中的scss轉換成css，并將其他所有文件原封不動挪到dist下相應位置。

這里就不詳細說了，代碼參考Wux。

方案2

非常簡單直接，使用Webstorm/IDEA的File Watchers功能實時轉換。

安裝Ruby和sass

確保命令行輸入sass -v能出現版本號，安裝過程略。

安裝File Watchers

到插件市場上搜索并安裝（已安裝則跳過）

添加scss的轉換腳本

現在安裝完插件打開項目會自動彈出scss轉css的向導，方便了很多。但還需要做一些修改，配置如下：

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

其次，將Arguments改為:

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

如果不加--no-cache，scss文件同目錄下會出現一個.sass-cache目錄。

如果不加--sourcemap=none, scss文件同目錄下會出現一個.map文件。

如果不加--default-encoding utf-8, scss文件如果有中文注釋轉換就會報錯。

style可不加，這里用的是無縮進和壓縮的風格，反正小程序打包發布時還會壓，這里保持可讀性。

現在這個scss轉換是單獨作用于項目的，如果新建一個小程序項目，就需要重新添加（不建議設置成global，容易誤傷）。

注意到File Watchers列表的右側操作欄下方有導入導出按鈕，可以將現在配好的設置導出保存，將來新建項目時只要導入一下就行了。

之后還有一個問題，如果我手動將編譯后的css（即wxss或者acss，下略）文件刪除，scss文件不改動的話，就不會重新編譯出css文件。
或者萬一監聽失效或者不夠及時，css還有可能是舊的。
所以還需要一個命令，用來將整個目錄下的scss文件統一轉換，確保沒有遺漏和保持代碼。

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

所以遍歷這個行為只能交給nodejs來實現，代碼如下：

創建編譯腳本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規則，下劃線開頭的文件不會生成css } // exec可以讓nodejs執行外部命令 exec(`sass --no-cache --sourcemap=none --default-encoding utf-8 --style expanded ${file}:${newFileWithoutExt}.acss`, { cwd: path.dirname(file) // 不寫這個會導致生成的文件出現在根目錄 }, (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 允許按照一定模式，從數組和對象中提取值，對變量進行賦值，這被稱為解構（Destructuring）



本質上，這種寫法屬于“模式匹配”，只要等號兩邊的模式相同，左邊的變量就會被賦予對應的值

如果解構不成功，變量的值就等于undefined

解構賦值的規則是，只要等號右邊的值不是對象或數組，就先將其轉為對象。由于undefined和null無法轉為對象，所以對它們進行解構賦值，都會報錯、

解構賦值的用途：

交換變量的值

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



從函數返回多個值

函數只能返回一個值，如果要返回多個值，只能將它們放在數組或對象里返回。有了解構賦值，取出這些值就非常方便



函數參數的定義

解構賦值可以方便地將一組參數與變量名對應起來



提取 JSON 數據，很多接口數據只需要其中某部分

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



函數參數的默認值

指定參數的默認值，就避免了在函數體內部再寫var foo = config.foo || ‘default foo’;這樣的語句



遍歷 Map 結構

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



輸入模塊的指定方法

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

1、數組的解構賦值

左右兩側數據解構須得吻合,或者等號左邊的模式，只匹配一部分的等號右邊的數組（屬于不完全解構）



特殊情況使用…擴展運算符，無值是空數組



左右兩邊等式的性質要相同，等號的右邊不是數組（或者嚴格地說，不是可遍歷的結構），那么將會報錯，只要某種數據結構具有 Iterator



接口，都可以采用數組形式的解構賦值，例如Set結構



解構賦值允許指定默認值，當一個數組成員嚴格等于undefined，默認值才會生效,否則取賦值的值；如果默認值是一個表達式，那么這個表達式是惰性求值的，即只有在用到的時候，才會求值；默認值可以引用解構賦值的其他變量，但該變量必須已經聲明

// 數組的解構賦值
 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 []
 // 等號右邊不是數組會報錯
 // let [ab] = 121;
 // conosle.log(ab)//TypeError: 121 is not iterable
 // let [abc] = {}
 // conosle.log(abc)//TypeError: {} is not iterable
 // 默認值賦值
 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,因為ww申明比qq晚所以是undefined；

2、對象的解構賦值
對象的解構賦值的內部機制，是先找到同名屬性，然后再賦給對應的變量。真正被賦值的是后者，而不是前者

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

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

由于數組本質是特殊的對象，因此可以對數組進行對象屬性的解構

objFuc(){
            // 對象解構賦值
            let {b,a} = {a:1}
            console.log(a,b)//1 undefined
            // 已有對象解構賦值
            let { sin, cos } = Math;//將Math對象的對數、正弦、余弦三個方法，賦值到對應的變量上
            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"
            // 默認值
            // 錯誤的寫法
            let xx;
            // {xx} = {xx: 1};// SyntaxError: syntax error,Uncaught SyntaxError: Unexpected token '='
            ({xx} = {xx: 1});//正確寫法
            console.log(xx)
            // 古怪的，等式左邊可為空
            // ({} = [true, false]);
            // 對象可解構數組
            let arr = [1, 2, 3];
            let {0 : first, [arr.length - 1] : last} = arr;
            console.log(first,last)//1 3
        },

3、字符串的解構賦值

• 字符串賦值
• 類似數組的對象都有一個length屬性，因此還可以對這個屬性解構賦值

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
            // 對數組屬性解構賦值
            let {length} = this.str;
            console.log(length)//7
        },

    

        4、數值和布爾值的解構賦值
    

    


        

            解構賦值時，如果等號右邊是數值和布爾值，則會先轉為對象
        

        

            解構賦值的規則是，只要等號右邊的值不是對象或數組，就先將其轉為對象。由于undefined和null無法轉為對象，所以對它們進行解構賦值，都會報錯
        

    

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] }
// 右側必須是數組或對象，undefined和null無法轉為對象，所以對它們進行解構賦值，都會報錯
// let { prop: x } = undefined; // TypeError
// let { prop: y } = null; // TypeError

    

        5、函數參數的解構賦值
    

    


        

            也可使用默認值，注意默認值是指實參的默認值而不是形參的默認值
        

    

// 函數的解構賦值可使用默認值，注意默認值是指實參的默認值而不是形參的默認值
            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、圓括號問題
解構賦值雖然很方便，但是解析起來并不容易。對于編譯器來說，一個式子到底是模式，還是表達式，沒有辦法從一開始就知道，必須解析到（或解析不到）等號才能知道。
由此帶來的問題是，如果模式中出現圓括號怎么處理。ES6 的規則是，只要有可能導致解構的歧義，就不得使用圓括號。
可以使用圓括號的情況只有一種：賦值語句的非模式部分，可以使用圓括號
總結：
不管是哪一類的解構賦值，等式右邊的數據必須是對象形式（數組也是一種對象形式）
————————————————
版權聲明：本文為CSDN博主「Yan_an_n」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/weixin_44258964/article/details/105643553

目錄

HTTP協議

HTTP請求：

HTTP響應：

會話與會話狀態：

Cookie

Session

Cookie和Session的區別

HTTP協議


 HTTP請求：
Post /test.php HTTP/1.1                               //請求行以一個方法符號開頭，以空格分開，后面跟著請求的URI和協議的版本

Host: www.test.com                                       //請求頭

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

Gecko/20100101 firefox15.0

                                                                                    //空白行，代表請求頭結束

Username=admin&passwd=admin                             //請求正文

HTTP請求方法



GET       請求獲取Request-URI所標識的資源

POST     在Request-URI所標識的資源后附加新的數據

HEAD    請求獲取由Request-URI所標識的資源的響應消息報頭

PUT       請求服務器存儲一個資源，并用Request-URI作為其標識

常用的為GET和POST；GET和POST的區別：

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

POST不會將內容顯示在URL中，可以用于提交一些敏感數據，例如用戶名或密碼。

HTTP響應：
HTTP/1.1 200 OK                                         //響應行由協議版本號，響應狀態碼和文本描述組成

Data：sun，15 nov 2018 11:02:04  GMT    //響應頭

Server：bfe/1.0.8.9

……

Connection: keep-alive

                                                                      //空白行，代表響應頭結束

<html>

</html><title>index.heml</title>                  //響應正文

HTTP的狀態碼：

狀態代碼由三位數字組成，第一個數字定義了響應的類別，且有五種可能取值。

1xx：指示信息 —— 表示請求已接收，繼續處理。

2xx：成功 —— 表示請求已被成功接收、理解、接受。

3xx：重定向 —— 要完成請求必須進行更進一步的操作。

4xx：客戶端錯誤 —— 請求有語法錯誤或請求無法實現。

5xx：服務器端錯誤 —— 服務器未能實現合法的請求。

常見狀態代碼、狀態描述的說明如下。

200 OK：客戶端請求成功。

400 Bad Request：客戶端請求有語法錯誤，不能被服務器所理解。

401 Unauthorized：請求未經授權，這個狀態代碼必須和 WWW-Authenticate 報頭域一起使用。

403 Forbidden：服務器收到請求，但是拒絕提供服務。

404 Not Found：請求資源不存在，舉個例子：輸入了錯誤的URL。

500 Internal Server Error：服務器發生不可預期的錯誤。

503 Server Unavailable：服務器當前不能處理客戶端的請求，一段時間后可能恢復正常。

會話與會話狀態：
       Web中的會話是指一個客戶端瀏覽器與web服務器之間連續發生一系列請求和響應過程。會話狀態是指在會話過程中產生的狀態信息；借助會話狀態，web服務器能夠把屬于同一會話中的一系列的請求和響應關聯起來。

Cookie
概述

       Cookie是一種在客戶端保持HTTP狀態信息的技術，它好比商場發放的優惠卡。在瀏覽器訪問Web服務器的某個資源時，由Web服務器在在HTTP響應頭中附帶傳送給瀏覽器一片數據，web服務器傳送給各個客戶端瀏覽器的數據是可以各不相同的。

       一旦Web瀏覽器保存了某個Cookie，那么它在以后每次訪問該Web服務器是都應在HTTP請求頭中將這個Cookie回傳個Web服務器。Web服務器通過在HTTP響應消息中增加Set-Cookie響應頭字段將CooKie信息發送給瀏覽器，瀏覽器則通過在HTTP請求消息中增加Cookie請求頭字段將Cookie回傳給Web服務器。

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

傳送示意圖



特點

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

Set-Cookie2響應頭字段

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

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

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

Cookie請求頭字段

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

       瀏覽器使用Cookie請求頭字段將Cookie信息會送給Web服務器；多個Cookie信息通過一個Cookie請求頭字段會送給Web服務器。

瀏覽器會根據下面幾個規則決定是否發送某個Cookie信息：

       1、請求主機名是否與某個存儲的Cookie的Domain屬性匹配

       2、請求的端口號是否在該Cookie的Port屬性列表中

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

       4、該Cookie的有效期是否已過

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

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

Cookie的安全屬性

secure屬性

當設置為true時，表示創建的Cookie會被以安全的形式向服務器傳輸，也就是只能在HTTPS連接中被瀏覽器傳遞到服務器端進行會話驗證，如果是HTTP連接則不會傳遞該信息，所以不會被竊取到Cookie的具體內容。

 HttpOnly屬性

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

總結：secure屬性 是防止信息在傳遞的過程中被監聽捕獲后信息泄漏，HttpOnly屬性的目的是防止程序獲取cookie后進行攻擊這兩個屬性并不能解決cookie在本機出現的信息泄漏的問題(FireFox的插件FireBug能直接看到cookie的相關信息)。

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

概述

Session技術是一種將會話狀態保存在服務器端的技術，它可以比喻成是醫院發放給病人的病歷卡和醫院為每個病人保留的病歷檔案的結合方式?？蛻舳诵枰邮铡⒂洃浐突厮蚐ession的會話標識號，Session可以且通常是借助Cookie來傳遞會話標識號。



Session的跟蹤機制

HttpSession對象是保持會話狀態信息的存儲結構，一個客戶端在WEB服務器端對應一個各自的HttpSession對象。WEB服務器并不會在客戶端開始訪問它時就創建HttpSession對象，只有客戶端訪問某個能與客戶端開啟會話的服務端程序時，WEB應用程序才會創建一個與該客戶端對應的HttpSession對象。WEB服務器為HttpSession對象分配一個獨一無的會話標識號， 然后在響應消息中將這個會話標識號傳遞給客戶端。客戶端需要記住會話標識號，并在后續的每次訪問請求中都把這個會話標識號傳送給WEB服務器，WEB服務器端程序依據回傳的會話標識號就知道這次請求是哪個客戶端發出的，從而選擇與之對應的HttpSession對象。

WEB應用程序創建了與某個客戶端對應的HttpSession對象后，只要沒有超出一個限定的空閑時間段，HttpSession對象就駐留在WEB服務器內存之中，該客戶端此后訪問任意的Servlet程序時，它們都使用與客戶端對應的那個已存在的HttpSession對象。

Session是實現網上商城的購物車的最佳方案，存儲在某個客戶Session中的一個集合對象就可充當該客戶的一個購物車。

超時管理

WEB服務器無法判斷當前的客戶端瀏覽器是否還會繼續訪問，也無法檢測客戶端瀏覽器是否關閉，所以，即使客戶已經離開或關閉了瀏覽器，WEB服務器還要保留與之對應的HttpSession對象。隨著時間的推移而不斷增加新的訪問客戶端，WEB服務器內存中將會因此積累起大量的不再被使用的HttpSession對象，并將最終導致服務器內存耗盡。WEB服務器采用“超時限制”的辦法來判斷客戶端是否還在繼續訪問如果某個客戶端在一定的時間之 內沒有發出后續請求，WEB服務器則認為客戶端已經停止了活動，結束與該客戶端的會話并將與之對應的HttpSession對象變成垃圾。

如果客戶端瀏覽器超時后再次發出訪問請求，Web服務器則認為這是一個新的會話開始，將為之創建新的Httpsession對象和分配新的會話標識號。

利用Cookie實現Session的跟蹤

如果WEB服務器處理某個訪問請求時創建了新的HttpSession對象，它將把會話標識號作為一個Cookie項加入到響應消息中，通常情況下，瀏覽器在隨后發出的訪問請求中又將會話標識號以Cookie的形式回傳給WEB服務器。WEB服務器端程序依據回傳的會話標識號就知道以前已經為該客戶端創建了HttpSession對象，不必再為該客戶端創建新的HttpSession對象，而是直接使用與該會話標識號匹配的HttpSession對象，通過這種方式就實現了對同一個客戶端的會話狀態的跟蹤。

利用URL重寫實現Session跟蹤

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

Cookie和Session的區別
session和cookies同樣都是針對單獨用戶的變量(或者說是對象好像更合適點)，不同的用戶在訪問網站的時候都會擁有各自的session或者cookies,不同用戶之間互不干擾。

他們的不同點是:

1,存儲位置不同

session在服務器端存儲，比較安全，但是如果session較多則會影響性能

cookies在客戶端存儲，存在較大的安全隱患

2，生命周期不同

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

cookies默認情況下也隨著瀏覽器進程結束而結束，但如果手動指定時間，則不受瀏覽器進程結束的影響。

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

js中cookie的使用（設置和獲取cookie緩存）
生為一個已經入職一年多的前端小白，第一次寫博客還有點小激動，有不足的地方還希望大家多多指出，因為最近項目有涉及到利用cookie緩存數據，所以在這邊再鞏固一下。

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

2、cookie的使用
設置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
調用該方法如：

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

參數 含義
c_name 自己定義的cookie名稱
value 需要放在定義的c_name 中的值
expiredays cookie的有效期
這里有一個要注意點就是 " path=/"
" path=/"是只存下的cookie再該項目所有頁面都能去獲取，如果你想只存到弄個特定目錄可以在path中指定路徑，如：“path=/views/myHomePage”,z這樣你可以在/views/myHomePage文件下所有頁面都能取到你存的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
調用該方法如：

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

痛點

目前眾多的網文產品中，設計同質化比較高，無論是產品視覺或是品牌運營視覺大多都缺乏獨創性與統一性。番茄小說想要從眾多產品中脫穎而出就需要走出一條合而不同的設計道路。因此提升產品的識別度與消費者對品牌的認知勢在必行，設計需探索構建一套屬于產品的語言體系。

解決方法

探索番茄小說的設計語言，建立產品認知

1. 文學特性——傳統、網絡的冷與熱

傳統文學

文學分為兩類，嚴肅文學（看重語言和細節）、通俗文學（注重情節和故事，淺顯易懂）。

周憲《文學理論導引》里定義「文學是以精致語言書寫的具有藝術價值的以文本為中心的文化系統?！雇ㄟ^定義可以概括出文學的特點就是具有藝術價值，并且能夠通過文字內容帶人用戶反思或者收獲。當人們在閱讀文學書籍時是冷靜的，只有在這樣的心境下讀者才能更好的獨立思考與分析。因此在氛圍上需要給用戶提供一個相對沉浸的空間、安逸的環境，通過分析可以提煉出的傳統文學情緒關鍵詞：沉浸、冷靜、舒適、價值

網絡文學

不同于傳統文學，網絡文學是順應市場價值而誕生，是文學創作的平民化，讓大家能夠以網絡為載體而發表的文字內容。廣義來說，網絡文學屬于通俗文學的一類，注重情節和故事，通過文字傳遞的內容更加的樸實、接地氣，在創作分類上也更加的多樣化，作者可以天馬行空的表達自己感受，可以說是在傳統文學的基礎上，給文字增加了幾分煙火氣息，也多了幾分熱鬧的感受。

因此通過文學關鍵詞可擴展出網絡文學情緒關鍵詞：沉浸、愉悅、煙火氣

2. 調研分析

前期通過對小說用戶群體與市場的走訪調研，并通過數據分析，我們得到了如下結論：

產品用戶類型

12-50歲青中年人；后GenX時代；一二三線城市有閱讀小說習慣的人群；目前為對生活充滿向往的學生與藍領

產品品牌人格

樂觀愉悅（輕松）；品質（書好）；親民、豐富（書多）

產品視覺風格

品牌色貫穿產品，但不過分使用；視覺為產品功能服務，不做多余的設計；視覺表現多樣化，但需要表達相同的產品氣質；適度的留白，增強設計空間感

3. 小說產品特性

產品核心詞：「沉浸中的愉悅」

正如我們對文學的分析，小說閱讀同樣是一種獨立個體的行為方式，在讀書時，我們不希望被人打擾，不希望被瑣事細節阻斷，我們希望在一個相對安靜、舒適的環境下閱讀，這是一種沉浸式的感受。

因此這里我們就根據用戶的想要的感受，引入「沉浸」的概念——希望能夠給讀者留下一定的空間，并拋除繁雜打擾，讓大家享受閱讀與獨立思考。其核心是圍繞信息內容本身而呈現，設計不再作為獨立于內容之外的元素存在，而將著眼于內容本身，為用戶打造直觀的視覺體驗。拉大層級對比，增加適當的留白，在一定程度上增加少許修飾，打破絕對的冷淡。其既能體現出文學的特點，又能夠在簡約的基礎上增加畫面的構成感，給用戶愉悅的感受。

觸感

網絡小說與傳統文學另外一個最大的區別是觸感。

傳統文學大多以實體書籍紙張為承載，而網絡文學來自于互聯網是虛擬的。我們在閱讀時，觸摸紙張與書本樸實的質感，也能夠給讀者帶來額外的舒適感受，因此如果能以視覺的形式還原用戶對書籍的「觸感」，不僅能夠將網絡與實體相鏈接，也可以幫助用戶增加電子閱讀的樂趣。

4. 建立番茄小說情緒版

根據歸納出的文學特征，以及調研用戶年齡層與喜好，我們可以歸納出番茄小說基礎原生關鍵詞。

基礎原生關鍵詞

拓展衍生關鍵詞

根據網絡文學原生關鍵詞，我們拓展出衍生詞

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

圖片搜索、提取情緒版

根據相關的衍生關鍵詞，我們收集大量的視覺圖片并將其匯總，借以分析其視覺特征

色彩提取

視覺映射

通過對情緒版的分析，我們可以得出結論并整理出番茄小說設計語言，輕量的色彩、寫意式元素、非對稱布局、紙紋理噪點

番茄小說設計語言

將傳統的冷靜沉浸與網絡文學的熱鬧向融合是番茄小說設計語言的重要視覺呈現方式風格

多元化的簡約設計+情感化修飾

• 簡潔：簡約，做不飽和的設計，給用戶空間感、想象的余地
• 趣味：暖色+趣味，體現產品的溫度與友好
• 風格多樣化：視覺多樣化體現小說多樣性、市井特點
• 質感：增加視覺紋理，給用戶帶來真實閱讀的感受

Logo

番茄的品牌名稱基于「、優質」的產品理念，服務于產品設計、品牌設計中。番茄相對于紅果是一個更加具象的表達，不僅可提高用戶對產品的認知，也能傳遞小說品牌的理念和態度。基于此，這個理念框架是講述品牌故事的關鍵載體。

logo動畫展示

小說相關產品logo匯總

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

選定 logo 并設計圖形+文字組合：

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

品牌色

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

通過對情緒版色彩的歸納，我們抽取具有代表性的顏色，作為番茄小說的品牌色

輔助圖形

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

官方字體

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

VI 呈現：

品牌視覺感受：

品牌體現—產品場景

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

運營場景—運營設計對品牌塑造的意義

第一眼的感受，往往決定了用戶對產品的整體印象。目前在番茄小說的產品中，最直觀的品牌視覺展示主要以書單活動banner為載體，其做為活動入口本身就處在一個前置的位置，占用空間大且更能吸引到用戶的注意。因此，需要對運營焦點圖設計精細化的打磨，讓用戶在打開產品的瞬間，快速塑造產品在用戶心中的視覺形象。

番茄小說運營設計——和而不同

運營設計的基本原則

• 信息快速傳達
• 促使用戶行動

因此番茄小說的運營視覺需要緊密圍繞在這個大前提下進行設計，快速傳達信息=保證信息的簡單化、文字有效性，促使用戶行動=畫面內容的趣味性、吸引性。

視覺呈現形式

遵循番茄體系，體現小說內核的「煙火」氣質，視覺呈現多元化。以運營文案為中心，畫面設計貼近內容，降低用戶信息識別成本。

品牌運營視覺一期構建：手繪元素+非對稱構圖+質感

設計規范

運營視覺與品牌調性應是統一的，因此在運營設計的色彩選擇需要與品牌配色相呼應，保證視覺與整個產品的和諧性。

運營插圖案例

在運營活動中，依然要以產品所傳遞的氣質來進行畫面設計，即是保留沉浸的前提下，抽取關鍵詞的某個方向來表達品牌運營所傳遞的理念。在色彩的使用上可以圍繞關鍵詞的方向來選擇顏色，以表達內容所傳遞的信息，可適當使用品牌色作為點綴，但依然需要的保持視覺給人帶來的平和感。

總結

作為一個從 0 到1的品牌，番茄小說的設計語言依然在不斷的打磨、優化。整體清晰的品牌規劃能夠保證線上、線下、產品與營銷的各個視覺設計環節更加統一，同時也為后續的設計指明方向，助力業務持續發展。

文章來源：優設    作者：今日頭條UED