最近碰到個需要自動生成表格的任務，作為前端的我，就想在 node 和瀏覽器中生成強大的表格，所以特此研究了很多關于表格的 npm 庫
支持讀寫 Excel 的 node.js 模塊
node-xlsx: 基于 Node.js 解析 excel 文件數據及生成 excel 文件，僅支持 xlsx 格式文件
js-xlsx: 目前 Github 上 star 數量最多的處理 Excel 的庫，支持解析多種格式表格 XLSX / XLSM / XLSB / XLS / CSV，解析采用純 js 實現，寫入需要依賴 nodejs 或者 FileSaver.js 實現生成寫入 Excel，可以生成子表 Excel，功能強大，但上手難度稍大。不提供基礎設置 Excel 表格 api 例單元格寬度，文檔有些亂，不適合快速上手；普通版本不支持定義字體、顏色、背景色等，有這個功能需要的可以使用 pro 版，是要聯系客服收費的，害我照著 API 設置調試了好多次都失敗。好在樣式設置問題有一些教程，通過研究本人已解決，可設置寬度顏色等等，見根目錄本人修改的 xlsx.js
xlsx-style 基于 xlsx 封裝的樣式庫，可以在 xlsx 的基礎上設置樣式。樣式不全，寬度都設置不了，好多年前作者就不維護了.寬度設置問題本人已解決了，見修改的 xlsx-style.js 文件
exceljs 在使用此庫之前，本人已花費了很大的精力，用以上庫做好了表格，但是發現不能設置頁眉頁腳，添加圖片，打印選項設置等等，直到發現了這個庫，文檔齊全，功能強大，并且還免費.但是star較少，差一點就錯過了。本教程主要針對這個庫
代碼庫地址
https://github.com/lingxiaoyi/excel
安裝
npm install
npm install -g nodemon
調試使用，替代 node 命令，實現保存文件，node 自動重新啟動執行，必須全局安裝才能運行
使用
nodemon app.js
js-xlsx 具體 api 使用方法請參考 main.js demo 使用，app.js 中修改為 require('./src/main.js');
exceljs 具體 api 使用方法請參考 main-exceljs.js demo 使用，app.js 中修改為 require('./src/main-exceljs.js');
因為每次生成完表格，每次都需要打開表格查看樣式，在 windows 電腦中，打開表格之后就鎖定不能生成新文件了，本來想著能導出一個 html 文件對應表格的樣式
node 調試
vscode 中打開調試右側設置編輯，將下方代碼復制進去，點 nodemon 啟動就可以進行 debug 調試了
{
"type": "node"，
"request": "launch"，
"name": "nodemon"，
"runtimeExecutable": "nodemon"，
"program": "${workspaceFolder}/app.js"，
"restart": true，
"console": "integratedTerminal"，
"internalConsoleOptions": "neverOpen"，
"skipFiles": ["<node_internals>/**"]
}，
webpack 目錄的作用
每次生成完新表格，都需要重新打開表格查看樣式，在 windows 電腦中，打開表格之后就鎖定了，再次生成新表格就會報錯，文件已鎖定，不能寫入，對于想偷懶的我，能不能實現像 webpack 熱更新功能那種，修改樣式 js 頁面自動更新呢?
wps 自帶另存 html 文件功能，但是沒有提供生成的 api ，網上也搜索不到對應的轉換功能，
本來以為自己要實現一套表格轉 html 的功能。通過不斷嘗試，偶然間發現手機瀏覽器可以直接打開預覽 xlsx 文件，內心狂喜啊
使用方法
進入 webpack 目錄安裝依賴包，安裝好之后執行
npm run dev
啟動成功之后，會自動打開帶有 ip 地址的預覽地址，此時在電腦瀏覽器會自動下載 xlsx 文件，忽略不管，用手機直接打開此地址，就能看到 xlsx 表格的內容了，并且每次新修改內容和樣式，都會自動刷新頁面顯示新表格.
小技巧
谷歌瀏覽器插件:
生成二維碼的插件生成二維碼方便手機掃描
劃詞翻譯 用來翻譯一些看不懂的英文文檔
browser 目錄
瀏覽器中實現生成 xlsx 表格方法
進入 browser 目錄安裝依賴包，安裝好之后執行
npm run dev
啟動成功之后，拖動根目錄 src 下的李四表格到頁面上的輸入框里，成功生成表格之后會生成一個下載鏈接地址，右鍵在新標簽頁打開鏈接，即會生成一個新的表格文件出來，完整 api 使用和 demo 文件請參考 index.js
vue 和 react 用法可以參考此例子，如果有必要也可以此版本庫的例子
一些概念
在使用這個庫之前，先介紹庫中的一些概念。
workbook 對象，指的是整份 Excel 文檔。我們在使用 js-xlsx 讀取 Excel 文檔之后就會獲得 workbook 對象。
worksheet 對象，指的是 Excel 文檔中的表。我們知道一份 Excel 文檔中可以包含很多張表，而每張表對應的就是 worksheet 對象。
cell 對象，指的就是 worksheet 中的單元格，一個單元格就是一個 cell 對象。
xlsx 使用注意事項
constXLSX = require('xlsx');
let html = XLSX.utils.sheet_to_html(workbook.Sheets.Sheet1)
生成 html 的用法，并且不會有任何樣式
exceljs 使用注意
讀取文件問題
因為 exceljs 讀取文件不支持 sync 同步讀取，給的實例也是 await 例子.導致我讀取完遇到一個問題，就是老是生成不成功，最后發現必須要把所有邏輯全部放入函數中，像下方這樣
(async function (params) {
let res = await workbook.xlsx.readFile(`${__dirname}/趙六.xlsx`);
//執行所有數據處理邏輯
//執行寫的邏輯
workbook.xlsx.writeFile(path.resolve(__dirname， '../webpack/test222.xlsx'));
});
所有邏輯全部要寫入這個函數中，這樣本來是可以的，但是出錯調試幾率較大，并且讀取到的數據龐大還需要額外處理，所以我讀取數據邏輯就用的 node-xlsx，十分簡單方便，如果你用的 exceljs 讀取文件數據出現問題，大概率是異步同步邏輯搞錯了，多加注意即可
寬度設置
列寬不知道是以什么為單位，反正不是像素(已測量)，例子中是以厘米為單位再乘以 4.7 的結果設置的，4.7 是不斷測試的結果.
快捷查看列寬的方法，打開 wps 表格，長按列與列字母間的豎線，就能看到列寬，取厘米的單位即可.見下圖
前景色
前景色設置必須右鍵單元格選擇設置單元格格式，然后選擇圖案樣式選擇顏色，就可以前景色填充
worksheet.getCell('A2').fill = { type: 'pattern'， pattern:'darkTrellis'， fgColor:{argb:'FFFFFF00'}， bgColor:{argb:'FF0000FF'} };
背景色
worksheet.getCell('A2').fill = { type: "pattern"， pattern: "solid"， fgColor: { argb: next.bgColor }， }
排版不一致的問題
解決 Mac 下編輯 Microsoft Office Word 文檔與 Windows 排版不一致的問題，，不同的系統用 wps 打開相同的表格，打印預覽的時候，表格寬度顯示不一樣
問題詳細說明地址
我的解決辦法就是 mac 下顯示正常，按 mac 下的寬度來設置就可以了
參考資料
exceljs
node-xlsx
js-xlsx
函數節流與函數防抖是我們解決頻繁觸發DOM事件的兩種常用解決方案，但是經常傻傻分不清楚。。。這不，在項目中又用遇到了，在此處記錄一下
函數防抖 debounce
原理：將若干函數調用合成為一次，并在給定時間過去之后，或者連續事件完全觸發完成之后，調用一次(僅僅只會調用一次?。。。。。。。。?！)。
舉個栗子：滾動scroll事件，不?；瑒訚L輪會連續觸發多次滾動事件，從而調用綁定的回調函數，我們希望當我們停止滾動的時，才觸發一次回調，這時可以使用函數防抖。
原理性代碼及測試：
// 給盒子較大的height，容易看到效果
<style>
* {
padding: 0;
margin: 0;
}
.box {
width: 800px;
height: 1200px;
}
</style>
<body>
<div class="container">
<div class="box" style="background: tomato"></div>
<div class="box" style="background: skyblue"></div>
<div class="box" style="background: red"></div>
<div class="box" style="background: yellow"></div>
</div>
<script>
window.onload = function() {
const decounce = function(fn, delay) {
let timer = null
return function() {
const context = this
let args = arguments
clearTimeout(timer) // 每次調用debounce函數都會將前一次的timer清空，確保只執行一次
timer = setTimeout(() => {
fn.apply(context, args)
}, delay)
}
}
let num = 0
function scrollTap() {
num++
console.log(看看num吧 ${num})
}
// 此處的觸發時間間隔設置的很小
document.addEventListener('scroll', decounce(scrollTap, 500))
// document.addEventListener('scroll', scrollTap)
}
</script>
</body>
此處的觸發時間間隔設置的很小，如果勻速不間斷的滾動，不斷觸發scroll事件，如果不用debounce處理，可以發現num改變了很多次，用了debounce函數防抖，num在一次上時間的滾動中只改變了一次。
調用debouce使scrollTap防抖之后的結果：
直接調用scrollTap的結果：
補充：瀏覽器在處理setTimeout和setInterval時，有最小時間間隔。
setTimeout的最短時間間隔是4毫秒；
setInterval的最短間隔時間是10毫秒，也就是說，小于10毫秒的時間間隔會被調整到10毫秒。
事實上，未優化時，scroll事件頻繁觸發的時間間隔也是這個最小時間間隔。
也就是說，當我們在debounce函數中的間隔事件設置不恰當（小于這個最小時間間隔），會使debounce無效。
函數節流 throttle
原理：當達到了一定的時間間隔就會執行一次；可以理解為是縮減執行頻率
舉個栗子：還是以scroll滾動事件來說吧，滾動事件是及其消耗瀏覽器性能的，不停觸發。以我在項目中碰到的問題，移動端通過scroll實現分頁，不斷滾動，我們不希望不斷發送請求，只有當達到某個條件，比如，距離手機窗口底部150px才發送一個請求，接下來就是展示新頁面的請求，不停滾動，如此反復；這個時候就得用到函數節流。
原理性代碼及實現
// 函數節流 throttle
// 方法一：定時器實現
const throttle = function(fn,delay) {
let timer = null
return function() {
const context = this
let args = arguments
if(!timer) {
timer = setTimeout(() => {
fn.apply(context,args)
clearTimeout(timer)
},delay)
}
}
}
// 方法二：時間戳
const throttle2 = function(fn, delay) {
let preTime = Date.now()
return function() {
const context = this
let args = arguments
let doTime = Date.now()
if (doTime - preTime >= delay) {
fn.apply(context, args)
preTime = Date.now()
}
}
}
需要注意的是定時器方法實現throttle方法和debounce方法的不同：
在debounce中：在執行setTimeout函數之前總會將timer用setTimeout清除，取消延遲代碼塊，確保只執行一次
在throttle中：只要timer存在就會執行setTimeout，在setTimeout內部每次清空這個timer，但是延遲代碼塊已經執行啦，確保一定頻率執行一次
我們依舊可以在html頁面中進行測試scroll事件，html和css代碼同debounce，此處不贅述，運行結果是（可以說是一場漫長的滾輪滾動了）：
最后再來瞅瞅項目中封裝好的debounce和throttle函數，可以說是很優秀了，考慮的特別全面，希望自己以后封裝的函數也能考慮的這么全面吧，加油！
/*
空閑控制 返回函數連續調用時，空閑時間必須大于或等于 wait，func 才會執行
@param {function} func 傳入函數，最后一個參數是額外增加的this對象，.apply(this, args) 這種方式，this無法傳遞進函數
@param {number} wait 表示時間窗口的間隔
@param {boolean} immediate 設置為ture時，調用觸發于開始邊界而不是結束邊界
@return {function} 返回客戶調用函數
/
const debounce = function(func, wait, immediate) {
let timeout, args, context, timestamp, result;
const later = function() {
// 據上一次觸發時間間隔
let last = Number(new Date()) - timestamp;
// 上次被包裝函數被調用時間間隔last小于設定時間間隔wait
if (last < wait && last > 0) {
timeout = setTimeout(later, wait - last);
} else {
timeout = null;
// 如果設定為immediate===true，因為開始邊界已經調用過了此處無需調用
if (!immediate) {
result = func.call(context, ...args, context);
if (!timeout) {
context = args = null;
}
}
}
};
return function(..._args) {
context = this;
args = _args;
timestamp = Number(new Date());
const callNow = immediate && !timeout;
// 如果延時不存在，重新設定延時
if (!timeout) {
timeout = setTimeout(later, wait);
}
if (callNow) {
result = func.call(context, ...args, context);
context = args = null;
}
return result;
};
};
/*
頻率控制 返回函數連續調用時，func 執行頻率限定為 次 / wait
@param {function} func 傳入函數
@param {number} wait 表示時間窗口的間隔
@param {object} options 如果想忽略開始邊界上的調用，傳入{leading: false}。
如果想忽略結尾邊界上的調用，傳入{trailing: false}
@return {function} 返回客戶調用函數
*/
const throttle = function(func, wait, options) {
let context, args, result;
let timeout = null;
// 上次執行時間點
let previous = 0;
if (!options) options = {};
// 延遲執行函數
let later = function() {
// 若設定了開始邊界不執行選項，上次執行時間始終為0
previous = options.leading === false ? 0 : Number(new Date());
timeout = null;
result = func.apply(context, args);
if (!timeout) context = args = null;
};
return function(..._args) {
let now = Number(new Date());
// 首次執行時，如果設定了開始邊界不執行選項，將上次執行時間設定為當前時間。
if (!previous && options.leading === false) previous = now;
// 延遲執行時間間隔
let remaining = wait - (now - previous);
context = this;
args = _args;
// 延遲時間間隔remaining小于等于0，表示上次執行至此所間隔時間已經超過一個時間窗口
// remaining大于時間窗口wait，表示客戶端系統時間被調整過
if (remaining <= 0 || remaining > wait) {
clearTimeout(timeout);
timeout = null;
previous = now;
result = func.apply(context, args);
if (!timeout) context = args = null;
//如果延遲執行不存在，且沒有設定結尾邊界不執行選項
} else if (!timeout && options.trailing !== false) {
timeout = setTimeout(later, remaining);
}
return result;
};
};
本文旨在通過一個簡單的例子，練習vuex的幾個常用方法，使初學者以最快的速度跑起來一個vue + vuex的示例。
學習vuex需要你知道vue的一些基礎知識和用法。相信點開本文的同學都具備這個基礎。
另外對vuex已經比較熟悉的大佬可以忽略本文。
基于vue-cli腳手架生成一個vue項目
常用npm命令：
npm i vue-vli -g vue --version vue init webpack 項目名 進入項目目錄，使用npm run dev先試著跑一下。
一般不會出現問題，試跑成功后，就可以寫我們的vuex程序了。
使用vuex首先得安裝vuex，命令：
npm i vuex --save介紹一下我們的超簡單Demo，一個父組件，一個子組件，父組件有一個數據，子組件有一個數據，想要將這兩個數據都放置到vuex的state中，然后父組件可以修改自己的和子組件的數據。子組件可以修改父組件和自己的數據。
先放效果圖，初始化效果如下：
如果想通過父組件觸發子組件的數據，就點“改變子組件文本”按鈕，點擊后效果如下：
如果想通過子組件修改父組件的數據，就在子組件點擊“修改父組件文本”按鈕，點擊后效果如下：
首先是Parent.vue組件
<template> <div class="parent"> <h3>這里是父組件</h3> <button type="button" @click="clickHandler">修改自己文本</button> <button type="button" @click="clickHandler2">修改子組件文本</button> <div>Test: {{msg}}</div> <child></child> </div> </template> <script> import store from '../vuex' import Child from './Child.vue' export default { computed: {
msg(){ return store.state.testMsg;
}
}, methods:{
clickHandler(){
store.commit('changeTestMsg', '父組件修改自己后的文本')
},
clickHandler2(){
store.commit('changeChildText', '父組件修改子組件后的文本')
}
}, components:{ 'child': Child
},
store,
} </script> <style scoped> .parent{ background-color: #00BBFF; height: 400px;
} </style> 下面是Child.vue子組件
<template> <div class="child"> <h3>這里是子組件</h3> <div>childText: {{msg}}</div> <button type="button" @click="clickHandler">修改父組件文本</button> <button type="button" @click="clickHandler2">修改自己文本</button> </div> </template> <script> import store from '../vuex' export default { name: "Child", computed:{
msg(){ return store.state.childText;
}
}, methods: {
clickHandler(){
store.commit("changeTestMsg", "子組件修改父組件后的文本");
},
clickHandler2(){
store.commit("changeChildText", "子組件修改自己后的文本");
}
},
store
} </script> <style scoped> .child{ background-color: palegreen; border:1px solid black; height:200px; margin:10px;
} </style> 最后是vuex的配置文件
import Vue from 'vue' import Vuex from 'vuex';
Vue.use(Vuex) const state = { testMsg: '原始文本', childText:"子組件原始文本" } const mutations = {
changeTestMsg(state, str){
state.testMsg = str;
},
changeChildText(state, str){
state.childText = str;
}
} const store = new Vuex.Store({ state: state, mutations: mutations
}) export default store;通過該vuex示例，了解vuex的常用配置及方法調用。希望對不怎么熟悉vuex的同學快速上手vuex項目有點幫助。
因為沒太多東西，我自己也是剛接觸，本例就不往GitHub扔了，如果嘗試了本例，但是沒有跑起來的同學，可以一起交流下。
為何深色模式看起來不自然？它的實用性到底怎么樣？深色模式是不是對眼睛更健康？結合文獻，我們一起來探究深色模式的種種！
在過去的幾年中，深色模式一直是用戶最期待的一個功能。你可以自由切換你喜歡的模式來適應當前的場景，iOS和Android也都在2019年布局了系統級的深色模式，深色模式可獲得出色的視覺體驗，尤其是在弱光環境中……有助于你專注地開展工作，因為內容會較為顯眼，而顏色加深的控制項和窗口則會隱入背景之中。但真是這樣嗎，或者只是一種實際上弊大于利的操作？
雖然各種軟件界面的色調和顏色會有所不同，但是對深色模式的處理方式都是在深色背景上顯示明亮文本和界面元素的配色方案。相比之下，在淺色背景上顯示深色文本和界面元素的配色方案，在這里我們稱之為淺色模式。
而事實上，深色模式比淺色模式早了幾十年。在其最初的階段，深色模式并不是一種有意的解決方案，而僅僅是當時計算顯示設備是陰極射線管（CRT），且只能顯示單色的顯示，屏幕看上去就是黑的，黑底白字或者黑底綠字就是計算機行業的早期狀態。直到1980年代彩色顯示器發明后，微軟視窗系統上線之后，黑底顯示才退出主流。蘋果在1984年推出“麥金塔”個人電腦，第一次發布采用圖形用戶界面，由此開啟了計算機屏幕白底顯示的主流之路。
ibm 5151單色監視器
淺色模式出現的確切時間很難確定，但可以追溯到施樂Parc圖形用戶界面，它也極大地影響了早期蘋果的“麥金塔”和其他操作系統，該界面使用了以白色背景為主的深色文本和界面元素。它與顯示技術的進步和現代圖形用戶界面的出現密切相關。這種能夠顯示色彩的且更先進的RGB CRT顯示器拉開了淺色模式的序幕。
1973年的施樂Alto是最早使用輕型接口模式的計算機之一
深色模式的實用性有多少，每個人看法也不一樣。盡管深色模式的界面可能不像淺色模式那樣觀感清晰，但深色模式的界面卻具有一定的魅力，可以讓你聯想到新穎，高端，精致，神秘，力量，奢華這些詞。但是，黑色也是一種會引起人們強烈的情感一個顏色，并且在過度使用時很容易使人無法承受。
2019年9月，蘋果公司上線深色模式（Dark Model）時，在官網上如是宣傳道。從iPhone到Mac，當庫克決定在蘋果公司幾乎所有產品上線深色模式、甚至要求所有在AppStore上架的應用都必須兼容深色模式時，安卓陣營的谷歌、華為、三星等頭部公司也紛紛在其手機中推出了深色模式，相應地從WhatsApp到微信等全球主流的應用也都推出了深色模式。
但是，想要獲得良好的深色模式是相對比較難的。一方面，深色模式迫使放大瞳孔來捕獲必要的視覺信息，從而導致整體清晰度的降低。而同時界面中高亮的部分又迫使我們的瞳孔縮小去適應亮度，以便提高清晰度。這也就能理解為什么白色背景上的黑色文本在你的眼睛中通常會顯得更清晰的原因。
擴大的瞳孔讓光線更多，但感覺到的銳度受到損害
行業對深色模式追逐的群羊效應，也進一步加劇、放大了一個見解：深色模式對眼睛更友好更健康！
但是，事實并非如此。對于一些有散光的人來說，在某種程度上深色模式對他們的眼睛來說更糟糕，深色模式比淺色模式更友好更健康的科學仍有待討論。斯坦?！ぐ轄査寡劭蒲芯克难劭茖＜覍Υ吮硎荆骸拌b于文獻中的數據，我認為深色模式對眼睛沒有任何的友好和健康。” 這種深色模式對眼睛疲勞和潛在的眼睛健康的影響時，使用時間可能比設備的亮度或亮度更重要。
根據美國驗光協會的說法稱，大多數人的眼睛在某種程度上都患有散光，但通常不會引起注意。據美國眼科學院統計，每三個美國人中就一個存在散光的情況，1.5億美國人需要佩戴眼鏡來矯正視力；香港理工大學針對2700多人的臨床檢測發現，在21歲的30歲的香港人中，近40%以上患有100度以上散光。
一起看下面的說明性圖像。即使你有完美的視覺，你也很可能在黑色背景上看到白色文字周圍的光暈。
淺色模式與深色模式
如果增加文字并降低文字的大小，這種效果可能會更強：
右邊的圖像你應該會看到更多的光暈，如果你有散光癥狀，深色模式可能會讓你看屏幕更費勁。在深色模式下，虹膜打開以接收更多的光，并且瞳孔的變形在眼睛上產生了更加模糊的焦點，因此，當你在深色屏幕上看到淺色文本時，其邊緣似乎滲入黑色背景，也就是所謂的“光暈效果”。雖然深色模式可能更適合夜晚等弱光環境下使用，但不一定能幫助更好地閱讀，對于散光患者來說，可能還會加劇視疲勞。
當然，從實用性上講，深色模式也有它的好處，深色模式利用OLED屏幕在純黑的背景下不發光的特性，確實能有效的省電，讓你的電子設備續航上提升很大，這也是很多人一直在追求深色模式的一個重要原因，只要手機續航強比啥都重要！這也可能是蘋果公司決定在幾乎所有產品上線深色模式的一個原因。
另外深色模式更有利于給用戶營造一種沉浸體驗，對于視覺娛樂應用尤為如此。當你想突出顯示特定類型的內容時，深色模式會特別有用。豆瓣、數字尾巴、網易云音樂是我常用的幾個軟件，它們都已經適配了深色模式。在這種模式下你的目光會更加注意到電影的海報、數碼產品和充滿活力的音樂專輯上。
豆瓣、數字尾巴、網易云音樂的深色模式
一是由于我們人腦的組織結構造成的，從多年來的多項科學研究和調查得出的結論是，從物種進化來看，人類99%的時間都是在白天中活動，人腦更傾向于在淺的背景上顯示深色的圖像。所以無論白天還是黑夜，淺色的背景都可以讓你更快地專注于顯示的元素，而深色的背景則使其難以辨別文字和視覺界面元素，從而影響你的閱讀效果并最終使你的眼睛疲勞。 其實從世界各地多個洞穴中發現的史前壁畫也能說明為什么我們傾向于喜歡淺色模式。
追逐獵物的獅子，法國Chauvet Cave，約公元前30,000-28,000
德國帕紹大學曾經做過一次測試。在該研究要求參與者閱讀屏幕上的正極性（白色背景上的黑色文本）或負極性（黑色背景上的白色文本）的文本。隨后，參與測試的人員會執行基本的校對任務，例如查找拼寫或語法錯誤。研究人員還測量了每種模式下參與者的閱讀速度。結果是所有參與者在正極性條件下的表現都會更好，他們檢查出更多的錯誤以及閱讀的速度更快。
可讀性差異
另一個學習發現正極性對于在顯示器上讀取小文本特別有利。人腦具有更快的可讀性，更喜歡在光線背景下顯示的深色文本和物體。
二是由于含有大量藍光的光源會使我們眼睛不舒服，當我們談論屏幕對眼睛的潛在破壞性影響時，我們通常是在談論“藍光”，這是由短、高能量波長構成的光譜的一部分。研究發現藍光可能是導致眼睛疲勞的一個因素，但指出長時間不眨眼的干眼也是導致眼睛疲勞的一個更嚴重的原因，當然也有是因為字體太小，以及散光這樣的原因。
當我們身處暗室或是在黃昏或夜晚時，眼睛會切換成不同的視覺模式；在弱光環境下，人眼會從對綠色敏感變成對高能量藍光敏感，這代表我們在大量的接收藍光，因此對刺眼強光的敏感度會增強。這類情形對駕駛人而言并不陌生，當他們被來車車頭燈的強光照射時，特別是使用現代化氙氣燈或LED頭燈的車輛，可能會暫時喪失視力。
平板電腦、智能手機和其他電子顯示屏，不僅改變了我們所接觸的光譜，也使我們的視覺行為發生轉變。我們必須意識到，我們現在用于“近距離”視物的時間比以往多得多，這通常是因為背景亮度太暗所致。
在德國光學公司蔡司官方網站上，對于藍光也作一分為二的評價：“好處是當外界環境變亮也就是藍光較多時，身體便釋放出血清素—它是其中一種快樂荷爾蒙以及皮質醇—這是一種壓力荷爾蒙。這兩種荷爾蒙能讓我們保持清醒，富有活力，同時也應用于冬季抑郁和失眠的治療中。但過多的紫外光和藍紫光可能會對肉眼造成損傷，除了可能導致令人難受的結膜和角膜發炎，也可能會破壞眼睛的晶狀體（例如白內障），尤其是傷害我們的視網膜（黃斑病變）?！?
在WWDC 2019大會上，蘋果宣布了iOS13的深色模式功能，在令人興奮之余，作為設計師和開發人員，我們應該考慮的該如何去實現它。蘋果和安卓已經發布了為應用程序設計深色模式的設計指南。當然，沒有硬性規定要求遵循他們提供的設計指南，這些只是指導原則。
由于Material Design設計語言的原因，投影的占比是非常大的。在淺色模式下還好，但這不太適用于深色模式，因為深色背景上的黑色陰影在視覺上不容易察覺，為此安卓還提供了在深色模式下不同層級的卡片與投影上的參考。
根據設計文檔來看，iOS背景為純黑色，色值為＃000000，Google 則更喜歡深灰色，色值為＃121212。
通過提供的設計指南，我們可以輕易上手來設計和開發我們的軟件，但要注意的是深色模式并不是簡單的與淺色模式顏色對調，必須為所有的元素進行單獨配色。
淺色模式下的白色不會在深色模式下轉換成純黑色
這樣也就能理解為什么很多軟件并沒有全部去適配新的深色模式，一方面使用場景決定的，另一方面就是深色模式并不是簡單地換個換個顏色就行，很多元素需要重新設計和開發。
在去年的 WWDC 大會上，蘋果人機交互團隊的設計師曾對 macOS 的深色模式使用場景做了進一步的解釋。
他指出，只有閱讀瀏覽或是內容創作型 App 才需要長期啟用深色模式，比如文字或代碼編輯。它們會借助黑底白字的高對比度特性來讓用戶視線保持集中，其它大部分軟件對于深色模式的需求反而并不強烈。
或則你可以通過使用場景去選擇，在明亮的環境中使用淺色模式，在昏暗的環境中使用深色模式。
但是在大多數情況下，真正幫助你避免眼睛疲勞的是不要整天盯著屏幕，而不是糾結到底用深色還是淺色模式。
轉自：站酷-
無論是 pc 端還是移動端，無可避免都會涉及到列表查詢有關的操作，但對于這兩種不同的設備，其列表查詢的最佳處理方式也是完全不同。
對于 pc 端列表查詢來說，前端通常是給與服務端當前需要獲取的數據量(如 pageCount，limit 等參數)以及所需要獲取數據的位置(如 pageSize，offset 等參數)作為查詢條件。然后服務端然后返回數據總數，以及當前數據，前端再結合這些數據顯示頁面總數等信息。這里我稱為相對位置取數。
對于移動端而言，沒有pc 端那么大的空間展示以及操作，所以基本上都會采用下拉取數這種方案。
那么我們在處理移動端列表查詢時候使用這種相對位置取數會有什么問題呢？
通過相對位置取數會具有性能問題，因為一旦使用 offset 信息來獲取數據，隨著頁數的增加，響應速度也會變的越來越慢。因為在數據庫層面，我們每次所獲取的數據都是“從頭開始第幾條”，每次我們都需要從第一條開始計算，計算后舍棄前面的數據，只取最后多條數據返回前端。
當然了，對于相對位置取數來說，數據庫優化是必然的，這里我就不多做贅述了。對于前端開發來說，優秀的的查詢條件設計可以在一定方面解決此問題。
事實上，對于一個實際運行的項目而言，數據更新才是常態，如果數據更新的頻率很高或者你在當前頁停留的時間過久的話，會導致當前獲取的數據出現一定的偏差。
例如：當你在獲取最開始的 20 條數據后，正準備獲取緊接著的后 20 條數據時，在這段時間內 ，發生了數據增加，此時移動端列表就可能會出現重復數據。雖然這個問題在 pc 端也存在，但是 pc 端只會展示當前頁的信息，這樣就避免了該問題所帶來的負面影響。
我們在上面的問題中說明了，移動端下拉加載中使用相對位置查詢取數是有問題的。
那么，如果當前不能迅速結合前后端進行修改 api 的情況下，當服務端傳遞過來的數據與用戶想要得的數據不一致，我們必須在前端進行處理，至少處理數據重復問題所帶來的負面影響。
因為當前分頁請求時無狀態的。在分頁取到數據之后前端可以對取得的數據進行過濾，過濾掉當前頁面已經存在的 key(例如 id 等能夠確定的唯一鍵)。
通過這種處理方式，我們至少可以保證當前用戶看到的數據不會出現重復。同時當列表數據可以編輯修改的時候，也不會出現因為 key 值相同而導致數據錯亂。
如果不使用相對位置獲取數據，前端可以利用當前列表中的最后一條數據作為請求源參數。前端事先記錄最后一條數據的信息。例如當前的排序條件為創建時間，那么記錄最后一條數據的創建時間為主查詢條件(如果列表對應的數據不屬于個人，可能創建時間不能唯一決定當前數據位置，同時還需要添加 ID 等信息作為次要查詢條件)。
當我們使用絕對位置獲取數據時候，雖然我們無法提供類似于從第 1 頁直接跳轉 100 頁的查詢請求，但對于下拉加載這種類型的請求，我們不必擔心性能以及數據重復顯示的問題。
對于相對位置取數來說，前端可以根據返回數據的總數來判斷。但當使用絕對位置取數時，即使獲取數據總數，也無法判斷當前查詢是否存在后續數據。
從服務器端實現的角度來說，當用戶想要得到 20 條數據時候，服務端如果僅僅只向數據庫請求 20 條數據，是無法得知是否有后續數據的。服務端可以嘗試獲取當前請求的數據條數 + 1, 如向數據庫請求 21 條數據，如果成功獲得 21 條數據，則說明至少存在著 1 條后續數據，這時候，我們就可以返回 20 條數據以及具有后續數據的信息。但如果我們請求 21 條數據卻僅僅只能獲取 20 條數據(及以下)，則說明沒有后續數據。
如可以通過 “hasMore” 字段來表示是否能夠繼續下拉加載的信息。
{ data: [], hasMore: true }事實上，前面我們已經解決了移動端處理列表查詢的問題。但是我們做的還不夠好，前端還需要結合排序條件來處理并提供請求參數，這個操作對于前端來說也是一種負擔。那么我們就聊一下 HATEOAS 。
HATEOAS (Hypermedia As The Engine Of Application State, 超媒體即應用狀態引起) 這個概念最早出現在 Roy Fielding 的論文中。REST 設計級別如下所示:
HATEOAS 會在 API 返回的數據中添加下一步要執行的行為，要獲取的數據等 URI 的鏈接信息。客戶端只要獲取這些信息以及行為鏈接，就可以根據這些信息進行接下來的操作。
對于當前的請求來說，服務端可以直接返回下一頁的信息，如
{ data: [], hasMore: true, nextPageParams: {}
}服務端如此傳遞數據，前端就不需要對其進行多余的請求處理，如果當前沒有修改之前的查詢以及排序條件，則只需要直接返回 “nextPageParams” 作為下一頁的查詢條件即可。
這樣做的好處不但符合 REST LEVEL 3,同時也減輕了前端的心智模型。前端無需配置下一頁請求參數。只需要在最開始查詢的時候提供查詢條件即可。
當然，如果前端已經實現了所有排序添加以及查詢條件由服務端提供，前端僅僅提供組件，那么該方案更能體現優勢。 前端是不需要知道當前業務究竟需要什么查詢條件，自然也不需要根據查詢條件來組織下一頁的條件。同時，該方案的輸入和輸出都由后端提供，當涉及到業務替換( 查詢條件，排序條件修改)時候，前端無需任何修改便可以直接替換和使用。
一旦涉及到移動端請求，不可避免的會有網絡問題，當用戶在火車或者偏遠地區時候，一旦下拉就會涉及取數，但是當前數據沒有返回之前，用戶多次下拉可能會有多次取數請求，雖然前端可以結合 key 使得渲染不出錯，但是還是會在緩慢的網絡下請求多次，無疑雪上加霜。這時候我們需要增加條件變量 loading。
偽代碼如下所示：
// 查詢 function search(cond) {
loading = true api.then(res => {
loading = false }).catch(err => {
loading = false })
} // 獲取下一頁數據 function queryNextPage() { if (!nextPageParams) return if (!loading) return search(nextPageParams)
}今天跟大家聊聊設計中焦點配色這個話題。焦點這個詞對于設計師來說應該不會感到陌生，但是這節課我們主要是從色彩的角度，來看看焦點在設計中的作用以及色彩焦點的重要性。首先我們要知道設計的目的就是通過視覺來傳達信息，而視覺的表現形式是有一定規律性的，在這些眾多的規律性當中，其中有一條就是通過色彩來實現，而焦點配色就是色彩設計中最有效的一個手段。
其實無論是繪畫、攝影還是我們的設計，都存在大量的焦點配色，只是我們平時沒有特別去注意而已。比如莫奈的這幅《日出·印象》，我們來嘗試分析一下焦點的設置和移動。
我想絕大多數人都應該是這種移動路線，也就是在大面積灰色調和冷色調中先被強暖色的太陽所吸引，然后是近景全黑色的船，接著順延到另一條船上，當然每個人都會有所不同。
比如也可能是這種從遠景到近景的順序。
也可能有的人是從近到遠的觀看順序，但是無論你是哪一種，都不重要，為什么？
因為無論你的視線是怎么移動的，都不會影響到我們最終焦點的歸屬。大家可以感受一下，當你看這幅畫的時候，無論你先看哪后看哪，最終你的眼睛都會被這個橙紅色的太陽所吸引，這就是色彩焦點的魅力。
我們再來看一個攝影作品，這個跟剛才那幅畫來比，焦點就更加清晰了，而且這里也不需要焦點的移動，很明顯焦點就是這個人物。
但是這個焦點是怎么通過色彩得到強化的呢？可能有的人會說這么明顯的人物肯定是焦點啊，但是你可以嘗試把人物后面的暖色光去掉看看，雖然人物同樣是這個畫面的焦點，但是一定沒有現在這樣搶眼，因為暖色和背景的冷色形成了強烈的對比。
所以無論是繪畫、攝影還是我們接下來會看到的設計，其中都會包含一種故意的或者是有意識的色彩焦點的安排，而這種焦點的形成是怎么實現的呢？其實就是通過色彩對比，因為有色彩對比必定產生焦點，即使沒有焦點我們也會努力去尋找焦點。我們聯想下平時的生活就會發現，無論是我們看到一幅畫面，或者是置身于一個真實的環境中，我們都會不自覺地去尋找色彩最突出或者最醒目的東西，這就是作為人的一種本能，也就是自然而然地去尋找焦點。
下面我們來看一些設計作品，我們看這三個界面，不能說沒有焦點，有，就是圖片，準確地說應該是沒有色彩焦點，所以我們接收到的就是圖片加上信息排在一起，我們很難在短時間內區分出哪些是重要信息哪些是次要信息。我們不知道視線應該落在哪里，因為沒有突出的東西，這種不知所措會讓看的人感到不舒服，這就是沒有焦點會造成的一種情況。
同樣這三個界面，我們什么都不變，只是在想強調的部分填充一個顏色，這樣就會讓看的人可以通過色彩毫不猶豫地感受到焦點，這種交互才是人性化的交互，而這個簡單的過程其實就是色彩設計。
我們再來看一個更加簡單易懂的，比如現在這個，就是在一個藍色背景上編排純白的文字，可能通過字號和距離的安排我們也知道孰輕孰重，但是如果從色彩的角度來看還不夠，因為沒有形成讓人快速識別的焦點。
如果在想強調的地方，適當的填充一個顏色，那么瞬間就有了焦點，而這個顏色和背景色的對比越強，焦點就越明顯。
我們看這個海報，當我們看到這個畫面的時候首先注意到的是什么？
首先注意的肯定是上方的圖片，其次會根據信息的層級大小去看主標題，然后是次要信息。這種沒有設置色彩焦點的形式，雖然不太會影響信息的閱讀，但我們不妨試試有色彩焦點的情況。
當原本就是畫面中比較重要的標題信息和突出的英文被填充紅色之后，焦點就產生了并且得到強化。
這時候當我們再看這個作品，就可以在短時間內迅速獲得信息，如果想繼續了解也可以繼續閱讀，這就是有焦點和沒焦點或者焦點不突出的差別。
我們看這個 banner，這里我們不說它的版式怎么樣，我們就看色彩和焦點，這個畫面有什么問題呢？就是焦點設置錯誤，什么意思？
也就是大家看這個畫面的時候，雖然都會先看月餅的圖片，然后是標題到進入專場，但是大家發現沒有，你的視線總會被中間這個粉色的花瓣吸引。
就是那種你不想看它，但是又不得不看的感覺，因為這個花瓣的顏色完全沒必要出現在這里，因為它不是信息，為什么要充當焦點呢？這就是焦點錯誤。
我們把花瓣去掉試試，這樣焦點就很清晰明確了。
現在我們知道了有焦點和沒焦點的差別，那焦點的設置其實也是有多種情況的。我們就拿這個網頁來舉例，版式部分保持不變，你想突出哪里就在哪里設置焦點。我們來看看通過色彩把焦點安排在不同的地方，這個頁面產生什么樣的效果。
比如我們可以把焦點設置在上半部分，也就是頂部的品牌和導航區域。
也可以把焦點設置在主標題的文字信息上。
還可以設置在底部區域，形成色塊。
當然也可以是自由式的焦點設置，強調你想強調的部分，這種情況下就有了焦點的移動。
通過之前的案例分析我們總結一下有焦點的好處：首先它滿足了人的生理需求，其次滿足了視覺傳達的需求，最后滿足了審美的需求。也就是說我們所要做的視覺設計是需要傳達信息的，你得讓受眾看到你的信息才行，而要想有效的讓人看到信息，焦點的設置就要滿足前面三個需求，如果沒有滿足，一定程度上說明你的作品是失敗的。實際人都是充滿惰性的，也都不喜歡延遲，當人們看到所有的信息在它應該在的位置，不需要眼睛和大腦再去閱讀，這時候就得到了一種觀看和閱讀的滿足感。
說了這么多焦點的好處，下面我們就來看看如何通過配色形成或者強化焦點。首先我們要知道的就是焦點是通過對比實現的，而這里包括了色相對比形成焦點、冷暖對比形成焦點、深淺對比形成焦點、有彩色與無彩色對比形成焦點、花色與純色對比形成焦點、色彩面積對比形成焦點。
首先我們來看色相對比形成焦點，這里的色相對比通常是指互補色或對比色之間的對比，因為色相差異越大越容易產生焦點。比如這個海報就是藍色和黃色的互補色對比，當然需要注意的是，我們所列舉出的這些對比并不是單獨存在的，它們往往都是相互結合的，比如這個海報最明顯的就是色相上的互補色對比，當然你也可以說是冷暖對比，同時也包括面積對比。
這個網頁作品，藍色與綠色形成了色相上的對比，同時它們二者又與背景形成了有彩色與無彩色的對比。
這個圣誕主題的 banner，整體是大面積的暗紅色，這就讓人物頭頂的綠色圣誕樹成為了焦點，也就是色相對比中通過對比色形成焦點。
然后是冷暖色對比產生焦點，這個版面很簡單，就是文字編排加上背景，但是很明顯，通過在強調的地方使用藍色與背景的粉紅色形成一種冷暖對比，讓焦點一目了然。
這個同樣也是紅色與藍色的冷暖對比強調焦點，讓人一眼就能抓住重點。
這個同樣也是通過冷暖對比形成焦點，只不過這個畫面并不是單一焦點的形式，是多個焦點從大到小或從近到遠的移動。
如果色相對比不夠明顯，那么通過單一色彩或近似色彩的深淺對比也可以很好的形成焦點，同樣純度和明度差異越大越容易產生焦點。比如這個畫面中的焦點面包與背景形成的就是深淺對比。
這個畫面整體是褐色的基調，但是杯子中的茶湯是比背景更亮一些的顏色，所以它自然而然地就成為了畫面的焦點，而且這個焦點也是符合這個版面的設計邏輯的。
這個頁面的背景是偏深一些的粉紅色，當然圖片肯定是這個畫面的第一焦點，但除此之外，這個畫面中還有另外兩個焦點，就是比背景偏暗一些的嘴唇，這就是利用深淺色對比形成焦點。
焦點的作用以及如何強調焦點都很好理解和操作，但是設置焦點背后的原理是什么呢？就是我們之前講過的色彩營銷，因為設計的目的是通過視覺傳達信息，而傳遞信息的目的是為了營銷，所以答案也就很明了了。也就是如何設置焦點以及讓誰成為焦點，這背后的邏輯要依據營銷的目的，換句話說焦點的設置一定要滿足以上的需求，假如設置了錯誤的焦點，就會適得其反，倒不如不設置焦點了，這個道理大家一定要明白。
我們接著往下看，下一個就是有彩色與無彩色對比產生焦點。比如我們看上面這個海報，圖片整體是黑白的，只有雨傘的部分是紅色，非常醒目的被凸顯出來，當然就是第一焦點，其次就是紅色的標題性文字。因為黑色與紅色很好的對比效果，所以類似這種形式的攝影作品大家也一定見過很多，就是整體是黑白，個別地方用紅色的形式。
雖然這個網頁頁面上的有彩色并不是單一色彩，但是與背景黑色的搭配，整體上依然是有彩色與無彩色搭配所產生的對比，從而產生焦點。
這個雖然也是有彩色與無彩色的對比，但是這個很巧妙，因為設計者并沒有直接在主標題上填充有彩色，而是在標題下方使用了一個有彩色的色塊，這也是一種變相突顯焦點的方式。
接下來是花色與純色對比產生焦點，這個算是很常見很通用的一種形式了，尤其是照片上編排文字的形式，如果圖片本身的色彩就比較豐富，那么文字色必然要使用單一的色彩才能保證很好的識別。
這個雜志封面的背景是由多種色彩所形成的插畫圖形，而人物一身黑色位于中間形成了第一焦點，其次是位于人物上的綠色文字，可以說既是有彩色與無彩色的對比，又是有彩色與花色之間的對比。
這個海報上的圖片雖然色彩并沒有多純，但是由于色彩比較分散，所以可想而知，在它上方編排文字難免會造成識別度很低的情況，所以設計師也很巧妙地使用了添加色塊的方式，利用這種圖片花色與色塊純色的對比來突出焦點。
最后就是通過色彩面積大小產生焦點，這種面積的對比可以說是非常常見的，可以說大部分有色彩焦點的畫面都是之前的那幾種形式與面積對比的一個結合，但是并沒有誰重要誰不重要一說，就比如這個海報上的紅色圓形，無論你是把它的面積放大，還是把它換成和藍色相近的顏色，焦點的效果都沒有現在的好。所以我們在具體設計配色的時候千萬不要有強迫癥，因為這些方法往往都是結合使用的。
這個也是面積對比產生的焦點，同時又有藍色與紅色的冷暖對比。
這個頁面也是，通過在大面積綠色調中使用一個紅色塊，快速形成對比，從而確定焦點。
以上我們主要講解了通過配色形成焦點的一些方法，但其實細心的同學就會發現，這里面還是有一些潛規則的，有的是和色彩有關，有的可能和色彩無關。比如說同樣的色彩或同樣大小的對象，具象的東西比抽象的東西容易形成焦點、人物比場景或風景容易形成焦點、圖像比文字容易形成焦點、標題文字比內文容易形成焦點、暖色比冷色容易形成焦點、強對比比弱對比容易形成焦點，最后我們就分別來看一下。
具象的事物比抽象的事物容易形成焦點，這個似乎沒什么可說的，大家應該都能明顯的感覺到，就比如這個海報，即使人臉的周圍有著密密麻麻的抽象圖像，我們的注意力依然在人臉的部分。
人物要比場景更容易產生焦點，比如這個海報，同時存在兩張圖片，雖然上方的圖片是一匹馬不是人，但是道理是一樣的，我們的視線總是想關注這個馬的眼睛，而下方的海水我們可能只是一掃而過。
圖片比文字更容易形成焦點，這個也是無需多說的一點，因為即使都是黑白的圖片和文字，我們也會首先注意到圖片，這是圖片所具有的天然魅力。比如這個海報，假如我們把圖片遮掉，那么紅色的「魂」字毋庸置疑就是第一焦點，因為在一堆黑色文字中它實在太顯眼了，但是加上人物圖片的話，就沒有多少人會去關注「魂」字了。
標題比內文更容易產生焦點，這是因為標題所具有的天然優勢，也就是面積優勢，比如我們看這個海報，其實它這里的標題使用與圖片一樣的藍色并不是很突出，雖然日期和副標題使用了色相對比，也確實成為了焦點，但是對于主標題的影響并不是很大，我們依然不會忽略掉主標題，這就是面積原因所造成的，因為它足夠大。
暖色比冷色更容易形成焦點，這個海報就是一個很好的說明，因為海報中兩個圖片大小相當，唯一的區別就是一個是暖色一個是冷色，那么哪個更吸引你呢？一定是暖色，如果你說你就是被冷色所吸引那也沒關系，但是你自己保留意見，我不接受反駁。
最后就是強對比大于弱對比，比如我們看這個海報，其實本身背景色上有色相的對比，但是因為對比不夠強，所以就讓上方的紅色成為了焦點，因為紅色與整體背景形成了強烈的深淺對比。
簡單總結一下，首先我們通過一些案例說明了色彩焦點的重要性，也就是滿足了人的三種需求：生理需求、視覺傳達的需求以及審美的需求。其次我們講解了如何形成或強調焦點，也就是通過一些色彩對比來實現。最后補充了一些焦點配色中存在的潛規則，也就是哪些內容或形式具有形成焦點的天然優勢。當然這一切的落腳點還要歸到視覺傳達以及色彩營銷上。
文章來源：優設 作者：研習設
距離上一次介紹 The Stocks 已經超過五年，前段時間無意間瀏覽到這個網站，才想起我以前好像也寫過文章，不過網站現在變得不太一樣而且內容又更完整了，非常推薦加入收藏，因為真的很方便。如果你還不知道 The Stocks，它整合各種設計相關免費資源，最早只有將一些免費圖庫整合在一起，讓找圖的使用者透過側邊欄選單快速切換各個不同圖庫網站，加速搜尋圖庫的效率。
在全新的 The Stocks 2 除了免費圖庫，加入配色工具、免費圖標、免費影片、免費字體和 Mockups 素材網站共六種項目，相較于早期來說在資源數量上增加不少，現在一樣可以從網站側邊選單選取你要瀏覽的素材類型，The Stocks 就會出現一整排的網站列表讓使用者直接選擇，再從這些網站去尋找你要的免費資源。
對于平常會需要搜尋設計相關資源的使用者來說，The Stocks 是很好用的工具。
不過 The Stocks 現在會加入一些贊助商「推薦」內容，如果使用者進入這些服務，也有付費購買的話 The Stocks 開發者就能獲得回饋（其實就是 Affiliate），網站主要還是以收錄免費服務為主。
網站鏈接：http://thestocks.im/
使用教學
開啟 The Stocks 網站后會隨機顯示一個免費圖庫，The Stocks 主要功能列在左側，點選選單上的網站名稱會將網頁顯示于右側，方便在各個外部網站跳轉和搜尋，不過有些網站不允許被嵌入其他頁面，這時候就會以開新分頁方式替代。
左上角是 The Stocks 收錄的免費資源類型，包括免費圖庫、配色工具、免費圖標、免費影片、免費字體和 Mockups 素材網站，點選后下方的網站列表就會實時更新。
有些標示為 Featured 就是本文前面提到的贊助商推薦內容，大多都是付費服務，例如銷售相片圖片的 Shutterstock、iStock 圖庫，如果有在找圖的朋友應該不陌生，其實很多免費圖庫也是透過刊登付費圖庫廣告來獲取收益。
當然 The Stocks 收錄的網站仍以免費資源居多，點選后就能快速瀏覽網站，如果操作上發現有些問題或無法正確顯示，亦可搜尋該網站名稱直接在瀏覽器開啟。
最近因為疫情關系，很多公司改為在家上班，如果要開會就會透過一些視頻會議軟件例如 Zoom ，The Stocks 也有提供 Zoom 適用的免費虛擬背景（特別是家里背景很雜亂的朋友可以稍微隱藏一下），這些素材可以在網站右上角 Zoom Virtual Backgrounds 找到。
值得一試的三個理由：
文章來源：優設 作者：Pseric
為了降低開發的復雜度，以后端為出發點，比如:Struts、SpringMVC 等框架的使用，就是后端的 MVC 時代;
以 SpringMVC 流程為例:
優點:
前后端職責很清晰: 前端工作在瀏覽器端，后端工作在服務端。清晰的分工，可以讓開發并行，測 試數據的模擬不難，前端可以本地開發。后端則可以專注于業務邏輯的處理，輸出 RESTful等接 口。
前端開發的復雜度可控: 前端代碼很重，但合理的分層，讓前端代碼能各司其職。這一塊蠻有意思 的，簡單如模板特性的選擇，就有很多很多講究。并非越強大越好，限制什么，留下哪些自由，代 碼應該如何組織，所有這一切設計，得花一本書的厚度去說明。
-部署相對獨立: 可以快速改進產品體驗
缺點:
代碼不能復用。比如后端依舊需要對數據做各種校驗，校驗邏輯無法復用瀏覽器端的代碼。如果可 以復用，那么后端的數據校驗可以相對簡單化。
全異步，對 SEO 不利。往往還需要服務端做同步渲染的降級方案。 性能并非最佳，特別是移動互聯網環境下。
SPA 不能滿足所有需求，依舊存在大量多頁面應用。URL Design 需要后端配合，前端無法完全掌控。
NodeJS 帶來的全棧時代
前端為主的 MV* 模式解決了很多很多問題，但如上所述，依舊存在不少不足之處。隨著 NodeJS 的興 起，JavaScript 開始有能力運行在服務端。這意味著可以有一種新的研發模式:
————————————————
版權聲明：本文為CSDN博主「叁有三分之一」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/iME_cho/article/details/105654633
塊級元素（inline）：
塊級元素可以包含行內元素和其它塊級元素，且占據父元素的整個空間，可以設置 width 和 height 屬性，瀏覽器通常會在塊級元素前后另起一個新行。
常見塊級元素：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
<style>
div{
width: 150px;
height: 150px;
background-color: cadetblue;
}
</style>
</head>
<body>
<div>塊級元素1</div>
<div>塊級元素2</div>
</body>
</html>
分析：
塊級元素的高和寬可以被修改，而且塊級元素會在一個塊級元素之后另起一行。
行級元素
行級元素（block）：
一般情況下，行內元素只能包含內容或者其它行內元素，寬度和長度依據內容而定，不可以設置，可以和其它元素和平共處于一行。
常見行級元素：
a,b,strong,span,img,label,button,input,select,textarea
特點：
和相鄰的行內元素在一行上
高度和寬度無效，但是水平方向上的padding和margin可以設置，垂直方向上的無效
默認的寬度就是它本身的寬度
行內元素只能容納純文本或者是其他的行內元素（a標簽除外）
例如：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
<style>
span{
width: 150px;
height: 150px;
font-size: 40px;
background-color: cadetblue;
}
</style>
</head>
<body>
<span>行級元素1</span>
<span>行級元素2</span>
</body>
</html>
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
<style>
span{
width: 150px;
height: 150px;
font-size: 20px;
background-color: cadetblue;
display: inline-block;
}
</style>
</head>
<body>
<span>以前我是行級元素，</span>
<span>現在我只想做行內塊級元素。</span>
</body>
</html>
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
<style>
div{
width: 150px;
height: 150px;
font-size: 30px;
background-color: cadetblue;
display: inline;
}
</style>
</head>
<body>
<div>我以前是塊級元素，</div>
<div>現在我是行級元素！</div>
</body>
</html>
分析：
在VSC中，修改寬高的代碼已經出現了波浪線，證明他是錯誤的，所以現在的div已經變成了行級元素。
————————————————
版權聲明：本文為CSDN博主「董小宇」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/lolly1023/article/details/105715892
其實VSCode編輯器本身自帶了一個功能（Interactive Editor Playground ：可以讓你快速了解VSCode的特性，并且是可以交互的），
但很可惜它的內容是全英文的（將VSCode設置為中文也沒用哦~），
我將每一部分截圖下來，并為你說明關鍵內容，教你學會使用 Interactive Editor Playground
還有一些顯而易見的特性，我不會再用文字敘述一遍（它們都是潛移默化的）
在下文中會涉及到大量快捷鍵的介紹，如果看不懂快捷鍵請自行百度
鼠標 = 文本光標 = 光標
本文成于2020年4月22日，隨著VSCode的版本更迭，此部分內容可能會略有差異（小更改不影響觀看，有較大影響的更新請在評論區告之，我會及時更新的）
打開VSCode > Help > Interactive Playground
你將會打開 Interactive Editor Playground 頁面
VS代碼中的核心編輯器包含許多特性。此頁高亮顯示了10個特性，每個特性介紹中都提供了代碼行供你編輯
接下來的10行內容（你可以理解為目錄，對應10個特性）
多光標編輯（Multi-Cursor Editing）- 選擇一塊區域，選擇所有匹配項，添加其余光標等
智能感應（intelliSense）- 獲取代碼和外部模塊的代碼幫助和參數建議
行操作（Line Actions ）- 快速移動行以重新排序代碼
重命名重構（Rename Refactoring）- 快速重命名代碼庫中的符號（比如變量名、函數名）
格式化（Formatting）- 使用內置文檔和選擇格式使代碼看起來很棒
代碼折疊（Code Folding） - 通過折疊其他代碼區域，關注代碼中最相關的部分
錯誤和警告（Errors and Warnings）- 寫代碼時請參閱錯誤和警告
片段（Snippets）- 花更少的時間輸入片段
Emmet - 只需要敲一行代碼就能生成你想要的完整HTML結構等（極大方便前端開發）
JavaScript Type Checking- 使用零配置的TypeScript對JavaScript文件執行類型檢查。
Multi-Cursor Editing
使用多光標編輯可以同時編輯文檔的多個部分，極大地提高了工作效率
框式選擇
鍵盤同時按下 Shift + DownArrow（下鍵）、Shift + RightArrow（右鍵）、Shift + UpArrow（上鍵）、Shift + LeftArrow（左鍵） 的任意組合可選擇文本塊
也可以用鼠標選擇文本時按 Shift + Alt 鍵
或使用鼠標中鍵拖動選擇（可用性很高）
添加光標
按 Ctrl + Alt + UpArrow 在行上方添加新光標
或按 Ctrl + Alt + DownArrow 在行下方添加新光標
您也可以使用鼠標和 Alt + Click 在任何地方添加光標（可用性很高）
在所有出現的字符串上創建光標
選擇字符串的一個實例，例如我用鼠標選中所有background，然后按 Ctrl + Shift + L，文本中所有的background都將被選中（可用性很高）
IntelliSense
Visual Studio Code 預裝了強大的JavaScript和TypeScript智能感知。
在代碼示例中，將文本光標放在錯誤下劃線的上面，會自動調用IntelliSense
這只是智能提示的冰山一角，還有懸停在函數名上可以看到參數及其注釋（如果有）等等，它會潛移默化的帶給你極大幫助
其他語言在安裝對應插件后，會附帶對應語言的IntelliSense
Line Actions
分別使用 Shift + Alt + DownArrow 或 Shift + Alt + UpArrow 復制光標所在行并將其插入當前光標位置的上方或下方
分別使用 Alt + UpArrow 和 Alt + DownArrow 向上或向下移動選定行（可用性很高）
用 Ctrl + Shift + K 刪除整行（可用性很高）
通過按 Ctrl + / 來注釋掉光標所在行、切換注釋（可用性很高）
Rename Refactoring
重命名符號（如函數名或變量名）
重命名操作將在項目中的所有文件中發生（可用性很高）
代碼如果沒有良好的編寫格式，閱讀起來是一個折磨
Formatting可以解決編寫格式問題：無論你的代碼的格式寫的有多么糟糕，它可以將代碼格式化為閱讀性良好的格式
格式化整個文檔 Shift + Alt + F （可用性很高）
格式化當前行 Ctrl + K Ctrl + F（即先按Ctrl，再按K，最后按F）
鼠標右鍵 > Format Document （格式化整個文檔）
將格式化操作設置為自動化（保存時自動格式化整個文檔）：Ctrl + , 輸入 editor.formatOnSave
鼠標操作，自己嘗試一下，秒懂
快捷鍵：
折疊代碼段是基于基于縮進
錯誤和警告將在你出現錯誤時，高亮該代碼行
在代碼示例中可以看到許多語法錯誤（如果沒有，請你隨便修改它，讓它出現錯誤）
按F8鍵可以按順序在錯誤之間導航，并查看詳細的錯誤消息（可用性很高）
Snippets
通過使用代碼片段，可以大大加快編輯速度
在代碼編輯區，你可以嘗試輸入try并從建議列表中選擇try catch，
然后按Tab鍵或者Enter，創建try->catch塊
你的光標將放在文本error上，以便編輯。如果存在多個參數，請按Tab鍵跳轉到該參數。
Emmet
Emmet將代碼片段的概念提升到了一個全新的層次（前端開發的大寶貝）
你可以鍵入類似Css的可動態解析表達式，并根據在abrevision中鍵入的內容生成輸出
比如說：
然后Enter
————————————————
版權聲明：本文為CSDN博主「索兒呀」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/Zhangguohao666/article/details/105676173
藍藍設計的小編 http://www.syprn.cn