ulBo 是一个面向个人博客场景的 Astro 主题模板，强调配置集中、可迁移、可扩展，以及对 SEO/性能的工程化细节优化。

迁移astro的原因

hexo——构建效率低

大一快要结束时，第一次尝试在github上部署自己的博客。当时并没有对比主流的博客框架，只因为hexo是第一个刷到的，便直接选择了它。在之后的一年半中(到现在)，我花费了大量的时间用于写博客，只是想要记录下来自己所学的知识，所走过的路。这一年半中，踩了不少写博客的坑，无数次为自己的鲁莽、不求甚解而买单。

还记得刚开始写博客时，我甚至搞不明白md文档中插入的图片应该放在hexo的哪个路径下，索性写了个脚本将文档中的所有图片用base64编码内嵌在md文件中：

这种写法也有一个我当时认为很棒的优点——每个md文件的内容都是完整的。使用这种方式，完全避免了文档还在，但图片丢失了的情况。

1770898680463

在一些早期的博客源文件中现在依旧可以看见这些base64编码的身影。

hexo中：

md文档放在 source/_post/路径下

而图片路径的根目录为 source/

假设你在文章中引用的一张图片路径为 image/md/example.png，你的图片实际路径需要为：source/image/md/example.png

就这样，很快我就遇到了写博客生涯的第一个问题：内存溢出

hexo缺点：Hexo 需要将所有文章的元数据加载到内存中进行处理。如果文章极多或图片资源管理不当，很容易触发 Node.js 的内存溢出（Out of Memory）。

解决这个问题很轻松，只要把md文档中的所有图片与文本分离即可。在md文档中只引用文档的相对路径即可。

hexo——公式渲染的错译

在我的文档中，我以前偶尔能看到一些没有被渲染的数学公式：

1770899752877

这些公式中所有的 *和 _这两个符号，都被替换成了元素 <em>。导致公式无法被正确渲染。

hexo缺点：它的渲染器（marked.js）是一个“一锅烩”的线性解析器，它分不清什么是公式，什么是普通文本。于是Markdown 渲染引擎抢在 MathJax 之前，把这些符号解析成了 HTML 的强调标签（<em>） 。

其实这个问题也很好解决：

把所有公式中的 *替换为 \ats
在所有公式中的 _替换为 _{}

也许是这个问题点燃了我想要更换框架的怒火，也许是趁着假期想要做点什么东西，我选择使用Astro并自定义一个主题。

astro有很多优点，比如：

而 Astro 使用的是 Remark 和 Rehype 生态系统，对于文章解析能力更强，完美解决公式的问题。
Astro 的底层构建工具是 Vite ，而 Vite 内部使用了用 Go 语言编写的 esbuild 。在处理数千个文件时，Astro 的并行处理能力让它的构建时间随规模增长的斜率远低于 Hexo。

接下来就介绍一下我的博客主题以及这个过程中学习到的一些知识

ulbo主题

主题仓库：xxy1103/ulbo-astro-theme-template

并且我已经同步提交到Astro的主题仓库，正在等待审核，审核通过后会在此更新链接。

1770900824146

关于主题的详细介绍可以在github仓库中查看。

针对这个博客主题设计，我希望做出类似SPA(单页应用)的效果，同时我又很喜欢原生android系统中Material Design的非线性动画设计。结合两者，就做出了这个主题。

博客架构

过去以为博客能有什么流程架构，无非是下载一个主题模板，然后在里面修改自己的个人信息，最后更新自己的博客内容即可。

对于一个功能完善，也没有bug的优秀主题或许确实是这样。但是我的博客主题可能并不完善，后续如果我想要修复主题的bug或更新功能，莫非需要同时在两个仓库修改代码？(一个是我配置了个人信息发布内容的仓库，一个是我开源的仓库模板)

于是学习到了我认为是比较现代且标准化的一个模板仓与内容仓分离方案：Upstream Sync (上游同步) 模式

1770902527652

上图真好看。

核心架构：

模板仓(ulbo-astro-theme-template)：作为“发动机”，负责 UI 组件、样式（CSS）、构建逻辑和插件配置。
内容仓(xxy1103.github.io)：作为“载体”，存放你个人的 .md 或 .mdx 文章、图片以及个性化配置（如 astro.config.mjs 中的站点名称）。
Upstream 关联 ：通过 Git 将两者建立联系，使你在内容仓也能轻松拉取模板仓的功能更新。

如果你在第一次git merge时遇到报错：fatal: refusing to merge unrelated histories。可以使用强制合并命令：(允许无关历史的合并)
git merge upstream/main --allow-unrelated-histories

这样做的好处：

无痛同步更新：你在模板仓修复了一个 Bug 或增加了一个新功能时，只需要在个人主页仓执行 git fetch upstream 和 git merge，就能直接获取更新，而不需要手动复制粘贴代码。
保持仓库整洁：个人主页仓可以专注于内容创作，而不会被复杂的底层框架逻辑干扰。
多站点复用：如果你以后想开第二个站点（比如专门放摄影作品），可以直接再次以该模板创建新仓，同样关联这个 upstream，实现“一套代码，多处复用”。

LightHouse

整个主题的SEO全部是交给GPT-5.3-Codex来完成的，但是如果没有学过相关的内容，我们可能很难评测网页SEO的效果，好在，浏览器自带的开发工具Lighthouse可以自动帮我们测试。

Lighthouse 是一个由 Google 开发的开源自动化工具，主要用于 改进网页的质量 。

如何使用它：

按 F12 或右键点击页面选择“检查”打开 DevTools。
找到 “Lighthouse” 标签页。
点击 “Analyze page load” (分析页面加载) 即可开始。

测试Lighthouse时，请不要使用启动命令 npm run dev；使用 build然后再 preview进行测试。

但最好还是直接在最终的部署环境下测试，如gihub page，这才能够反应真正的效果，包括网络延迟等。

1770903593237

Lisghthouse可以综合测试网站的多项指标：

1770903674522

并且还会进行数据分析以及诊断结果，让我们可以很方便的智慧ai进行针对的优化：

AI优化后，建议再次测试，检验ai的优化是否有效，AI很有可能进行负面优化。

1770903742377

GSC与BWT

GSC(Google Search Console)：它是由 Google 提供的 免费服务 ，用于帮助网站管理者（站长、SEO 人员、开发人员）监控和维护其网站在 Google 搜索结果中的表现。

如果你希望的网站尽快被Google索引，可以在这里请求编入索引：

1770904789743

BWT(Bing Webmater Tools)：与GSC同理，不过是Bing的服务：

1770904945395

通过GSC和BWT可以进一步优化网站的SEO性能！！！而且很有针对性

blog主题开发与架构_