上篇《博客零碎知多少：揭秘那些鲜为人知的学识（三）》介绍了博客协定或规范。本篇终章介绍设计博客零碎有哪些知识点。
因为文章篇幅较长，本文将分为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.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.1 时区真的全用UTC？
6.2 HTML还是Markdown
6.3 MVC还是SPA
6.4 平安 - 结束语
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/Mo...。并且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...
博客前台依然选用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/...），
也能扫描服务器端口（https://www.avsecurity.in/wor...）
结束语
设计一个优良的博客零碎，每一处细节都值得斟酌。这些设计相对不可能一开始就能做对，而是得靠长期经营博客的数据去发现并思考。并且，市场会变动，用户行为会变动，规范会被淘汰，也会被创造，因而你的零碎须要跟着进化。
任何看似简略的零碎，就算一般到烂大巷，也有背地看不见的一套残缺体系。博客如此，电子商城、外卖、金融清理零碎更是简单，不要光凭本人外表看到的就开始做。就如同造飞机，造个纸飞机和真飞机，相对不是一回事。
技术人员也不要感觉什么风行就得用什么，优良的产品并不是堆砌时尚技术做进去的，而先得剖析你的用户到底是怎么用你的产品，能力做最合适的抉择。要记住，想要一件事件做胜利，思路不要只局限于技术自身，学会剖析市场，用户行为，能力更精确的抉择和利用技术。
图 | 网络
感激读到这里的读者，如果大家有什么疑难和探讨，欢送留言交换。
扫码关注微软中国MSDN，获取更多微软一手技术信息和官网学习材料！