从今年 5 月算到现在，我的博客已经创建整整半年时间了。虽然搭建一个博客谈不上有什么难度，但自己的网站就是用来折腾的，所以博客背后的引擎也在这半年时间里也更换过好几次了。在这里，我把自己使用各种博客技术框架的经历和自己的一些心得体会记录下来，希望能对同样想自己搭建博客的同学有所参考吧。

Wordpress

毫无疑问这是全世界最知名的博客引擎。在建站之初，我并未打算花太多时间去自己编写一个博客，所以用市面上现成的、最流行的方案也是一个情理之中的选择了。

我自己对 PHP 并没有任何经验（也不喜欢它）。从使用经验看，基于 PHP 的方案恐怕最有吸引力的应该就是：部署网站就是一个简单的 copy 动作，不涉及任何服务器的停止和重启。这个特性应该是很讨好空间提供商和没有程序员背景的普通用户的，毕竟对这些用户来说，自己管理服务器存在着不小的门槛。但另一方面，程序员对它可能就没有太大感觉了。

Wordpress 作为博客引擎本身已经比较完善了，不过更深入的功能很多还是要依赖于第三方插件的，当然，Wordpress 也有着非常广大的插件市场。有很多插件的确让博客更加完善了，但也带来了一些恼人的问题：

• 插件质量良莠不齐，有些安装之后会出现一些莫名其妙的问题；
• 很多插件功能类似，评价、甚至名字都差不多，不知道该选哪个，只能自己一个个去尝试；
• 有些插件功能不错，但看更新时间已经很旧，能否正常工作挺让人担心的；
• 插件多了以后，需要升级的情况也更加频繁出现。隔三岔五的跳出来着实挺烦人的；
• 升级插件以后有时会把一些自定义的修改直接覆盖掉；
• 有些插件明显有刷榜的嫌疑；
• 有很多插件还需要收费。付费并不是大问题，然而要对零散的小功能分别去支付就不是多么愉快的事情了；

当然，上述现象在其他类似的应用市场大体上也都是存在的。然而对于博客这样一个算不上太复杂的网站，并且自己也是程序员，面临这种局面就让人不舒服了。或许只是改动几行代码的工作，却要依赖于你不知道是否值得信任的第三方，还不知道什么时候能够解决。Wordpress 插件市场看起来也不像 Apple Store 那样有很严格的管理。

此外，有一些功能方面的定制还是需要自己修改 PHP 代码。我个人对 PHP 并无好感，如果一定要自己写代码的话，那我干嘛不自己撸一个？ 于是，在使用 Wordpress 大概一个多月后，我开始寻找其他的解决方案。

Hexo

Hexo 截然不同的地方在于它是一个静态网站生成器。用静态网站完全免去了自己编写程序和升级的麻烦，还不必担心性能和安全问题，当然缺点就是很难实现动态交互了。我的确看到有一些项目在探索突破静态限制的可能性，不过认真的说，这些要求已经超过静态网站的能力范围了，如果当真需要很多交互功能的话，那还是考虑动态网站吧。

我在使用 Wordpress 的时候发现，虽然 WP 有评论功能，但开始的时候引来的大多数是广告和垃圾贴（当然是因为访问量太小啦）。所以这时我考虑的主要问题是：既然动态功能没有用还增加了垃圾内容，那干脆完全禁止掉好了。Hexo 正好符合我的要求。同类的静态网站生成器基本上大多数主流编程语言都有，Hexo 可能是其中最流行的，并且用户口碑也很好，于是我选择了它。

Hexo 在部署方面可以说是简化到了极致。在配置好以后，要执行部署基本上只需要执行：

hexo d -g

发帖和管理的工作也相当简单。另外，Hexo 还倡导一个（我认为）非常优秀的思路，那就是用 Markdown 撰写内容。Wordpress 使用的是富文本编辑器，直观是直观了，不过生成的 HTML 比较啰嗦，而且容易产生一些冗余的标签，想要精确控制内容和格式有时候比较困难。Hexo 的默认主题也是非常朴素大方的（我现在的博客也继承了这个主题）。

总之，从功能方面说，我对 Hexo 是非常满意的。不满意的地方在于，使用久了，我还是会想念动态网站的灵活性，比如想要增加一些统计、跟踪和分析的功能，这是静态网站无法实现的。虽然可以引入一些第三方的方案，但外部的工具无论如何都不如自己后台的数据来的准确和详实。

如果你自己不是程序员，不希望花精力去学习编写代码；又或者你自己是程序员，但对博客的要求只是一个写文章的地方，那么 Hexo 是非常值得你考虑的，这是一个足够简单且高效的方案。但假如你希望拥有的不只是一些静态内容的集合，而是一个有自己的功能、能够管理和维护的网站，则 Hexo 是无法满足你的，你还要继续前进（像我一样）。

使用 Hexo 的另外一种形式是把内容发布到支持的网站上去，最著名的就是 Github Pages 了。其他诸如 GitLab，以及国内的码云、Coding 也有类似的功能。这样的好处是不但不用自己创建网站，连寻找托管空间的工夫都可以省去了。然而，这同时也意味着你的内容也不再完全属于自己，而是需要和托管方分享了。这未必是什么大问题，但你要是想这样做的话，还是应当认真考虑一下是否会带来潜在的问题，毕竟天下没有免费的午餐。最终的决定权在你自己。

Flask

在从 Hexo 迁移的过程中，我做出了两个决定。一个是网站必须是动态的；另外一个是基础语言不用我自己更加熟悉的 Java/C#，而是用 Python。具体的思考过程这里就不展开了，既然用 Python，那么 Web 框架基本上就是从 Flask 和 Django 二者选一了。

我最初的选择是 Flask。Flask 的设计哲学是小而美，这更加贴近我的思想，并且 Flask 自身的设计也有很多可圈可点的地方。我基本已经用 Flask 写出一个完整的博客网站了，但最后我放弃了。为什么呢？

Flask 在设计上有一个比较怪异的地方在于，为了定义 URL 路由，在 定义 app 或 blueprint 之后需要继续定义视图函数；而视图函数又需要引用前面定义的 app 或 blueprint。听起来没有什么，但当模块拆分的时候代码顺序就特别重要，否则就容易出现循环引用，或者看到意味不明的 Import error。当然这个问题只要小心的话就可以避免，然而我特别不喜欢这种强制代码顺序的设计风格。后面将说到的 Django 应该是注意到了这个问题，所以在配置中统一以模块的字符串形式作为参数而不是使用强引用，从而不需要程序员去过分关注代码的定义顺序。

另外一个问题在于 Flask 的 URL 只能通过 Blueprint 来划分，实际上在比较大的程序中 URL 地址经常需要多级结构，而 Blueprint 却是不可嵌套的。这个问题在官网和 Stackoverflow 也有人问过，然而并没有官方的解决方案，只有一些 Hack 手段，参见 Stackoverflow 以及 Github Issue。当然自己为每个地址加上前缀也不是不行，不过那样也太不 DRY 了...

最后一个不大不小的问题是，网站中难免有一些无聊的 CRUD 工作，自己实现也没有问题，但是用 Django 的话可以为你节约大量工作。当发现这一点以后，我就开始转向下面的方向。

总结：虽然我自己放弃了用 Flask 搭建博客的打算，但是这并不意味着此路不通（网上也有不少用 Flask 搭建博客的教程），只是我对这个框架的某些部分不太喜欢而已，并不是无法克服的问题。我自己平时也会用 Flask 来创建一些临时性的网站用于测试某些功能。这种任务用 Java/C# 以及 Django 的话，动辄要创建一个完整的项目，太过于重量级了。而 Flask 则只需要单个文件、10 几行代码就能跑起来，快捷方便的多。

Django

和 Flask 的风格相反， Django 走的是大而全的一站式路线。这使得我开始的时候不太喜欢它 而更加倾向于 Flask。然而深入了解以后才发现， Django 的可定制性还是比较强的，并且内置的 Admin 能节省大量重复性的工作（虽然界面算不上好看，对于个人站点的后台管理这个问题不重要）。目前的网站就是基于 Django 架设的，编写过程很愉快，没有遇到什么重大的痛点。相信目前这个架构足够使用相当一段时间了。

使用 Django 是一种比较不同的体验。这是因为大部分事情框架都已经为你考虑到了，自己需要编写的代码并不多，大多数时间是在熟悉框架提供的各种机制以及调用方法，并且 Django 的体系结构确实也比较复杂。有的同学可能会不喜欢这种受限制的感觉，然而按照我自己的体会来看，Django 的设置总体上来说都是比较合理的。有些文章也提到 Django 的一体化思路并不符合当下微服务的潮流，这应当是真的，Django 的各部分的确难以拆分。不过对于个人网站来说，用微服务显然是大材小用了，Django 在这种场合下还是很好的选择。

Django 也不是没有缺点。我最不喜欢的是它的 Template，这种模板可能是为了防止设计人员出错，设计比较简陋和怪异，不太符合程序员的习惯。相比之下，Flask 的 Jinja2 引擎要顺眼的多。目前 Django 也允许程序员使用 Jinja2，不过需要自己去配置一些东西，并且在调试方面也不如内置的模板集成度高。我的网站在前台部分也使用 Jinja2 作为默认的模板引擎。另外值得一提的是，Django 版本变更还是比较频繁的，以前一些基于 1.8 之前的代码，到 1.11 版本就未必适用了，但网上的很多文章没有特意去注明使用的版本，这是你需要多加小心的。

最后多说两句。有同学说 Flask 适合入门，因为简单，上手快。但我的经验告诉我这个结论可能是有欺骗性的。因为 Flask 是个微框架，自身除了路由和模板之外没有多少功能，要完成一个完整的网站的话还要额外学习不少插件，这样一圈折腾下来花费的代价未必会比 Django 少多少。常用的那些如 Flask-Script，Flask-SqlAlchemy，Flask-Login 等核心插件质量是有保证的，然而其他插件就未必了。我的看法是，对于初学者，Django 是更好的选择。那些所谓框架的限制，对初学者而言其实是有引导意义的，并不是什么坏事。对于真正的专家而言，Flask 会有更大的自由度——然而那也是等你已经有足够扎实的基础以后的事情了。

PS: 就在写这篇文章时，我才发现 Flask 的官方网站还是 HTTP，而 Django 已经启用 HTTPS 了。也许 Flask 的作者觉得自己的网站都是静态内容没有什么被黑的价值吧。不过我还是在心里暗暗为 Django 点了一个 +1。