---
title: "建站小结2.0"
published: 2025-04-30
tags:
  - "Astro"
  - "CloudServices"
---

![文章封面图像](https://blog-static.xeonzilla.top/img/blog-summary2/cover.avif)

经过不懈的努力，博客2.0也是初具雏形。初代博客陪我走过了一年的时间，现在，我想要赋予这个站点更强的玩具属性。即使我写不出文章，也能对博客进行各种各样的改动，满足我对各种新奇技术的探索。

## 关于Cloudflare

博客2.0的最大功臣，非“赛博菩萨”Cloudflare莫属，我在一个平台上就完成了几乎所有的作业。如果哪天，Cloudflare提供了代码托管的功能，我甚至可以不需要GitHub。

目前的站点的结构如下：

|   项目   |         框架        |                        服务提供                        |
| :----: | :---------------: | :------------------------------------------------: |
|  域名解析  |         /         |                     Cloudflare                     |
| CDN与防护 |         /         |                     Cloudflare                     |
|  博客本体  |       Astro       |                  Cloudflare Pages                  |
|  评论系统  | twikoo-cloudflare | Cloudflare Workers + Cloudflare D1 + Cloudflare R2 |
|   图床   |   无（未来或许是PicGo）   |                    Cloudflare R2                   |

Cloudflare CDN的可访问性不好，这是事实，但是这并不是Cloudflare的问题，我们没有理由奢求更多。最极端的情况，如果Cloudflare CDN在中国大陆完全不可访问，关闭Cloudflare的代理也能够缓解，不是什么大问题。

Cloudflare太过慷慨，以至于我很想为它做些什么，可惜Cloudflare目前不支持`.top`域名，要不然我一定要转移域名到Cloudflare，以示感谢。

## 关于Astro

一年前的我非常排斥Node.js，因为江湖中总是流传着它的传说：“比黑洞更深不见底”的node\_modules，感人的站点生成速度，还有版本管理地狱。但是在我与Go/Hugo相处的一年中，我确实也感受到了Node.js的优点，繁荣的生态、便利的包引入、大量的开发者与社区讨论。在一番挣扎后，我决定亲身体验它的好坏，毕竟调查过后才有发言权。

相比于最主流的Hexo，我选择了新生的Astro。作为后来者，Astro在设计上就强调了性能与易用，技术细节还有待了解，但至少目前的站点确实能让我感受到所言非虚。同时，作为新项目，Astro的生态和社区却意外成熟，这是开发者们对它的肯定。

在基础的使用体验上，我必须承认，Hugo太过优秀，以至于找不到对手。毫秒级的站点生成时间，100MB的轻巧体积，模块式的部件替换，还有便利的主题功能。如果你是一位“建站新手”或“极简主义者”，我觉得Hugo一定能让你满意。相比之下，Astro笨重又缓慢。对于现在的站点，占地700MB、编译时间3分钟，简直不像是一个时代的产物。即使我使用Bun来提升效率，也改变不了Astro的先天缺陷。

相应的，我得到的是极强的拓展性与可玩性。Astro的“UI无关”理念，能让我随意取得他人的优秀组件与设计，而不必担心前端框架的移植。在Hugo与Blowfish中需要自行获取的图标，在Node.js与Astro这里，只需简单的一句import。唯一的小遗憾，就是我心心念念的Bangumi组件，没办法直接引入，最后还是要靠我自行实现。npm里的bangumi包，迷惑性真是太强了。

## 关于Fuwari

讨论主题前，我必须要吐槽Astro对主题功能的设计。Astro提出的主题功能，耦合度极高，不如说它是“框架”、“手脚架”。所有的修改与个性化，都直接在原有代码上执行，而不是像Hugo一样，提供一种Overlay功能，能让用户在不触碰原有代码的情况下实现修改。对于熟悉Git操作的用户，还可以通过`cherry-pick`和`rebase`进行同步，而对于我这种只会`add`、`commit`、`push`三板斧的普通用户，想要同步上游真是令人头疼。

最后，我选择将主题添加为子模块，然后手动同步所需的代码，勉强解决了与主题上游同步的问题。

说回主题，我选择了Astro社区中比较出名的Fuwari，它在设计与性能方面表现都相当不错，也难怪使用者众多。我上手Fuwari的第一感受就是：“它真好看”，大量的过渡动画、统一的圆角和块状设计、还有自定义主题色，比Blowfish精致太多。

Fuwari最大的问题是开发进度缓慢，尤其是作者相当坚持自己的美学，很多小细节都希望自己设计。慢工出细活我倒是不反感，但是一些最基本的功能，例如评论系统，都没有完成的情况下，缓慢的开发确实让我有些心急。

博客的很多功能，都来自社区的二次开发，包括评论系统和友链页，感谢他们的贡献，让Fuwari的可用度高了很多。

## 关于Twikoo

站点的评论区是变动最频繁的部分，目前我的选择是twikoo-cloudflare，这也是Cloudflare生态下的唯一选择。其他的评论系统，例如MiniValine或基于Cloudflare Workers实现的原生评论系统，从可持续性的角度看，都不如twikoo-cloudflare。

非常诡异的一点是，Waline和Twikoo作为最流行的两大评论系统，竟然没有数据迁移的直接途径。最后不得已，我选择手工录入先前的评论，可能会出现意料外的问题，但是能保全数据，也无所谓了。

## Astro+Fuwari之后？

相比于先前对迁移的热情，我必须要说，翻新一个已经存在大量数据的站点是一件很耗费时间和精力的事情；而且Astro与Fuwari的组合也足够好玩，实在是没有必要再“搬运”我的博客。

曾经我对Zola有着谜之执着，但是在听说Zola开发者的独裁与固执后，这份执念也消散了。一个流行的软件，一定是适应大多数人的需求、符合大部分人习惯的优秀产品，Zola声称自己比Hugo优秀，结果在功能性和生态远远不及，实在是很难说服我这位前Hugo用户再去尝试Zola。

![Fresh](https://blog-static.xeonzilla.top/img/blog-summary2/01.avif "Fresh")

在决定使用Bun进行开发前，我首先了解的是Deno，毕竟“Deno, the next-generation JavaScript runtime”的口号很响亮，Deno还附带了官方开发的框架Fresh。我就曾计划使用Deno + Fresh的组合，进行一次全新的、跨时代的站点建设，可惜我高估了自己的实力。没有了主题之类的预设功能，从零开始开发一个站点真是寸步难行。

虽说计划失败了，但是不代表我会就此放弃，目前我唯有期待，Fresh也能有简化开发的功能出现。