从 Firefly 到「酥酥鸡」：我的博客定制记录

选择一个成熟主题的价值，不是省掉所有思考，而是把精力从“重复造基础设施”转移到“这个网站究竟应该是什么样”。

我的博客以 Firefly 为起点。它提供了文章、归档、分类、标签、Pagefind 搜索、RSS、评论适配和多种扩展页面。真正开始定制后，我做的第一件事却不是继续加功能，而是先做减法。

先让配置与内容一致#

Firefly 的页面开关很丰富，演示项目也准备了动态、相册、友链、留言和追番等示例。如果没有真实数据却把入口全部打开，读者看到的只会是空页面或主题作者的演示内容。

因此，第一版只保留这些核心入口：

其他页面继续保留代码能力，但通过 siteConfig.pages 关闭。等到有真实内容和维护意愿时，再重新启用会更稳妥。

Tip

页面隐藏不等于内容一定不会输出。像动态页这样的功能还可能生成 JSON 数据接口，所以演示文件也需要清理，不能只删导航链接。

我没有完全重做主题，而是围绕统一的视觉目标调整现有系统：以蓝色为主色，扩大内容区域，使用更适合中文阅读的字体，并保留卡片边框与轻量阴影。

导航负责帮助读者快速抵达内容，侧边栏则承担氛围和辅助信息。时钟、每日一言、运行时间与樱花效果都可以存在，但它们不能抢过正文。动效和装饰最终都要服从同一个判断：是否会影响阅读、性能或移动端布局。

亮色与暗色模式也不能只检查首页。文章卡片、代码块、提示框、标签、页脚和移动端菜单都需要分别验证，否则很容易在某个局部出现对比度不足或背景突兀的问题。

Firefly 使用 Astro Content Collections 管理文章。每篇文章可以使用 Markdown 或 MDX，Frontmatter 负责标题、发布日期、描述、封面、分类、标签、草稿和评论等元数据。

我选择让每篇文章拥有独立目录：

1
src/content/posts/
2
└── customizing-firefly-blog/
3
    ├── index.md
4
    └── cover.png

这样文章 URL 由目录名稳定决定，封面和后续插图也能与正文放在一起。Frontmatter 中只需使用相对路径：

1
image: ./cover.png

本地图片会进入 Astro 的图像处理流程，再按照站点配置输出 WebP。相比随机图片 API，这种方式没有第三方可用性和防盗链风险，也更容易保持整站风格统一。

这个项目的正式构建命令不是单独执行 Astro，而是：

1
pnpm build

原因是完整脚本还会执行 Pagefind 等后处理。如果只运行 pnpm exec astro build，页面可能看起来正常，但 dist/pagefind/ 不完整，部署后搜索就会失效。

我的本地验收至少包含以下项目：

我仍然保留 Firefly 的 Logo、Favicon 和开源署名，也保留未来重新开启评论、友链或相册的可能。不过，第一版不会因为“主题支持”就默认公开所有功能。

这次定制最大的收获不是改了多少 CSS，而是逐渐明确了一条边界：配置应该服务真实内容，功能应该对应持续维护的承诺。先把三篇文章写好，比先摆出十个空栏目更重要。