No. 17: 从 Hexo 到 Astro——一次被推着走的迁移
一个网站分析工具的报告，让我发现自己的十年博客站已经是「信息化石」。于是有了这场迁移。
2026/7/6
事情要从一个无聊的下午说起。
在 x 上看到有人分享自己的个人站点，点进去一看，完全不是我以为的”博客”。人家的首屏像一张创作者桌面：纸条、咖啡、铅笔、终端窗口、项目卡片。访客一眼就知道”这个人能做什么”。
我打开自己的站看了看。名字加导航，加上 17 篇按时间倒序排列的文章列表。访客只能去猜。
1️⃣ 问题不在 Hexo
我用了十年 Hexo。它没错。错的是我把”写博客”当成了个人网站的全部功能。
对比那些让我眼前一亮的个人站，差距在三个层面：
信息密度。 人家的首屏能传递”这个人在做什么、擅长什么、能帮你解决什么”。我的首屏只能传递”这个人写过几篇文章”。
叙事结构。 人家是 About / Work / Playground，每个板块都在回答”我能解决什么”。我是 归档 / 分类 / 标签 / 关于。新读者进来不知道从哪看起。
可信证据。 人家有项目案例、实验入口、产品展示。我只有文字，没有一条说”这人的作品长什么样”。
问题不是 Hexo 不够好。是我的站已经不是一个”个人网站”，而是一个”文章收纳盒”。
2️⃣ 为什么是 Astro
需求很明确：从”博客归档”变成”个人品牌入口”。需要同时承载文章、项目案例、个人定位，长期维护成本越低越好。
看了一圈：
- 继续 Hexo——要自定义页面结构就得改模板和插件，改造深度跟迁移差不多
- Hugo——快，但模板语法我完全不想学
- Next.js——适合高交互站点，对我这种内容为主的站来说太沉
- Astro——静态优先、原生 Content Collections、文件路由、零 JS 默认输出
真正打动我的是 Content Collections。 用 Schema 定义 frontmatter，类型安全，构建时校验。写文章就是写 Markdown，没有额外的数据层。
3️⃣ 迁移做了什么
骨架级重做：
- 文章从
source/_posts/搬到src/content/writing/，统一 frontmatter schema - 新设计布局：shell 容器、固定宽度、全屏色块穿透
- 配色从灰白老主题改为暖白底色 + 酸绿色强调色（#39ff14）
- 新增项目页、About 页、RSS、404——之前完全依赖主题自带
- 滚动渐入动效 + 文章 typography 整套重写
- 部署从
master分支静态文件改为 GitHub Actions +main分支
最花时间的不是搬文章，是重新想清楚这个站应该长什么样。
| 维度 | 之前（Hexo） | 之后（Astro） |
|---|---|---|
| 定位 | 博客归档 | 个人品牌入口 |
| 内容结构 | 归档 / 分类 / 标签 | 文章 / 项目 / 实验室 / 关于 |
| 文章管理 | 纯 Markdown 文件 | Markdown + Schema 校验 |
| 路由 | 配置 + 插件 | 文件系统路由 |
| 自定义能力 | 改主题模板 | 写 .astro 组件 |
| 部署 | master 分支静态文件 | GitHub Actions |
4️⃣ 迁移教会我的事
迁移本身不难。想清楚要什么最难。
如果我只是把 17 篇文章从 Hexo 复制到 Astro，再把界面重新画一遍，那什么都不会改变。真正的迁移发生在脑子里：从一个”我写过什么”的归档思维，变成一个**“我现在能解决什么问题”的品牌思维**。
静态站不需要框架化。 Astro 的输出还是纯 HTML + CSS，跟 Hexo 一样干净。它没有让这个站”变现代”，它只是让”写网站的体验”现代化了。这一点很重要——很多人迁到 React 框架之后就默认要上客户端路由、SSR、ISR，其实你的内容站可能根本不需要这些东西。
一个好的参考对象不是用来抄的。 我参考的全视觉设计网站，但我是 AI 教育行业的产品经理。我站点的第一原则应该是：让别人快速判断你是否懂 AI、懂教育业务、懂产品架构、能把复杂系统讲清楚并落地。所以我借鉴的是它的叙事方式，不是它的视觉皮肤。
5️⃣ 下一步
这个站不会停在这次迁移。接下来会陆续补上项目案例、AI 产品实验室。但重点会回到内容创作本身——站是容器，文章和产品才是内容。
一个个人站应该像一份持续更新的说明书：告诉访客你是谁、做什么、能解决什么。而过去十年，我一直在写目录，没有写过说明书。