决定用 Hugo 的原因

一开始考虑的是，因为评论管理起来太麻烦了，于是想着要不要放弃掉评论。从 14 年最早开始做个人站的时候，先是 Typecho 再到 WP ，其实一直以来都比较讨厌的是 php 运行起来实在有点慢（当然，跟我的 VPS 的配置有点差也有关系）。

既然放弃评论机制，那么对于 “ 精通 Markdown ” 的人来说，各种静态站点生成器就变成了首选，毕竟不再有动态内容的需求了，而且像有账号洁癖的程序员群体，基本上是不会去公共设备上登录自己账号的，自然也不存在跑到外面用别人电脑写文章这种事情。

进入静态站点生成器这个话题之后，绕不过去的一环自然是速度。老实说，从我过去为数不多的使用体验， Hexo 真的就，几个页面能跑半天，更何况还有个 node_modules ，属实是血压拉满（虽然我主力眼下还是 JS 但是不妨碍我喷 node_modules ）。而 Jekyll 甚至还没有入围就被我踹了，单纯是因为它是用 Ruby 写的（鄙视链又开始了）。所以， Hugo 这种速度超快的，在这一轮（也是唯一一轮）就这么选出来了。

主题呢？

选中 Hugo 之后，我又回到了到底是用 Hugo 还是重启 WP 的纠结中，因为我发现， WP 有一个叫 Argon 的主题还蛮好看的，就又开始了无意义的纠结……然而最后结束这份纠结的原因是因为……我看了眼我的 VPS 的配置……并且不想在这上面再多花钱了。

在放弃 Argon 之后，回到 Hugo 的主题范围内，直接在 GitHub 按 Star 排序，前几位稍微瞅了一眼， Stack 算是比较对胃口的，相对简单没那么花哨，于是就选了。

配置我这份实例的过程中，我稍微去参考了一下墨语的 这篇文章 ，但是没有完全照搬，比如他的字体和样式设定我觉得就没有很合我胃口，以及我并没有使用 hugo mod 所以我也没有像他那样直接去修改主题文件，用了另外的覆写方式。

Cloudflare 先开起来

CF 这头就很简单了，域名解析转入，并且开通一个 Pages ，再把自己的域名指过来就好了。

在我粗浅地看文档的过程中，我发现 CF 这边如果用 git 仓库链接的方式的话，是有开销限制的，而我在 GitHub 那边有 Pro ，所以就想在这边省省，于是在创建 Pages 项目的时候，我直接用了上传压缩包的方式来初始化，反正以后 CI/CD 弄起来，也是 GitHub Actions 来调 API 上传。

Pages 默认会给一个 [project-name].pages.dev 的域名，默认情况下，这个域名和自己绑的域名都可以访问到。为了避免意外，总归还是期望能不能都跳转到自己的域名上（虽然别人应该也猜不到我的 .pages.dev 的域名是什么）。那么根据 CF 的 官方文档 ，用了它的 Bulk Redirect 做掉了这个跳转行为。哦对了，顺手还把 www.tinko.moe 也跳了（笑

至于每个 deployment 各自的子域名（也就是 xxx.[project-name].pages.dev ），我用了 CF 的 Access ，加了一条 Everyone deny ，不担心有人能看了。

上 GitHub Actions

这个环节其实没什么好说的了。在本地跑起来看着没啥问题，带上 Actions Workflow 往 GitHub 上面推就是了，记得要先按文档在 Repository 的环境变量里去配上 Cloudflare API Key。

从 Hugo 和 CF Pages 两边各自抄了一部分拼出来的 Worflow ，这里贴一下，以防有人有需要：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

name: Build and deploy to Cloudflare Pages

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      deployments: write
    name: Deploy to Cloudflare Pages
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          submodules: true

      - name: Cache Hugo resources
        uses: actions/cache@v3
        env:
          cache-name: cache-hugo-resources
        with:
          path: resources
          key: ${{ env.cache-name }}

      - uses: actions/setup-go@v4
        with:
          go-version: "^1.21.0"
      - run: go version
      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v2
        with:
          hugo-version: "latest"
          extended: true
      - name: Build
        run: hugo --minify --gc
      - name: Publish
        uses: cloudflare/pages-action@1
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          projectName: # Your Cloudflare Pages project name goes here
          directory: "public"
          gitHubToken: ${{ secrets.GITHUB_TOKEN }}

弄完这些到这里，基本上每次更新推上去之后可以在一分钟之内把整个 CI 走完，基本上没什么需要操心的。

最后的最后

说实话现在这个方式我用起来还是比 WP 更舒服的。一方面，我写的内容都是 Markdown ，排版什么的也完全不用操心。另一方面，原始的文本和其它杂七杂八的东西都是在一个 git 仓库里，直接一个复制文件夹或者打个压缩包就能带走了，相比起 WP 还要备份附件啊数据库啊之类的一堆东西，我觉得心智负担会低很多。而且现在写文章的时候，跟之前写文档的体验一样，都是在 VSCode 里面写，早也就习惯这样了。还有就是，我在写的过程中，我不再需要去操心会不会一个网络抖动导致我的草稿没能自动保存，或者写完之后点发布转圈圈要转半天，现在预览都在本地，一个 Ctrl-S 直接 hot reload ，或者更懒一点我可以直接用 VSCode 的 Markdown All in one 插件自带的 Preview ，发布也是 git push 不再操心跟之前 WP 一样点个发布卡半天还不敢刷新。

而在部署方面，我也不需要再去操心 VPS 要停机维护啊， SSL 证书要续期啊， nginx 配反代啊什么乱七八糟的，没有，彻底地，完全没有了，一个 Cloudflare Pages 彻底送走一切。

哦对，甚至，我还有 GitHub Copilot ，虽然这玩意的提示内容在写文章的时候用处不大，但是时不时倒也能猜中一些，少写一两行字也行（笑