? ?點擊上方關注“汪宇杰博客” ^_^

上篇《博客系統知多少：揭秘那些不為人知的學問（三）》介紹了博客協議或標準。本篇終章介紹設計博客系統有哪些知識點。

1.“博客”的前世今生

2.我的博客故事

3.誰是博客的受眾？

4. 博客基本功能設計要點

????4.1 文章（Post）

????4.2 評論（Comment）

????4.3 分類（Category）

????4.4 標簽（Tag）

????4.5 歸檔（Archive）

????4.6 頁面（Page）

????4.7 訂閱

????4.8 版本控制

????4.9 主題及個性化

????4.10 用戶及權限

????4.11 插件

????4.12 圖片及附件的處理

????4.13 敏感過濾及評論審查

????4.14 靜態化

????4.15 通知系統

5. 博客協議或標準

????5.1 RSS

????5.2 ATOM

????5.3 OPML

????5.4 APML

????5.5 FOAF

????5.6 BlogML

????5.7 Open Search

????5.8 Pingback

????5.9 Trackback

????5.10 MetaWeblog

????5.11 RSD

????5.12 閱讀器視圖

6. 設計博客系統有哪些知識點

??? 6.1 時區真的全用UTC？

????6.2 HTML還是Markdown

????6.3 MVC還是SPA

????6.4 安全

7. 結束語

6.1 |?時區真的全用UTC？

存儲時間使用UTC在2020年應該已經是猿盡皆知的實踐了，博客系統其實也是如此，我的博客所有時間數據最終保存都采用UTC時間。但博客有個特殊的地方，即它不應該按讀者的時區去轉換UTC時間進行顯示，而應該按照博客作者的時區去顯示時間。

這并不是技術上的原因，就算你按讀者時區去顯示時間也不會有代碼爆炸，原因在于博客的誕生初衷，就是為了彰顯個性，讓博主在互聯網上有自己的展示空間，因此突出博主本人的屬性非常重要，博主所在時區也是個讓讀者了解博主的屬性之一，因此，正宗的博客系統都會給一個時區設置選項，并以此轉換UTC時間作為顯示，WordPress和我的Moonglade博客系統均是如此。博客系統不自動轉換讀者所在時區的時間，純粹就是個鮮為人知的情懷設計，但必須得尊重。

(圖：Moonglade 按博主設置的時區顯示文章發表時間)

那么有意思的事情來了，搜索引擎要怎么理解博客文章的時間？最好將UTC時間僅告訴搜索引擎，不要給用戶顯示，方法也很簡單，用HTML5的time標簽的datetime屬性即可。在HTML5標準推廣以后，搜索引擎更喜歡看標簽類型來判斷內容的含義，而不是根據標簽里的內容來猜意思。

在C#里，ToString(“u”)指的是Universal sortable date/time patter。

<time datetime="@Model.PostModel.PubDateUtc.ToString("u")" title="GMT @Model.PostModel.PubDateUtc">@DateTimeResolver.GetDateTimeWithUserTZone(Model.PostModel.PubDateUtc).ToString("MM/dd/yyyy")</time>

對于剛才截圖里的文章，時間的HTML為：

<time datetime="2020-04-29 11:41:02Z" title="GMT 4/29/2020 11:41:02 AM">04/29/2020</time>

6.2丨HTML還是Markdown

許多技術人士編寫博客系統的時候喜歡選用Markdown作為編輯器，如果單純只是個技術博客，自己使用并沒有什么問題。但如果你在給他人編寫博客系統，請記住，不是每個人，都是程序員，不是每個人，都喜歡Markdown。

圖 | 網絡

在這種情況下，一個WSIWYG的HTML編輯器（如TinyMCE）是不錯的選擇，HTML編輯器相對Markdown也支持更高級的排版方式。Moonglade 同時支持HTML和Markdown編輯器。

（圖：Moonglade 使用的TinyMCE編輯器）

保存文章內容到數據庫時，Markdown格式需要選擇原始內容，而非生成的HTML，因為還需要支持后續編輯。HTML格式現在也不建議encoding存儲，畢竟都已經2020年了，市面上的主流數據庫都可以正確支持各種神奇的Unicode，比如文章中突然出現個emoji????，而如果你使用了encoding，就會像我的博客一樣面臨一些福報：https://github.com/EdiWang/Moonglade/issues/280。并且encoding和decoding的過程會影響性能。我的Moonglade博客系統也剛剛完成了去除encoding的改造。

6.3丨MVC還是SPA

許多社區里寫博客系統的程序員都偏向于使用SPA架構建博客，而鄙視用MVC，覺得落后，真的是這樣嗎？這個問題就像是飛機為什么不飛直線，是航空公司不會規劃嗎？關于這一點，我曾經在以前的博客文章《我的 .NET Core 博客性能優化經驗總結》中寫過：

2014年以后，隨著SPA的興起，Angular等框架逐漸成為了前端開發的主流。它們解決的問題正是提升前端的響應度，讓Web應用盡量接近本地原生應用的體驗。我也面臨過不少朋友的質疑：為什么你的博客不用angular寫？是你不擅長嗎？

圖 | 網絡

其實并不是那么簡單。實際上我任職的崗位的目前主要工作內容也是寫angular，博客曾經的.NET Framework版的后臺也用過angularjs以及angular2，經過一系列的實踐表明，我博客這樣的內容站用angular收益并不大。

其實這并不奇怪，在盲目選擇框架之前，我們得注意一個前提條件：SPA框架所針對的，其實是Web應用。而應用的意思是重交互，即像Azure Portal或Outlook郵箱那樣，目的是把網頁當應用程來開發，這時候SPA不僅能提升用戶體驗，也能降低開發成本，何樂而不為？但是博客屬于內容為主的網站，不是應用，要說應用也勉強只能說博客的后臺管理可以是應用。博客前臺唯一的交互就是評論、搜索，因此SPA并不適合這樣的工作。這就像你要去菜場買菜，騎自行車反而比你開個坦克過去方便。

在微軟官方文檔里也有同樣的關于何時選擇SPA，何時選擇傳統網站的參考：

https://docs.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/choose-between-traditional-web-and-single-page-apps?

博客前臺仍然選用MVC的另一個原因，請回顧一下本文開頭“博客的讀者是誰”，我運營博客十余年，統計的數據表明，幾乎所有的用戶都來源于搜索引擎，都只點進來看一篇文章，然后關閉網頁。現在仔細想想，SPA解決的最大的問題之一是什么？是不是通過只刷新局部來提高前端性能（可響應度）？而用戶從搜索引擎過來，只看一篇文章就關閉網頁，真的用得到SPA只刷新局部的優勢嗎？用戶只看一篇文章，你用個SPA框架，用戶得加載一堆框架本身的文件，其中包括導航、交互等功能，而99%的用戶根本就不會點到別的地方去，于是你只為了1%的用戶，去加載碩大的一個框架，值得嗎？這性能到底是提高了，還是降低了？

MVC框架雖然每次都會輸出服務器端渲染的完整HTML，但由于99%的用戶只看一篇文章就關閉網頁，所以對于99%的用戶來說，他們所需要加載的資源，遠小于加載一套SPA，速度更快，還更SEO友好。SPA適合用在博客的后臺管理portal，而不是前臺。

6.4丨安全

根據運營博客多年的后臺監控數據，最常見的攻擊行為是全自動的漏洞掃描工具。他們會請求例如 data.zip, wp-admin.php, git目錄等常見的安全疏忽，或是想要通過某些博客系統的已知漏洞進行攻擊。目的是為了控制服務器，在你的博客網頁里加入對用戶的惡意代碼（例如勒索病毒、挖礦）等，有些也會將服務器本身變成礦機。

（圖：Azure后臺捕獲的自動化掃描工具請求）

設計博客系統時，常用的安全對策可參考OWASP（https://owasp.org/），但同時保留靈活性。例如，加入JavaScript的CSP時，請考慮正常博客用戶可能需要添加三方統計插件（如Azure Application Insights，國內的CNZZ等），請設計一定的黑、白名單或功能開關。

大部分設計者都知道要防范用戶的輸入，即博客的讀者，輸入的入口通常只有評論和搜索功能。但不要忘了，博主在博客后臺管理中的輸入也需要防范，因為不一定是博主本人在操作。舉個例子，博主的賬號被盜，黑客在后臺將導航欄的鏈接指向黑客的服務器或localhost上早已準備好的奇妙的機關（是的，不要以為localhost在正常人的電腦上不起作用），那么讀者就會受到嚴重影響。

圖 | 網絡

關于后臺登錄的身份認證，能采用成熟的SSO的就優先采用SSO，例如Moonglade支持Azure Active Directory驗證，這樣能夠利用微軟這樣的專業服務管理授權認證，盡可能小的避免賬戶上產生安全問題。如果用戶沒有SSO的環境，才fallback到本地賬號認證。千萬不要認為用三方服務沒自己寫安全，覺得自己寫的邏輯沒人知道就不會被黑了，除非你是世界頂級大牛，不然自己寫的系統易黑程度遠高于三方服務。

另有一些攻擊通常由一些敵對陣營的無聊程序員發起，例如使用腳本或工具持續不斷的請求博客系統的某個URL，企圖像DDOS那樣擊爆服務器，對于這種無聊刷刷黨，博客系統設計者只要加入有關URL endpoint的rate limit即可。對于真實的DDOS攻擊，只有云端抗DDOS服務或硬件DDOS防火墻才能解決。

最后別忘了OWASP里沒有的東西，博客的協議也會有設計缺陷，例如pingback可以用來DDOS（https://www.imperva.com/blog/wordpress-security-alert-pingback-ddos/），也能掃描服務器端口（https://www.avsecurity.in/wordpress-xml-rpc-pingback-vulnerability/）

結束語

設計一個優秀的博客系統，每一處細節都值得斟酌。這些設計絕對不可能一開始就能做對，而是得靠長期運營博客的數據去發現并思考。并且，市場會變化，用戶行為會變化，標準會被淘汰，也會被發明，因此你的系統需要跟著進化。

任何看似簡單的系統，就算普通到爛大街，也有背后看不見的一套完整體系。博客如此，電子商城、外賣、金融清算系統更是復雜，不要光憑自己表面看到的就開始做。就如同造飛機，造個紙飛機和真飛機，絕對不是一回事。

技術人員也不要覺得什么流行就得用什么，優秀的產品并不是堆砌時髦技術做出來的，而先得分析你的用戶到底是怎么用你的產品，才能做最合適的選擇。要記住，想要一件事情做成功，思路不要只局限于技術本身，學會分析市場，用戶行為，才能更準確的選擇和應用技術。

圖 | 網絡

感謝讀到這里的讀者，如果大家有什么疑問和討論，歡迎留言交流。

喜歡本篇內容請點個在看

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的博客系统知多少：揭秘那些不为人知的学问（四）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。