起因是我希望搭建一个Blog系统，又不想再去麻烦的配置服务器，所以采用了Github Pages作为空间。原本是希望用Jekyll，但阴差阳错的选择了Hexo，于是爬坑之旅开始了。
首先还是肯定下，hexo整体比较稳定。但缺点也比较明显，主要集中在一下几点上面：
Bug吐槽
依赖顺序
这个问题是我所料未及的，Hexo的package.json的dependencies是需要有明确的先后指向的（集中在generator相关的组件上），因为这个让我一度很绝望。
事后我仔细阅读了hexo的代码，发现hexo对象有个generator列表用来处理整个项目生成器，项目本身使用了key-value的键值对形式。
这个设计本身存在了一定的漏洞，众所周知键值对形式的顺序是不可控的。这本来问题不大，hexo内部区分页面为page、post、categories、tags这几种页面类型，每种类型应该只需要一种generator就可以，所以，不应该存在逻辑上的冲突。
但是命运就是如此的巧合，hexo本身对于generator没有使用特别严格的类型限制，所以当存在两个同类型生成器的时候，就存在的一个顺序执行的问题，而这在键值对形式中是允许的，所以我所遇到的问题就变成了个让人纠结的问题。
多语言切换
hexo官方推荐hexo-i18n插件，用于处理多语言情况。但很不幸，这个插件处理的是识别多语言状态，并生成，但无法切换！！！而恰恰在开发时我需要用到的是个多语言切换站点，这不光是index页面需要针对语言进行文章列表的显示，针对categories、tags也都需要进行相应的识别。更关键的是在任意一个页面还需要能切换到另一个语言状态中，比如英文版tags——>中文版tags。
这里我强烈推荐一个插件hexo-generator-basic-set，这个插件可以非常两个良好的解决多语言文档的生成问题。当然这个插件需要针对同一片blog分别写多语言版本的内容，目前存在一种bug就是如果你只写了中文版本，英文版如果空缺，是无法自动生成类似404的切换页面的。
异常处理
这个算是无奈，本身hexo的基础是建立一套静态网页文件。所以不存在路由管理也就无法处理404这样的请求。这在单语言blog时问题不大，不会出现死链之类的情况（最多出现错链的时候会异常）。
但是在多语言状态，特别是某篇文章我不需要多语言的时候就会存在比较复杂的处理。
##总结
要修复上面的问题，需要延伸比较多的插件，并修改hexo的核心代码，建立页面、内容之间的关联关系。可以说这有点违背了简洁、快速的原则。
所以处理完这个模板，我果断开了个项目，基于jShow开源框架的衍生项目，致力于快速简单的搭建md文件静态网站（当然现在处于私有项目状态，后期会开源）