从一开始写博客开始，我就不断地更换博客生成器，先是Jekyll，然后是Hexo，之后用了一年的Hugo，因为数学公式渲染的问题又回到Jekyll。终于我忍不住了，自己写（不如说是组装）了一个博客生成器——sushi。
之前多次更换生成器，有时是因为盲从（比如从Hexo换成Hugo），有时是因为喜欢的主题只能用于另一个生成器（比如从Jekyll换成Hexo），不过更多时候是因为不顺手。对于其他生成器来说来说，我一直没法解决使用相对路径插图的问题，也没法解决生成期间渲染KaTeX公式的问题。Jekyll因为一些奇奇怪怪的原因在本地没法使用，并且我不熟悉Ruby，也不想花太多精力学习，一直没有能力排查。终于到了上个月，我终于受不了缓慢的数学公式加载、极不顺手的插图方式，决定自己写一个生成器。肝了几周之后终于组装出了sushi。
虽然sushi还存在一些问题，但我想我不会再迁移了，因为sushi的定制难度要低于我用过的其他生成器。下面几点是sushi已经实现的设计目标：
- 渲染器（converter）由用户指定，而且由用户提供。用户把渲染器的可执行文件放到一个文件夹中，然后在配置文件中指定那些文件使用那个渲染器。这使得使用pandoc非常容易，我可以用tex写博客，也可以用markdown，或者别的pandoc支持的语言。借助pandoc
filter，我还能实现KaTeX公式的静态渲染，大大提高了页面的加载速度。
对我而言，Hugo最大的问题就是和Goldmark绑定，对其他渲染器的支持不佳，导致我不能自定义markdown语法。 - 不改变站点的结构。比方说一个文件在
posts/aaa/test文件夹里面，那么无论它是什么文件，在生成的站点中，sushi会确保它依然在这个位置。这点使得我可以随心所欲地使用相对路径，不会有奇奇怪怪的插图问题。 - 使用liquid模板语言，但是无视博文中出现的liquid标签。
- 支持自定义的分类法（taxonomy）
- 不区分所谓“post”和普通的页面文件。站点结构除了少数几个配置相关的文件夹和文件之外，完全由用户自定义
这几点总结起来，就是sushi不管生成方式、部署方式、主题，只管按要求“套模板”。使得sushi的可定制性优于其他生成器。当然这也式sushi也存在一些问题：
- 几乎没有默认配置，所有东西都需要自定义，没有默认主题。即使你使用starter，也无法避免自己配置一些东西
- 因为使用了用户提供的渲染器，因此如果你和我一样给pandoc加了各种各样的filter，那么站点的生成速度会比较慢
- 没有“一键部署”，部署博客需要自己写脚本。（比如说可以自己写Makefile）
- 虽然跨平台，但是因为需要用户提供可执行文件作为converter，因此跨平台体验很一般。
- 也许存在一些没有被发现的bug。
- 分页器虽然能用，但是不太好用
- 虽然标榜可定制性，但是几个默认的配置文件夹和配置文件不允许改名
但是上述问题我一点都不在意。我更关心“能否轻松自定义”，不太关心能否开箱即用。因为个人博客的页面数量不多，我觉得hugo的那种速度没有必要的。跨平台问题并不难解决。分页器难用，但其实并不需要经常用。因为测试不是太彻底，因此可能有一些bug，但是我会持续进行维护，如果有bug也欢迎到github仓库提交issue或者PR。
综上，sushi对我而言就是完美的博客生成器了（毕竟是自己写的）。如果你和我有相似的需求，我强烈推荐使用sushi（虽然目前sushi只有我写的两个主题（letter和empty，如果不喜欢，你可能得自己写主题）。
Blog的迁移之路，终于到了一个终点……
ps. 关于我的生成器的起名，我觉得「苏轼」很符合博客的气质，而且「sushi」容易发音，如果加上音调，变成sūshì，也不会和「寿司」相混，于是就这样定下来了。不过很可惜gnome有个命令行工具也叫
sushi，因此我不得已把命令改成了ssushi。crates.io上已经有sushi这个crate了，我改名成ssushi又不利于搜索，所以最终，在crates.io上，我这个项目名为sushi-gen。