静态博客搭建的经验分享

发布于 2024-01-14 16:33 5603 字 29 min read

作者分享了搭建个人博客的经验,对比了多种方案后选择了Hexo静态博客生成器配合Vercel托管,以实现长期写作、永久保存和免维护的目标。文章详细讨论了服务选择、主题定制、图床使用、HTTPS配置、后台搭建以及友情链接等问题,并强调了博客内容应具有原创性和实用性。作者力求在免费、省事和可控性之间找到平衡,并分享了个人对技术博客的理解和建议。

前几天在tg群里看到了一篇博客,拜读一番后觉得受益匪浅,现在就来谈一下笔者对博客的看法。

笔者起先就在酷安发表过一些文章。主要是记录一下笔者的折腾经验。不过这样的平台有一些缺点:

  • 不支持代码块和标题
  • 不方便定制
  • 环境太差

等等一些原因。而且看到了群里别人的博客,遂使用hexo静态博客生成器,配合vercel来托管笔者的文章并记录笔者的成长。

这篇文章主要是基于笔者的理解对这篇文章的补充说明。这里并不会讲解hexo环境的搭建,使用hexo初始化项目,生成文章发布站点等操作。也不会讲诸如 Markdown,JavaScript,Shell 的基础知识。如果不熟悉的话请查阅官方文档。

目标

“追求永恒,那永远也追求不到的永恒。”

笔者主要的目标就是:

  • 长期写作
  • 永久保存:永久地在互联网上留下一点痕迹
  • 部署免费:不需要购买服务器
  • 免日常维护:一劳永逸,不需要操心服务器和域名续费、升级带宽、升级软件打补丁、部署 CDN、防 DDoS、防恶意消耗流量费用等工作
  • 可定制
  • 生态要好,可以方便解决问题
  • 使用 Markdown 等通用格式的纯文本源文件,不依赖某种特定软件和服务,可以版本控制,方便备份原稿,方便迁移

当然,没有完美的方案,我们只能尽可能实现这些目标。既想免费,又想省事,还想要可控性,这往往是不可能的,往往需要做出一定的牺牲和妥协。

服务选择

首先排除的就是 WordPress 和 Halo 这样的只能依靠 VPS 的大型博客系统。

难道是这两个不好吗?非也。

这两个当然好。但是一方面需要 VPS 部署,另一方面在某些地方就会显得特别臃肿。例如内存占用方面。

然后就排除的是 Typecho 这样的小型博客系统。

难道也是因为太臃肿了?非也。

下面是 Typecho 官网的介绍:

仅仅 7 张数据表,加上不足 400KB 的代码,就实现了完整的插件与模板机制。超低的 CPU 和内存使用率,足以发挥主机的最高性能。

看着是挺简洁轻巧,不过仍然是需要在 VPS 上安装并配置域名服务器。

尽管有诸如在 Vercel 上部署 Typecho 的教程,但是仍然需要准备一个远程数据库。免费的数据库要么容量小要么不稳定。

笔者更不推荐使用自家的电力和网络折腾 homelab 和内网穿透。家里的电力和网络的稳定性和可用性和数据中心没法比, homelab 的硬件稳定性也比不上专业的服务器。

最后还是选择生成静态博客网站,这样一次生成就可以永久访问,不会像 WordPress 一样需要经常打补丁升级。笔者可以把文件储存到 GitHub Pages 上,并直接使用它提供的 .github.io 域名,这样完全免费并且免运维。

当然部署在 Github Pages 上也并不是十全十美的。

Github Pages 的缺点

笔者在部署到 Github Pages 上曾经遇到了以下问题:

  • 需要先生成网页后推送到 page 上:现在可以用 Github Actions 生成网页并推送到 page 上。

img

  • 设置成私密后原先的 Github Pages 就无法访问:当然现在也可以通过 Github Actions 解决。
  • 访问速度太慢:毕竟是大环境的原因。

除了 GitHub Pages 之外,还有其他的静态网站托管平台,例如 Netlify 和 Vercel . 当然这里并不想比较一下这两个托管平台的不同,只能说各有优劣。

在开始之前…

Hexo 还是 Hugo ?

目前流行的静态博客生成器主要有:

  • Jekyll:基于 Ruby,GitHub Pages 中已经集成了 Jekyll,push 源文件后 GitHub 就会自动帮你生成静态文件
  • Hexo:基于 Node.js
  • Hugo:基于 Go 语言,生成速度较快

因为相比于 Hugo , Hexo 的教程已经烂大街了,于是就选择了一个相对成熟的方案。不过 Hexo 生成文章的速度是比较慢的,在接受范围内。

话虽如此,博客是写作的工具, 搭建博客的目的,是为了更好地写博客,写的博客文章才是重点。

Markdown 方言

Markdown 写多了,总感觉 Markdown 默认的语法不太够用。这个时候可以选择加装 第三方 Markdown 扩展。

当然笔者用的是主题自带的,这里就便不再赘述。

Markdown 文本编辑器

“工欲善其事,必先利其器。”

笔者建议你日常用什么文本编辑器就用什么文本编辑器写 Markdown .

例如你日常用 Emacs 那你就可以用 Emacs 写 Markdown 文档而不用整一个专门的 Markdown 文本编辑器例如 marktext 。

笔者曾经使用 Typora 作为 Markdown编辑器,它的以下缺点令我难以忍受:

  • 它是闭源软件
  • 它基于 Electron 构建而不是原生构建
  • 定价太贵: 89r/3 PCs 实际上 VSCode 装几个插件也能达到类似的效果。

于是又接着用 GNU nano 写 Markdown 文章了。

定制主题

一般情况下,你可以通过主题作者提供的选项来进行小范围的定制。如果觉得提供的选项太少或者不和胃口,亦或者该选项已经不满足当下需求,在了解编写主题的编程语言后,便可以进行一定程度的定制。

例如这篇文章

是否应该使用独立域名?

域名具有独占性和稀缺性,它的收费方式实际上是订阅制而不是买断制的,我们无法永久购买域名,所谓的购买实际上是租赁。就算想长期续费,一般一次最多也只能续费 10 年。在可预见的未来,一旦停止续费,域名就会被释放,网站就消失了,这不符合上面提到的“永恒”的目标。而直接使用 GitHub 提供的 .github.io 域名则在可预见的未来中,一定程度上避免了这个问题。

但是直接使用 .github.io 域名也有一些问题。首先,有些人(例如:AB)认为独立博客应该有个独立域名,没有独立域名的博客就不能叫独立博客。

不是,免费域名怎么你了?咋滴你还怕 Github , Vercel 等公司跑路啊?

另外即使购买了独立域名,如果管理者经营不善也很有可能导致博客无法访问。

按照他们的理解,.github.io 这种子域名则显得不那么独立。另外,域名是互联网的重要入口,掌握了域名就掌握了更多主动权和控制权。而 GitHub 也不是永恒的,它提供的 .github.io 域名的寿命也只能达到 GitHub Pages 这款产品的寿命。万一微软砍刀部把 GitHub Pages 产品一刀砍掉了,网站就会消失,指向它的所有链接都会失效。

所以,如果你有自己的域名,计划长期续费(起码一次性续满 10 年吧?),也可以给 GitHub Pages 设置一个自定义域名。使用独立域名,仍然可以同时使用别人的托管服务,自己只需要按时给域名续费,平均每年只需要投入百八十块的金钱成本,不需要持续投入运维成本,这是最兼顾方便和可控的方案,值得推荐。如果以后 GitHub Pages 出现不测,或者不想用 GitHub Pages 了,也可以随意迁移,域名不变 URL 就可以不变,不用担心读者流失、链接失效。如果除了域名之外你还有服务器,计划长期续费,持续付出运维成本,可以随时把静态文件迁移到 VPS 上,可控性和自由度都很高。(使用 VPS 时,建议从一开始就套上一层 Cloudflare CDN,节约服务器流量,隐藏源站,并防止 DDoS 等网络攻击。)

ICP 备案

笔者实在是想不通为什么一个博客需要 ICP 备案:

为了访问量:除非你是名人否则除了好友几乎没人会看自己写的东西。

为了逼格:萌备不好吗(虽然在大陆不是合法的)?

除非你是只通过大陆服务供应商购买了域名和服务器并在上面搭建博客。至少我身边的好友都是在国外服务商购买的域名并使用国外的 VPS 或者 serverless 服务。

另外 ICP 备案需要身份证且拥有诸多限制。

博客站点是否越花里胡哨越好?

笔者的意见是否定的。

笔者认为,博客站点是用来记录的,一般情况下整个友链朋友圈是无伤大雅的,整个小功能例如 Github 下载的也问题不大。

但是笔者曾不止一次见过明明是一个博客站点却非要整什么音乐下载,ChatGPT 等一些几乎与博客无关的东西。然后再加一套过于花里胡哨的主题。不知道的还以为这是一个综合性站点呢。

所以笔者对于站点的要求就是可以有点花里胡哨的功能或设计,但不能太过花里胡哨影响注意力。否则就成了一具空中楼阁。

是否应该使用图床?

图床并不适合所有人。笔者认为对于大多数计算机类技术性个人博客来说,把图片和博客放到一起就可以了,没有必要使用图床。

很多搭建博客的教程,动不动上来就开始折腾图床。使用图床有一些常见的理由:

  • 为了减轻服务器的带宽、流量、并发和存储空间压力,减少成本,让各个地理位置和 ISP 的用户都能快速低延迟加载,“动静分离”,对图片资源做针对性优化。
  • 需要全平台发表,一个 Markdown 文件可以在各大平台直接粘贴。
  • 享受图床顺带的功能:自动处理图片,生成不同分辨率的图片,并自动添加水印。
  • 有时候只能分享单个 .md 文件,无法附加图片文件。

等等诸如此类的理由。

但是使用图床可能又会带来一些问题:

  • 无法保证可用性:第三方图床随时都有倒闭的风险,在微博等平台上传图片并盗链作为图床也随时可能遭到反盗链措施。如果图床挂了,图片就会突然无法加载,甚至彻底丢失。很多老博客使用的第三方图床比博客活的时间都短,图片都已经加载不出来了,运气好的话还能在网页存档服务里找到它曾经的样子。
  • 运维和迁移成本高:挂了一个免费图床,又费功夫换另一个,折腾得多了搞不好还要研究自动化图床搬家工具。
  • 数据丢失:如果图床倒闭,同时你手里没有原图,那笔者就只能对你说一句节哀顺变了。
  • 使用限制:上传图片文件时限制文件大小,上传图片后强制有损压缩图片,图像分辨率和质量不受控制地下降。
  • 网络攻击:黑客恶意消耗收费图床的流量。

所以,笔者认为折腾图床大概率是一件费力不讨好的行为。

如果还是想用图床,可以自建图床服务,把数据掌握在自己手中。可以使用一些云计算平台提供的对象存储服务。用于图床的服务器不仅需要速度快,还要离用户近,因此自建图床还是需要和 CDN 配合。

如果不想/不会/没能力自建图床,或者自建图床仍然满足不了要求,可以使用服务稳定,预计短期内不会倒闭的收费图床。如果你没钱但是有大把时间,可以尝试第三方免费图床,或者盗链。选择免费图床时要搞明白它怎么盈利的问题,不赚钱的免费服务终究还是要倒闭的。另外要清楚,在新浪微博、简书、某些云笔记当成图床,利用他们的服务器资源在自己的网站上显示自己的内容,属于盗链行为。商业公司不是慈善组织,如果他们不想被薅羊毛,分分钟让你的盗链图片失效。

最后,无论用哪个第三方图床,最重要的还是备份原图。

对于图片本身,还可以做一些其他工作。一般情况下,技术性博客里也不会有大量的图片。必要的图片可以使用 TinyPNG、ImageOptim 等工具,有损或者无损压缩到合适的分辨率和体积。而终端截图、代码截图一般都可以使用语法高亮的代码块代替。

RSS

如果你希望你的博客的最新文章被用户追踪的话,就需要启用 RSS 功能。

具体介绍可以查看这篇文章

第三方服务

这里主要指的是评论系统,因为广告服务啥的一没了解过,二就是这博客单纯也没人看也就产生不了太大收益。

静态网站没有后台,没有数据库,只能嵌入第三方评论系统。

Disqus

Disqus 什么都好,唯二的问题就是被墙了。以及不知道怎么在hexo主题里嵌入(笑:-D)。而且也不知道是否可以导出评论。

Waline

相较于上面的评论系统,Waline一方面需要自己部署,另一方面需要 Leancloud 来存储评论系统。好在问题不大。而且也有比较完善的文档支持。

HTTPS

现在都已经 4202 年了,网站早就应该设置为默认强制 HTTPS 访问了。一个 HTTP 的网站会显得很不专业。

这里并不会告诉你如何启用 HTTPS ,建议自行查阅设置方法。

博客后台

网上搭建博客后台的教程都会有一些常见的理由:

  • 可以方便在线写文章,不用再局限于某一个地方

  • 后台发布不会出现发布失败的问题。

  • 更方便管理

诸如此类的理由等等。

不过笔者觉得是没有必要的。

首先安装动态博客后台需要安装数据库(以 Qexo 为代表),即使不用安装数据库(以 Hexo Admin 为代表),也会在本地安装一大堆依赖进而导致耗费大量的时间和磁盘空间。尽管它很方便,但更适合曾经习惯用动态博客发表文章的用户。

而且在线写文章这一点也可以通过 Github Actions ( 或 Vercel )加上 Github Private Repository 来实现类似的功能。

当然这点就见仁见智了。

友情链接

友链友链,先友后链。先链后友也不是不行,例如 chimzw.

对于友情链接的申请,笔者的考虑是和有一定往来的网友申请友链。这个往来可以分成很多形式,例如邮件交流,QQ 群交流等。

要添加添加友链的话,你首先需要考虑的是:和素不相识的博主要求建立友链是否合适?

至少,你要先相互认识,就像现实生活一样,你和陌生人见面,你总要寒暄几句才进入话题吧。毕竟谁会一上来就跟陌生人说话呢?

如果只是盲目地为了添加友链而添加友链的话,那友情链接也基本上就没有了意义。

笔者曾经就犯过这个错误,当然现在已经不再主动申请了。

博客写什么?

让我们看看对于博客的定义:

博客,仅音译,英文名为Blogger,为Web Log的混成词。它的正式名称为网络日记;又音译为部落格或部落阁等,是使用特定的软件,在网络上出版、发表和张贴个人文章的人,或者是一种通常由个人管理、不定期张贴新的文章的网站。它是一种网络交流方式,是网络时代的个人“读者文摘”,它代表着新的生活、工作和学习方式。

因此笔者认为,需要分情况。

博客的分类

技术性博客

对于技术性比较强的博客,博客里应该写一些有原创性、别人能看得懂、对他人有用的东西,而不应该 100% 复制粘贴,或者写一些只有自己能看得懂的流水账。只要能帮到他人,一句话的博客也有价值,否则,粘贴再多也只是污染互联网环境罢了。

在 CSDN 平台里,有很大比例的博客可以作为典型的反例。那里充斥着互相抄袭了 114514 遍的垃圾“原创”博客,而且复制粘贴的时候连排版都没有做好,内容还有可能是错误、片面、过时的。有的人可能会说“我的博客只有我自己看”,但是他们也许没有想过,垃圾博客会污染别人的搜索引擎,不想看都不行。也许在垃圾堆里偶尔可以淘到珍宝,但是“可以”并不意味着“值得”。与其在垃圾堆里找宝贝,不如屏蔽 CSDN,用英文搜索问题。

也许 CSDN 曾经有过辉煌,但是那辉煌已经成为历史了。没有把大环境搞好,一手好牌打得稀烂,这是平台的责任,也是所有用户的损失。

生活性博客

对于生活向的博客,只要叙述得体、详略得当,把前因后果、来龙去脉写明白,一般情况下就可以了。当然如果脑子里没有词的话可以多看看书积累一下。

编排一致性

为了是博客不那么杂乱无章,可以通过编排一致性来解决这个问题

中英文混排

为了美观,中西文混排时,应当在交界处加上空格。具体规则是:使用半角方式输入西文(英文字母、数字等),在中西文交界处插入一个半角空格,但是西文和任何中文全角标点符号交界处不需要加入半角空格。

正确示例:

在 CSDN 平台里,有很大比例的博客可以作为典型的反例。那里充斥着互相抄袭了 114514 遍的垃圾“原创”博客,而且复制粘贴的时候连排版都没有做好,内容还有可能是错误、片面、过时的。有的人可能会说“我的博客只有我自己看”,但是他们也许没有想过,垃圾博客会污染别人的搜索引擎,不想看都不行。也许在垃圾堆里偶尔可以淘到珍宝,但是“可以”并不意味着“值得”。与其在垃圾堆里找宝贝,不如屏蔽 CSDN ,用英文搜索问题。

错误示例:

在CSDN平台里,有很大比例的博客可以作为典型的反例。那里充斥着互相抄袭了114514遍的垃圾“原创”博客,而且复制粘贴的时候连排版都没有做好,内容还有可能是错误、片面、过时的。有的人可能会说“我的博客只有我自己看”,但是他们也许没有想过,垃圾博客会污染别人的搜索引擎,不想看都不行。也许在垃圾堆里偶尔可以淘到珍宝,但是“可以”并不意味着“值得”。与其在垃圾堆里找宝贝,不如屏蔽CSDN,用英文搜索问题。

这个问题笔者会慢慢改进

语言风格

相比于会长期存在的博客文章,网络流行语就是一阵风,几年之后不火了,读者都读不懂了,自己看到都会觉得尴尬。

所以需要尽可能准确表达,避免歧义。尽量避免中英夹杂、中文西化等现象,不用网络流行语、emoji(抽象话)、意义不明的拼音首字母缩写等。

第三方链接

现代的 URL 中经常会加入用于跟踪和统计的参数,其中可能包含个人账号的身份识别信息。插入链接时,要把 URL 中的这些参数清理干净,尽量删除到最短。

相对链接和绝对链接

如果一个链接地址前面没有以“https://www”这样的开头,那么可以说这就是一个相对链接,反之就是绝对链接。相对链接只能用于网页内部的链接访问,而绝对链接可以用于网页外的链接访问,它是一个完整的域名地址。一个绝对链接的地址里包含了相对链接。

笔者建议站内页面链接尽量使用相对链接,因为在网站的域名更换的情况下,网页内所有和这个链接相关的设置都要重新换过,这对于后期的维护和发展都很不方便。而站外的非本网站的网页访问则可以使用绝对链接。

暂时先写这么多,想起来啥的再接着写

喜欢的话,留下你的评论吧~