共计 4296 个字符，预计需要花费 11 分钟才能阅读完成。
上篇 《博客零碎知多少：揭秘那些鲜为人知的学识（三）》 介绍了博客协定或规范。本篇终章介绍设计博客零碎有哪些知识点。
因为文章篇幅较长，本文将分为 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，获取更多微软一手技术信息和官网学习材料！
