时隔多年，终于在最近对个人博客的技术栈又一次做了重构升级。
上一次使用 Gatsby 重构之后，其实也留下了一些遗憾。例如 Gatsby 不久之后就出了新的大版本 v3，包括后续更新的版本，都没有跟进；那时刚学 React 不久，很多代码的写法也很成问题；CSS 也乱糟糟，各种任意值乱飞，没有规范。随着 node.js 版本的升级，旧版本也逐渐成为了历史包袱，需要偶尔做一些特殊处理才能让它继续运作。
然而代码只要能跑就不要去动。虽然我自诩是一个有技术追求的人，并不完全认同这句话，但一方面我的三次元生活日渐忙碌，另一方面，随着我逐渐成为一个前端熟手，这些任务对我来说已没有技术上的兴奋劲，只沦为了体力劳动罢了。况且个人博客本就是个自嗨的东西，我更新的频率也不高，并没有那么痛。因此也就日复一日地苟到了现在。
可生成式 AI 在近几年的爆炸式发展改变了这一切。机械任务，做不好也没什么后果，最适合丢给 AI。是时候了。接下来就介绍一下本站的近期更新：
Gatsby v2 to v5
去年年底，拿 Kiro 实现的。没什么好说的，直接把需求丢过去就是了。
不过现在回想起来还是很感慨，看提交记录只是大半年之前的事，已经恍如隔世。
文章区分两个时间
这个算是一个产品层面的更新，值得单独拎出来说一下。
可能有细心的小伙伴会发现，现在部分文章的时间不再只有一个，而变成了两个。简单来说，可以把它们理解为创建时间和更新时间。复杂来说嘛，就可以说道说道。
最早在 Hexo 时期，我们使用 hexo new 创建文章，这时文章的时间就是它创建点的时间戳。后来在 Gatsby 时期，我习惯于在外部笔记软件中先写完，再导出 md 文件到博客中。这时文章的时间就是文章完成，导出时的时间戳。这里就引入了不一致。
但这个不一致我也并不是很在意。本来这个时间也没什么大不了的，况且，如果你的文章一气呵成，两者其实差异并不大。但真正使我在意的点在于，我有一个习惯，写完文章后不会立即发布，而是先沉淀几天，伴随着不断打磨、改动，然后再发布。然而我有拖延症，加之日渐忙碌，时间碎片化，再加之我纠结的个性，时有难以抉择定稿之情况，因此从初稿到定稿，有时会到跨月甚至跨年之久。如果仍使用创建时间，会显得不太真实，且博客里突然出现了一篇看上去早该出现的文章，就很奇怪。但如果使用定稿时间，又会显得我的 idea 特别旧，我也不喜欢。
思来想去，不如干脆分成两个时间。第一个时间可以认为是初稿时间，大概 80% 完成度，文章的核心 idea 已经稳定。第二个时间则是最终定稿发布时间，如果后续有较为重要的内容更新或改写（单纯修改错别字、调整措辞等不在此列），也会更新这个时间。当然，如果这两个时间比较接近，就不刻意区分了。
评论迁移到 Supabase
这属于被迫更新。我很喜欢 LeanCloud，但他们要终止服务了。
国内做同类产品的云服务不多。腾讯云的 CloudBase 算一个，我倒也用过。但他们之前取消了免费额度，我的那个项目又凉了，所以没有继续关注。最近再看到，是随着 AI 的兴起，他们认为这种产品形式非常适合非软件开发者借助 AI 快速开发出产品，故又恢复了免费额度，并大力推广以招揽客户。但我回去体验后发现，使用自定义域名的前端应用仍然在付费墙内，故只能作罢。
在国际上，Firebase 是当仁不让的霸主，但它被墙。最终看下来，选用了它的平替 Supabase，国内可直连且有一定免费额度。实际体验下来，感觉虽说是 Firebase 的开源平替，但使用上还是会更偏 Geek 一点，不过有 AI 帮助，上手也不会特别困难。迁移过程不表。
前端框架迁移到 Astro
这是这次最大的更新，值得花长篇来说。我也把它作为标题，算是对前文的呼应。
最初选择从 Hexo 迁移到 Gatsby，是因为从传统模版引擎到现代前端框架，确实形成了代差。而迁移到 Astro 并不是说 Gatsby 不好用了，而是带有一部分追新的成分。
但也并不是说这次迁移就是完全一时心血来潮，我也确实深思熟虑了一段时间。在当初弃用 Hexo，对 React 框架选型时，Next.js 是 SSR 领域的首选，而 Gatsby 是 SSG 领域的首选，选择 Gatsby 是理所当然的。但现在 Next.js 已经 SSR + SSG 通吃，并和 React server component 等新功能深度集成。随着 Create React App 的退出，Next.js 和 React 俨然已形成了共轭父子之势。而在如今 AI 大发展，框架马太效应加剧的情况下，Gatsby 的份额只会被不断蚕食，这使我对它的前景感到不太乐观。
Gatsby 此前被 Netlify 收购。收购以后的一段时间，Netlify 主推其云服务，开源版本长时间不更新，也引发了社区的一些疑虑和动荡。虽然目前看来是恢复正常迭代更新了，但也流失了一波人。Astro 的官网上放了一些从 Gatsby 迁移过来的例子，很多就是那个时候的难民。从 Github 趋势也能看出，Astro 虽然后发，但 stars 也已超越了 Gatsby。
那么，为什么不直接迁移到 Next.js 呢？之前并非没有试过，但很快遇到了 SSG 模式下，图片无法静态优化的问题，而这个功能在 Gatsby 和 Astro 中都是开箱即用的。再一查，发现这是一个多年的问题，用户呼声很高，但官方一直很冷淡，指引用户去使用运行时服务端优化的方案。但这样做，意味着你的博客必须带一个后端服务，这与 SSG 的初衷就背道而驰了。
从这个例子可以看出，Next.js 虽说同时支持 SSR 和 SSG，但 SSR 始终是亲儿子，毕竟他们发家于 SSR，且 SSR 的部署复杂度和 Next.js 独特的架构可以让用户更主动或被迫地绑定他们的生态。虽然社区也有人开发了第三方的插件，但我当时也没跑起来。自此放弃了 Next.js。
Astro 的架构则有其特殊性。它从基础的 HTML 出发，通过孤岛架构，可同时接入 React/Vue 等各种框架，有种元框架的意味。这使得它有自己的独特定位和不可替代性，和 Next.js 相比，并不是完全的上下位替代。
和 Astro 相比，Gatsby 会给人一种更重的感觉。Gatsby 把所有数据源抽象成 GraphQL 接口，说实在，我自始至终都认为这是一个很优雅的设计，如果是一个商业级的项目，需要对接各类数据源，还是会很值得选择它。但我这只是一个个人博客，跑了这么多年，所有的静态数据源也只有本地的 md 文件和 JSON 配置，现在回过头去看，未免有种屠龙之技的感觉。
Gatsby 的工程化仍然在使用 webpack，Jest 等一系列从现在来看稍显过时的技术栈。当然这是因为它起步早，并不是说它们不好。但切换到 Astro 后，可以感受到 dev server 启动速度、包体积等确实有了不小正向的优化。
也并不是说 Gatsby 就一无是处了。Gatsby 对网站有更多更开箱即用的优化手段。Gatsby 基于 React 的 all-in-js 语法，对比 Astro 必须发明一种自己的模板格式，也更加符合我的个人审美。不过平时工作 Vue 写多了，和多年前的自己比，倒也没有那么感到难受了。
前段时间，我的一个朋友让 Claude 重构他的 Gatsby 博客，Claude 也自主做出了迁移到 Astro 的决策，这也让我对自己的选型判断有了更多信心。
但就像我前面说的，现在也并不是不够用，所以虽然我确实考虑了不少时间，但总觉得优先级不高，没有下定决心开始。而变化出现在 10 月初，Codex 给的重置卡实在太多了，又是假期，正好拿这个项目来烧 token。
GPT 倒是比较干净利落地完成了整个迁移过程，消耗也不算多。不过后来我 review 代码时隐隐约约觉得有点不对，怎么写了一些我感觉应该是属于框架内置能力的代码。追问 GPT 后才知道，他为了实现方便， 并没有以正规的方式接入框架，而是调用了底层接口自行实现了诸如 markdown 渲染、图片优化、文件变化监听等能力。只能 PUA 他接着改。这其实也是现在 AI 开发中一个很典型的问题：自然语言总是模糊的，你无法确保 AI 完全理解你的意图，而如果你又不懂技术，你就分辨不出来他的结果符不符合你的预期。当然，如果你只是追求它 work，那也不是不行。又不是不能用
在迁移到 Astro 的过程中，也顺便让 AI 做了一些其他基建方面的迁移。
其一是将包管理从 npm 迁移到 pnpm。当年应该还没有 pnpm 或不出名，现在包括公司项目在内有多个项目已经用上了，而且多年来积攒的项目越来越多，也确实需要 pnpm 来解决 node_modules 的问题。
其二是从 JavaScript 迁移到 TypeScript。当年作为初学者，虽然普通的 TypeScript 语法还是容易看懂的，但涉及到 React 的 JSX 和 Gatsby 的 GraphQL 这些类型定义，确实不太容易弄明白。而现在我的项目早已 all in ts。并且 AI 时代 TypeScript 的性价比进一步提高：编写成本降低，但让 AI 不出错的帮助很大，没有理由不切。
其三是从 Less 迁移到 Tailwind CSS。同样当年作为初学者，我只是需要一个可以嵌套、可以使用变量的 CSS，Less 是其中最简单最轻量级的选择。而如今 Less 日渐式微。SCSS 仍然能保留一席之地。但后来我很快成为了 Tailwind CSS 的拥趸。这次也算是终于知行合一了。
样式优化
说是现在 AI 的设计能力进步很快，正好趁此机会试试。都说 Claude 的审美是最高的，但我只是一个卑微的中国用户，不想和 A/ 斗智斗勇，也不想把钱扔到动辄 2x 起步也不知道保不保真的中转站里。于是还是把任务给了 GPT 6 Astra。
有一些是功能上的新增，例如我想做很久了的夜间模式，还有回到顶部，还有 GPT 提出，我也觉得值得一做的文章目录。
剩下的样式优化部分，和 GPT 经历了几轮来回，一些打磨，不过大多数还是听从了 GPT 的建议。总的来说还不错。相比之下， 原来的版本更为小家碧玉，而新的版本则更显大气一些。GPT 认为最需要的改变是拉大各个地方的间距，以及放大了字号。不得不说，对于三十岁的老年人视力来说，看着确实轻松了一点。
配色方面也进行了微调，降低了颜色的对比度。可以感觉到 GPT 的选择非常安全、四平八稳、符合设计原则。确实看着会舒服一点，不那么累。
不过，相比原来的版本， 也失去了一些风格，失去了一些锋芒。
也许这就是人生吧。
看这个博客的时间线时，发现已经过了好多年了，距离上一次重构也是六年前了。如果这是一个商业项目，已经不知道经历多少次改版了。没有什么事情是一成不变的，也是时候 refresh 一下了。