這可能是一篇很多博客的讀者都期待的文章，我最終還是決定說一說『如何為技術文章配圖』這一話題，過去的幾年一直都有非常多的讀者在博客、微博和公眾號下面提出這樣的問題 —— 『你的圖是用什么工具畫的？』，對于這種問題我我一直都很少回復，一方面是因為我在博客下面其實已經寫明了畫圖工具：
本作品采用知識共享署名 4.0 國際許可協議進行許可。 轉載時請注明原文鏈接，圖片在使用時請保留圖片中的全部內容，可適當縮放并在引用處附上圖片所在的文章鏈接，圖片使用 Sketch 進行繪制。
另一方面，我不認為工具在幫助我們配圖時起到了決定性的作用，無論是使用 Photoshop 還是 OmniGraffle 甚至是其他的工具都能達到完全相同的效果，更加重要的其實是我們對于制圖規則的思考并形成一套自恰的體系，這篇文章就會分享一下作者在過去的幾年中是如何完成這一套制圖規則的。
概述
在理解作者對制圖規則的思考之前，我想先簡單分享一下最開始寫博客并且分享一些經驗和知識背后的原因，這對于作者制圖規則的形成起著比較重要的作用；國內的大多數技術博客（包括 CSDN 在內的一眾平臺）并沒有提供邏輯清晰、排版合理并且足夠優雅的內容，很多博客對于內容的排版和設計非常糟糕，作者在查詢到國內的資料時總有一種讀不下去和不忍直視的感覺，所以想輸出一些在內容和排版上都相對優質的內容，而圖片作為一種能夠承載大量信息的媒介和博客的重要一個組成部分自然也要做到足夠美觀和清晰。
從開始寫博客、畫圖到今天也有 5、6 年的時間了，在這個過程中我也不斷地完善了對制圖規則的設計，其中有幾個準則是非常重要的：
- 圖片必須足夠美觀并且清晰地傳達想要表現的內容；
- 是技術博客中出現圖片的意義；
- 圖片必須能夠在短時間內實現量產，不影響寫作的效率；
- 博客中的全部圖片都是在寫作的過程中一一繪制的，而不是最后統一完成的，所以會希望畫圖的時間可以盡量短，一旦畫圖的時間超過過長，那么整個思路就會被打斷；
- 博客的內容和邏輯相比于圖片更加重要，作者不希望在上面花費過長的時間；
- 圖片需要保證風格上的一致性，不會顯得非常突兀；
- 圖片的風格和配色對于作者來說就是簽名，形成統一的風格之后會給讀者留下比較深的印象；
這些準則也是作者這么多年總結下來的，也是在整理個人制圖規則時遵循的一些指南，在文章的剩余部分，你會看到作者在對于制圖方法和風格的變化和演進。
演進
博客中圖片的風格其實也不是一開始就像今天這樣的，現在博客中的大多數圖片都會使用使用 Sketch 進行繪制，圖片的風格非常統一、配色也高度一致：
不過在剛開始為博客制作流程圖的時候還會使用 OmniGraffle、Paper 等工具，到目前為止，除了 Sketch 和 LucidChart 之外的工具作者也都不再使用了，博客上絕大多數的圖片都是 Sketch 繪制的。
OmniGraffle
剛開始使用制作插圖時，作者還會使用 OmniGraffle 這樣的工具，它提供的功能其實比較強大，繪制流程圖、時序圖也非常方便，如果你對這個工具非常熟悉，也比較推薦使用它畫圖。
作者對于這個工具并不是特別熟悉，使用了一段時間還是覺得沒有 Sketch 來的順手，由于其本身的目的就是繪制流程圖、UML 圖，所以在設計上會對一些樣式做一些限制，如果覺得遵循這套限制是可以接受的話，使用 OmniGraffle 其實會有非常大的優勢，但是作者更希望減少工具的限制，所以最終還是選擇放棄了它。
Paper
除了 OmniGraffle 之外，在一兩年前作者還會使用 Paper 這種手繪的工具畫圖，使用 Paper 為博客畫插圖其實是一件比較耗費時間和精力的事情，但是這種風格的圖片確實非常有辨識度，作者在 Redis 和 I/O 多路復用 中就使用這種方式繪制插圖：
雖然手繪的插圖非常有辨識度并且 Paper 默認的風格其實也比較美觀，但是這種類型的插圖作者沒有辦法進行『量產』，而且每一張圖片都需要消耗比較多的時間，圖片的修改過程也比較麻煩，所以作者最終放棄了這種方法，不過手繪的方式確實是一種不一樣的體驗。
除了這種圖片需要較多時間、無法量產之外，前期的設備投入其實也比較大，如果想要使用 Paper 進行畫圖，iPad 和 Apple Pencil 基本上是必需品，如果不是特別熱衷于手繪的讀者并不建議使用這種方式。
LucidChart
LucidChart 其實就是用于繪制 UML 圖、流程圖的商業軟件，它其實就是 SaaS 版本的 OmniGraffle，但是與 OmniGraffle 相比，它提供的默認配色和樣式其實看起來非常美觀，哪怕是之前沒有經驗的人也可以比較容易的畫出優雅的流程圖，詳解 Kubernetes DaemonSet 的實現原理 中的圖片就都是通過 LucidChart 進行繪制的：
然而 LucidChart 其實是收費軟件，免費版限制了可以保存圖片的最大數量，作者購買了最低價格的套餐，一年的成本大概是 60$ 左右，價格相對來說還是比較貴的，不過非常適合經驗較少的博主。
國內其實也有一些比較類似的服務，例如 ProcessOn，但是它們提供的一些樣式和設計在作者看來相對 LucidChart 還是有一定距離，沒有達到作者心中對于圖片樣式要求的那根線，所以也不是特別推薦使用。
Sketch
最后要介紹的就是目前作者最常使用的工具 Sketch 了，相對于 Photoshop 來說比較簡單，它的場景也并不是對圖片進行處理，更偏向于一個 UI 設計工具，最開始使用 Sketch 也是作者的一個設計師朋友推薦的，不過目前來看 Sketch 其實已經成為了比較常用的設計工具。
Sketch 對于 UI 設計是非常友好的，它也提供了非常多的插件，相比于更專業的 Photoshop 也沒有那么復雜，使用它的一些最基本功能就完成高度定制的插圖，作為一個相對來說比較專業并且自由的工具，作者目前在日常工作中經常會使用 Sketch 來處理和創作一些圖片和插圖。
畫圖
在這一節中，作者將介紹為技術博客繪制圖片時總結的一些經驗，希望幫助各位讀者找到自己的制圖風格，為技術文章繪制圖片和使用 PS 修改圖片、為 App 繪制 UI 設計圖是完全不同的，技術文章的配圖主要作用還是為了輔助說明內容，圖畫的再好看如果不能很好地解釋問題都沒有太多的作用，相比于圖片的樣式，我們應該更加關注圖片的內容是否清晰和簡單。
內容
正如我們上面所介紹的，圖片的內容是配圖時至關重要的，作者在一個問題太過復雜或者連續的文字過多時，就會選擇為文章插入適合的圖片，內容作為博客中插圖的核心，我們需要清楚地知道需要表達什么，作者將博客中的圖片簡單的分成了以下三類分別用于描述和展示不同的內容：
- 用于展示多個平等的概念時；
- 用于描述模塊以及概念之間的關系時；
- 用于描述特定場景下概念的特性時；
在需要展示某個問題的多個方面、多個原因或者階段等處于相同層次的概念時就會使用如下所示的圖片：
這張圖片介紹了選擇版本控制系統時應該關注的三個特性：分布式、性能和可靠性，使用列表的方式也是沒有問題的，這只是作者的配圖習慣，而你在這篇文章稍微靠前的部分中也會看到用于展示繪圖工具的插圖，這些圖片的內容類型都是相似的。
除了展示概念的配圖之外，作者還會使用如下所示的圖片來展示不同概念或者模塊之間的關系，流程圖、架構圖等類型的圖片都會被作者歸到這一類中：
上述圖片展示了在分布式的版本控制系統中，各個倉庫之間的樹形結構，圖中使用不同的顏色將不同倉庫在樹中的高度做出了區分，這種圖片能夠很好地幫助讀者理解各個模塊之間的關系，我們在 LucidChart 一節中分享的圖片其實也屬于這種類型的圖片，只是使用的工具不同：
除了這兩種比較常見的插圖類型之外，作者在遇到一些特殊問題時也會選擇通過圖片幫助讀者理解問題，例如 為什么 DNS 使用 UDP 協議 中就使用了如下所示的圖片：
這張巨型圖片的主要作用就是幫助讀者理解 DNS 協議使用 TCP 或者 UDP 獲取域名解析時所需要傳輸數據的大小，通過這張圖片我們能夠比較直觀的了解不同協議在處理 DNS 協議時在數據方面的差別。
樣式
圖片的內容是它的核心價值所在，而圖片的樣式是決定圖片是否『優雅』的關鍵，內容和樣式之間的關系，就是 Web 前端中 HTML 和 CSS 的關系一樣，我們在這一節中就詳細介紹作者對于博客中圖片樣式的一些約定。
配色
圖片的配色其實非常重要，它決定了整個圖片從第一眼看過去給人的感覺，如果一個博客的配色你使用了非常長的時間，這也會成為你的標志。
每次看到其他博客中有相同配色的圖片時，都會點進去看一下，大多數博客的博主都會把圖片上的水印去掉并且不加引用，對于這種行為作者也不多評論，我只是希望各位讀者在使用圖片時能夠在圖片上或者文章末尾增加引用。
作者在最開始畫圖時都會使用不同的配色方案，但是大多數的配色如果長時間使用并且每天接觸確實會有一定的審美疲勞，這時就會選擇進行更換，你可以在通過下面的鏈接在歷史的博客中查看作者使用過的配色方案：
你可以看到作者在三年前使用的配色和畫圖方式與今天完全不同，這也是作者在實踐的過程中不斷進行的修正，關于配色選擇可以通過一些在線的網站獲取，你可以使用 Coolors 這一服務生成你的配色，作者之前就是用過這一服務，選擇配色時一定要使用相對較為和諧的配色，至于是否和諧就依賴各位讀者自己的審美了。
圖片長寬
很多平臺其實會限制博客的頭圖或者封面的長寬比例，比如微信公眾號，這種時候我們就只能接受平臺的設定，不過對于其他圖片的長寬，我們只需要注意兩個比較關鍵的問題：
- 保證圖片的寬度一定，長度不要太長；
- 保證圖片的大小被合理利用；
因為大多數人在閱讀博客時都會使用顯示器，這個時候過長的圖片會影響顯示效果，很可能一頁沒有辦法展示全部的內容，這會非常影響閱讀的體驗，所以我們可以固定圖片的寬度，目前作者博客的圖片寬度都是 1200px，這個值的選擇與使用的平臺和博客引擎都有關系，各位讀者可以按需選擇。
對于一張圖片自然是越清晰越好，但是大圖片會消耗較多的下載資源，如果使用 CDN 服務來加速圖片的分發，這其實會影響博客的運維成本，你的支出會與博客的訪問量成正比，所以選擇的時候也應該量力而行。
字號
接下來我們簡單介紹一下字號的選擇，對于字號大小的選擇，我只能說要根據情況進行，不過作者一般會遵守以下的兩個規則（在寬度為 1200px 的圖片中），如果圖片的大小改變，字號也會相應增減：
- 圖片標題的字號
31px； - 圖片非標題的字號
18~20px；
當然我們不能排除一些極端的情況，比如文字過長或者過多，遇到這種問題時會首先考慮減少文字的數量和長度，如果無法解決再縮小字號，保證圖片中文字的正常顯示。
圓角
圓角其實是一個非常有意思的設計，作者在圖片中基本不會使用直角的矩形，出現在圖片中的形狀都是圓形或者圓角矩形，所以對于圓角矩形也需要選擇合適的圓角。根據歷史的一些經驗，作者一般會選擇 15px 以下的圓角，盡可能地保證圓角不會太大也不太小，看起來相對比較柔和。
總結
希望在這篇文章之后不會有人再問『你的圖片是用什么畫的』，因為使用什么工具并不重要，之前微博上有一個評論我覺得說得特別對也特別好：
畫圖的工具并不重要，重要的其實是你應該如何形成自己的規則體系，想要為博客配圖并不是一件困難的事情，比較困難的是長期堅持并且經常思考，對自己形成的規則不斷改善，最終就一定能夠做好。
假如你讀到這里并且想要獲得這篇文章中的 Sketch 文件，可以關注『真沒什么邏輯』公眾號并回復 Sketch，你會得到一份 Sketch 的源文件，其中包含了這篇文章中的一些插圖；如果有意愿的話，相信從這個源文件開始你就可以構建自己的規則了，也希望各位讀者能夠從這篇文章中有所收獲并遇到和我一樣的問題，而我也能從相同的問題中解脫（不太可能）。
