博客的变迁
以我从事程序员开始计算，这个博客是我第 7 版个人博客。当然不算博客园、CSDN 和掘金这类平台。
我的域名也不断在增加，luzhenqian.top 到 luzhenqian.me，再到现在的 luzhenqian.com。
在工作早期，我受廖雪峰、阮一峰、张鑫旭等大佬的博客深深影响。
我算是觉悟比较早的程序员，坚定地认为走技术这条道，一定要写博客。具体的理由实在是太多了。具体可以看知乎上的这个问题：写博客对程序员很重要吗？
第一版
2016 年。
我用 jQuery 做了第一个静态博客。当时追求高端特效，在一个非常火的 jQuery 插件库 jq22 上面充值，用来下载一些收费插件。首页是用 3D 樱花 做的。这个插件非常炫酷，用了一堆的算法，到现在也没弄明白。这一版的博客只是记录了一些简单的个人信息，当时仅能在手机上浏览，电脑兼容性很差。网站挂到了阿里云上面的一个虚拟主机上，域名是 luzhenqian.top。为什么选择 top 域名而不是 com 域名呢？因为 top 域名便宜，那时候刚工作，没啥钱。做博客的目的也很单纯，为了让别人能够从网上看到我的信息，比如面试的时候，显得我比较厉害。
第二版
2017 年。
我觉得纯前端的博客不够上档次，就用当时工作中用到的 Spring、SpringMVC 、Ibatis、JSP、Oracle 和 JQuery 等技术栈搭建了一个带后端的博客系统。这套博客系统是第一版的补充，我更多的是想做一套电脑版本的博客。当时的设想很美好，是在浏览器里面实现一个操作系统。当时也是借助了很多 jQuery 插件，东拼西凑，最终做出来一个像模像样的博客。在浏览器中打开了一个高仿 Windows 界面的网站，而且还高仿了一个 QQ。我还把不同风格的系统 UI 做了 4 个系统，好像分别叫 Monkey、Tiger、Mouse、Bear。至今我还记得同事看见我的博客那惊讶的表情。现在想想，那时候真的就是小打小闹，本质上仍然是在炫技。不过这套博客对我的意义非常重要，它让我弄明白了一个 Web Service 的真正工作流程和分层架构的意义。
第三版
2018 年。
这时候我已经熟练掌握 SpringBoot 和 Vue 等框架了。第二版博客因为太过于华而不实，而且当时没有租服务器，后端没办法部署，也就没正式使用。这期间我一直在用博客园。博客园的样式实在是太丑了，不过好在支持样式定制，经过再三折腾后，还是丑。最后我决定再做一套漂亮且实用的博客系统。开始用 Vue 和 quasar 开发了一个静态博客网站，写了一些文章，给公司的实习生培训演示用。用了一段时间，还是觉得没有后端的博客网站简直就是没有灵魂。于是租了台腾讯云的服务器，很便宜，一年才几十块吧。前端选择了 Vue 和 IView。后端呢，可能是用腻了 Java，这时候我没选择 SpringBoot，而是用了我不是很熟的 Python 和 Django。数据库换成了 MySQL，装上了当时最新的 8.x。然后照抄博客园和 CSDN 熬了一段时间夜，搞了一套博客，包含了一个完整博客的所有功能：用户注册登陆、文章阅读数、标签、文章分类、文章审核、无限层级评论、作者等级、分享、富文本、Markdown 编辑器、主题、草稿箱、垃圾箱等等。做完之后兴奋的不得了，大半夜录了很长一段视频介绍这个博客系统怎么用。后来我觉得仅仅是做了 PC 端当然不够，我还要做移动端，全方面覆盖。于是用 Weex 开发了 App，还开发了微信小程序。为了让 markdown 可以跨设备跨平台同步，我又参照 Google 云端硬盘 设计开发了一款和博客系统捆绑使用的网盘系统，起了个很牛的名字，叫无涯云盘。做了那么多软件，Bug 也多，维护它们太吃力了。最后反而忘记了博客的初衷，是记录有价值的事，而不是折腾代码。本末倒置，疲于奔命，反倒没积累下什么有价值的文章。后来发现了语雀，当时就觉得这就是我想要的。我开发第三版博客的终极目标其实就是语雀。于是我停下了第三版博客系统的开发，转到了语雀平台。直到现在我还在使用语雀记录一些东西，不过我不习惯公开，更多的还是用语雀当一个写作工具。博客网站使用老版的 gitbook 开发，托管到 Github Pages，gitbook 的缺点是样式太丑，Github Pages 的缺点是网速太慢，而且对 SEO 不友好。
第四版
2019 年上半年，开始流行.me 域名。我看到尤雨溪的官网域名也是.me 域名，于是也想搞一个.me 域名。但国内没办法注册.me 域名，于是我就在 GoDaddy 上面买，我发现单独买.me 域名不是很划算，和虚拟主机搭配比较划算，好像一年才一两百块钱。这种虚拟主机只支持 PHP 语言，会送一台 MySQL 数据库。于是我就用 PHP 的 laravel、React 和 Material-UI 开发了第四版博客。本来以为不会再有什么问题，终于可以好好地用自己做的博客系统了。可是问题始终接连不断，GoDaddy 的服务器在国内连就像是乌龟一样慢，Material-UI 的包非常大，加载也很慢，两个问题结合到一起，首屏加载极慢，几乎到了不可用的状态。我仔细研究了下 Webpack 的 Tree Shaking 和分包加载，提高了一些首屏加载的速度，可是像 Material-UI 这种组件库非常笨重，加上还是解决不了服务器访问慢的问题。最后被我放弃了。从这时起我就开始认定，静态博客才是正道。那些带后台的博客系统，前端页面都做了资源静态化。
第五版
2019 年下半年，我体验了很多专门做博客的产品，比如 Hexo、Jekyll、VuePress、gridea、docz、docusaurus 、docsify等等。Hexo 生态很完善，但是需要服务器搭建后端。Jekyll 是老牌的静态博客框架，支持 Markdown 渲染，非常不错。VuePress 介于写博客和写文档之间，熟悉 Vue 的话上手很容易，同样是静态化的。gridea 集写作和发布于一体，开箱即用，有很多主题，体验上比其他几款要强，学习成本极低。docz 是使用最简单的框架，一行命令就可以启动，支持 mdx，可以很方便接入 React 生态系统，当时找了一个轻量级组件库 welcome ui 来配合 docz，开发成本极低。docz、docusaurus 和 docsify 三者其实很像，都是为了开源软件的文档而生，当然也可以用来写博客。其中 docusaurus 功能最强，docz 最简单，docsify 介于两者之间，不过 docsify 维护上比较差，有些浅而易见的小 Bug。除了上面列举的这些，还有很多优秀的产品和框架，我在搜索引擎和 github 上面搜罗了一个清单，大概有几十个，我逐一体验过，但名单一时找不到，就把印象最深的几个写下来了。
最终我还是选择使用 Gatsby。在静态网站生成器领域，Gatsby 几乎是最成熟的解决方案。你只需要简单了解 React 和 GraphQL 就可以使用 Gatsby。Gatsby 有最庞大的插件系统。Gatsby 本身的功能比较少，需要安装很多插件，比如解析 mdx 等。但有一款必不可少的处理图片的插件 gatsby-image 非常难以安装，它依赖一个 nodejs 底层处理图像的包 sharp，而 sharp 又依赖了 node-gyp 和一个 c 模块 libvips。node-gyp 的作用是编译 node 中的 C++扩展包的，在不同的环境下有不同的要求。我那时有三台电脑，分别是 Windows10、MACOS 和 CentOS 系统，只有 Windows10 可以跑得起来，MacOS 和 CentOS 折腾了很久最后放弃了。而且 Gatsby 的插件配置非常非常多，插件多了之后打包速度也让人头大。随着博客文章越来越多，打包速度也越来越慢，那时候我没有使用 CI 工具，而是打完包后手动上传到服务器上，这时候我已经换成了因为创业失败而闲置的一台三万多块的服务器。很快我就停止继续开发这套博客，转到了掘金、gitchat 和公众号。不过至今还在使用这套博客，整体效果还可以。
第六版
2020 年上半年，这时候我已经是微信读书和京东读书的深度用户。我被它们流畅的体验所吸引，我想，能不能在 Web 上实现这些功能？于是，我开始研究机制的移动端 Web 体验。开始用 Next.js 开发移动端 Web 博客，没有使用任何组件库。我想看看现在的前端技术能把体验机制做到什么程度。
因为是从零开始做的，需要做技术选型。对比了 marked 和 markdown-it 等 Markdown 渲染器，prism.js 和 highlight.js 等代码高亮库。最终选择了 marked 和 prism.js。在将它们集成到服务端渲染的过程中又踩了很多坑。比如当文章字数过多时，文章的渲染会很慢。如果把 marked 的渲染放到服务端做，可以比客户端渲染要快很多。做到最后发现这其实就是一套 Web 阅读器。
管理端使用 Nest.js、ReactAdmin 和 Mongoose。但是管理端一直没做好。本来打算把它开源，犹豫了一阵子，出于完美主义的心态，最终还是又把它搁置了。不过还是很推荐 Node.js 这套技术栈，开发效率非常高。这时候我更喜欢一些开箱即用的轻博客，比如 GitBook。
第七版
2020 年下半年，也就是现在。我打算做最后一版博客系统，把之前所有的博客文章都迁移到这个网站上，专心做内容。基本的设想就是满足 5 点即可。
- 支持 Markdown。
- 静态博客。
- 无服务器部署。
- 自动化构建。
- 浏览量和评论。
没用主流的 React+Gatsby 体系或者 Vue+gridsome体系，而是用 svelte 和 sapper。并且在 github 上找到一个还不错的模板 sapper-blog-template。
基础框架 svelte & sapper
之所以选择 svelte 和 sapper 作为基础框架，是因为它相比较 React 和 Vue 而言算是有三点好处。
- 对 SEO 支持度更优。
- 在做小型项目时，runtime 特别轻量，加载速度快。
- 语法层面决定了 svelte 具有更高的开发效率和更少、更简洁的代码量。
sapper-blog-template 集成了 marked、prismjs、reading-time、gray-matter 等功能，可以说基本上是一个开箱即用的静态网站生成器。
Markdown 渲染器 marked
在渲染器的选择上，marked 几乎是目前的首选，没有任何一个 Markdown 解析器可以比它更快。
代码高亮 prismjs
PrismJS 和 Highlight.js 无论是性能还是功能，实际上没有太大区别。
静态网站托管平台 netlify
免费的静态网站托管平台有很多。比较知名的两个分别是 vercel 和 netlify。虽然国内的一些云服务厂商也提供了免费的托管服务，比如腾讯云的 SCF，不仅可以托管静态网站，也可以托管后端服务，只是每个月有免费额度。根据真实体验感受来说，选择 vercel 和 netlify 更佳。两者都有免费托管服务，对带宽和构建时间做了限制。netlify 可以每月免费使用 100G 带宽和 300 分钟的构建时间。vercel 的免费构建速度是 100 分钟。不过两者的针对性不同，netlify 更加针对客户端应用程序，vercel 更加针对服务端应用程序。这里选择了 netlify。
自动化构建 Github Actions
Github Actions 可以很好的配合 netlify 进行自动化构建。当每次提交代码到 git 仓库时，github actions 都会自动运行配置好的脚本进行构建，并把构建结果推送到 netlify 服务器上，由 netlify 服务器进行构建。
访问量 LeanCloud
主流的选择有 LeanCloud 和不蒜子，以及基于 LeanCloud 封装的 Valine。
不蒜子的数据库不可操控，所以没有使用。相比较之下，LeanCloud 可能更好用一些，相当于在 Web 端直接操作数据库。也可以做一些除了访问量之外的事情。
评论 Gitalk
基于 github isuues 实现的 gitalk 非常容易接入。
获取用户 IP 和地址 pv.sohu
搜狐一直提供一个 JavaScript 脚本用于获取用户 IP 和地址，不过地址精度只能到省级别。
在页面中插入脚本。
<script src="//pv.sohu.com/cityjson?ie=utf-8"></script>该脚本返回内容是一个 JavaScript 对象，可以直接使用。
var returnCitySN = { cip: "39.71.123.189", cid: "370000", cname: "山东省" };静态网站性能测试 Google PageSpeed Insights
Google 有一个用于网站性能测试的 Web 工具，Google PageSpeed Insights。可以在这里进行性能测试，并且能够得到反馈和建议，进而优化网站性能。
https SSL 证书
阿里云有提供免费购买 SSL 证书的服务。(链接在这)[https://common-buy.aliyun.com/?commodityCode=cas#/buy]。
图标
网站 icon 在 flaticon 或者 iconfinder 上面找。
图标库在 iconfont 上面找。
阿里云 OSS
在使用了一段时间免费的 netlify 之后，我发现在国内访问网速很慢。于是开始研究国内类似的服务。我比较熟悉的有腾讯云的云函数和 Gitee Pages，不过最后选择了阿里云 OSS。原因是阿里云 OSS 最快，也最省事。
缺点是收费，但费用极低，请求量少的话可以忽略不计。
高德 SDK
在开发「碎碎念」功能时，我想尽量模拟朋友圈的实现。至于微信的定位功能，由于是 App，采用 GPS 定位，其精度肯定会比 H5 的 Geolocation 要高。虽然有所误差，也勉强可用。配合高德 SDK，可以很方便的实现 H5 应用定位。
博客系统开发过程中的一些感悟
中国人治病有一个习惯，就是「治本为先」。
实际上在一些误诊的情况下，病的原因可能不是「本」上的问题，恰恰可能就是「标」上的问题。博客系统就是这样。
博客的目的是为了记录有价值的东西，而不是纠结用什么来记录。
未完待续...