Part 1 : 个人博客断舍离

这件事情并非一时兴起，我有深思熟虑过很长一段时间。

为什么断舍离

有人喜欢收集车票电影票，还要把这些东西拍照留存，真是活在一堆过去的麻烦中啊。不懂得精简和丢弃的人，会被过去拖累，会身心疲惫。东西越多越不知道自己真正想要的是什么。

有一句话我深以为然：

汉服可以掩盖身材缺陷，但这不是囤积汉服的理由。应该调整饮食结构和健身减肥，而不是靠衣服修饰身体来自欺欺人。

我以前就有类似的误区，认为个人博客的功能越多越能证明一个人厉害，其实并非如此，因为内容才是博客真正的灵魂，过于关注形式其实会降低深度思考的能力。

另一个重要原因，以前我用 Hexo 框架搭建博客，给我的感觉就是不可控，换句话说就是在整个过程中我的参与感很弱（不过对有些人来说，参与感很弱恰恰是 Hexo 的优点，因为谁不喜欢无脑操作呢）。我没精力去弄懂它那庞大的代码体系是如何工作的，也没法对输出的臃肿的 HTML 进行字符级别的精准控制，想对它极简都无从下手。这让我很不爽，我决定自己写一个极简的框架，这样每一句代码、每一个字符都完全服从我的意志（好可怕的控制欲，感觉我似乎走上了另一条邪路 emmmmm）。

---

于是经过一番激烈的思想斗争，我舍弃了以前 Hexo 带给我的很多很多花里胡哨的东西，推倒重写了一个属于我自己的博客框架，算是找到了内容与形式的平衡点。

哪些该舍弃

从性能的角度考虑，live2d 看板娘最应该舍弃：

即使这个妹子实在很萌，我也不得不忍痛割爱。

然后就是评论系统，Twikoo.js 的代码有 700KB 之多，损失性能、浪费流量不说，压根也没人评论（不装了，这才是它被舍离的真正原因）。

切换壁纸面板大可不必存在，因为背景壁纸是导致花里胡哨的一大元凶。

文章目录我觉得也没有必要保留。

文章头部信息虽然很详细，但是这反而让人一眼看过去不知道关注点是什么。

文章尾部版权以及分享功能我也删除了。

这个板块是 Hexo 自带的，设计的挺好，我舍不得删掉的说实话，我很想（我也有能力）把它复刻到新的框架里，但是这也许就是麻衣女士所言扔东西的K点吧，一咬牙 → 恶向胆边生 → 抛弃了。

再然后，一些非常鸡肋的念两句诗、友链、说说、归档、深色模式、站内搜索也通通舍弃。

哪些该保留

我觉得关于有必要保留，这里会展示个人信息、版权说明什么的。然后读书也得保留，毕竟咱是读书人嗷，以书会友是不是，而且这个页面挺极简的。

Part 2 : 开发一个极简静态博客生成器

下图的右图就是极简博客的首页，相比以前可以说是清爽到家了。除去几个第三方库，生成器的核心部分不到 300 行代码（毕竟需求少导致代码少）。

工作流

目前，在写博客和写公众号方面，我已经形成了一个比较成熟的工作流：

具体怎么实现

Q1 : 采用哪种编程语言？

A1 : Javascript，基于 Node.js。因为开发网页离不开 Javascript，博客生成器也用 Javascript，可以减少我开发时的割裂感。

Q2 : 是否专门适配移动端？

A2 : 否。其一，如果专门为移动端进行适配，势必增加代码，这不极简。其二，我的一些博文有大量的公式，并不适合在移动端阅读。

Q3 : 是否用 Markdown 写博客？

A3 : 是。一篇博文对应一个 Markdown 文件。

Q4 : 如何解析 Markdown文件？

A4 : 在基于 marked.js 定制一个 Markdown 解析器介绍过，因为 marked.js 在解析公式的时候经常遇到问题，而且网上已知的一些解决方案都不能满足我的需求，于是我通过分析源代码，定制了一款适合自己的解析器。

Q5 : 一篇博文的属性信息保存在哪里？

A5 : 在一个 Markdown 文件的头部，标记了这篇博客的标题、日期、封面图等关键信息。这些头部信息可以用第三方工具 front-matter 解析成对象。

Q6 : 是否采用模板？

A6 : 是。使用我自己的解析器，可以把一个 Markdown 文件解析成一段 HTML，但是生成的只是正文部分，还需要把正文、标题、日期等元素填入模板，来生成完整的 HTML。模板的编译我用的是第三方工具 art-template，因为它是国产的，而且它具有语法简单、轻量、速度快等优点。

Q7 : 是否开发 cli 命令？

A7 : 是。目前开发了以下几个命令：

qingya -v # 查看版本
qingya -g # 生成（编译）
qingya -c # 清除缓存
qingya -d # 部署到远程仓库
qingya -i # 初始化git

---

目前这个极简博客生成器能够满足我的需求，但因为编程水平不高，一些功能实现得并不优雅，等着后面积累更多的编程骚操作再慢慢迭代吧。