最近看博客后台，纠结了一下内容字段的设计。写篇小文记录一下思考过程。
背景
博客后台一开始设计的是双轨制：一个 format 字段区分 markdown 和 richtext，对应两个编辑器、两个存储字段 body_md 和 body_html。当时想的是"兼收并蓄"，让我根据自己的习惯选择。
遇到的问题
首先是维护成本。两种格式意味着两套解析逻辑、两套渲染逻辑、两套校验规则。每次改需求都要同时改两边的代码，测试也要跑两遍。
其次是选择困难。每次写文章都要纠结一下：今天用哪个？Markdown 写技术文章比较顺手，但偶尔想插入一个复杂表格，富文本更方便。然后就陷入了"这个选择有意义吗"的自我怀疑。
最后是数据一致性。两种格式怎么同步？用户切换格式怎么办？历史数据要不要迁移？这些问题加起来比业务逻辑还复杂。
Markdown 其实够用了
仔细想想，博客这种内容形式，其实不需要那么多花里胡哨的格式。
标题、列表、代码块、图片、链接、引用，这些覆盖了 90% 的写作场景。剩下的 10% 是什么？可能是稍微复杂一点的表格，或者是多栏布局。但说实话，博客文章搞那么多花样，反而影响阅读体验。
作为程序员，Markdown 是天然的选择。写代码注释、写文档、写 Git 提交信息都是这一套语法，保持一致性挺好。
至于"所见即所得"的体验，EasyMDE 这类编辑器已经做得很好了。左边写、右边预览，实时看到效果，跟富文本编辑器的体验差距不大。
# 示例
这是一个代码块
const hello = 'world';
而且纯文本格式有个隐藏的好处：版本控制友好。哪天想迁移到别的平台，直接把 Markdown 文本搬过去就行，不用担心格式丢失或者解析出错。
决定
最后还是把富文本这条路砍掉了。只留 Markdown，一个字段 body_md，一个解析器。
前台渲染的时候用 Parsedown 或者类似库把 Markdown 转成 HTML，缓存起来。数据库里只存一份原始文本，干净利落。
以后如果有人吐槽"我不会用 Markdown"，再说。现在的目标用户主要是自己，先把代码写利索了。
