酥酥鸡

你好，这里是酥酥鸡的博客

Wed, 26 Aug 2026 10:00:00 GMT

你好，欢迎来到酥酥鸡的博客。

这是这个小站正式发布后的第一篇文章。比起把它当成一份精心包装的个人简历，我更愿意把它看作一张长期使用的书桌：一边放正在学习的技术，一边放生活里值得记住的小事。

为什么重新拥有一个博客#

平时接触到的知识很零散。一个报错的解决办法、一个组件的设计取舍，或者一次部署踩过的坑，如果只停留在聊天记录和临时笔记里，很快就会失去上下文。

博客给了这些内容一个更稳定的位置。写作也迫使我重新检查自己的理解：哪些只是“碰巧跑通”，哪些才是真正可以复用的方法。

Note

这里的文章会尽量区分事实、判断和个人偏好。能够验证的内容会给出过程，仍有不确定性的地方也会明确说明。

这里会写什么#

目前计划记录三类内容：

前端开发：Astro、组件设计、样式系统、性能和可访问性；
建站实践：静态博客、搜索、Nginx、HTTPS、发布与回滚；
生活随笔：那些不适合写成教程，却值得留下来的片段。

技术文章不会为了显得完整而虚构环境，生活内容也不会为了更新频率而勉强拼凑。比起追求数量，我更希望每一篇内容在一段时间后仍然对自己或读者有用。

关于这个小站#

本站使用 Astro 构建，界面基于 Firefly 主题定制。它最终会生成纯静态文件，由 Nginx 提供访问；站内搜索由 Pagefind 在构建阶段生成索引。

我保留了 Firefly 的开源署名，同时调整了配色、布局、字体和侧边栏，让它更像属于自己的空间。关于这部分的具体过程，会在后面的文章里慢慢展开。

如果你愿意持续关注，可以使用本站的 RSS 订阅。现在内容还不多，但这张书桌已经摆好了。

感谢来访，我们下一篇见。

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

Wed, 26 Aug 2026 09:00:00 GMT

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

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

先让配置与内容一致#

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

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

首页；
文章归档、分类与标签；
搜索；
关于页；
RSS。

其他页面继续保留代码能力，但通过 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，而是：

Terminal window

1
pnpm build

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

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

类型与内容 Schema 检查通过；
完整生产构建零错误；
首页、文章页、分类、标签和归档内容正确；
中文关键词能够被 Pagefind 搜到；
RSS、站点地图、404 和 canonical 地址正确；
桌面与手机、亮色与暗色模式都没有布局溢出。

保留主题能力，但不被主题牵着走#

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

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

把 Astro 静态博客部署到 Nginx：一次可回滚的上线记录

Wed, 26 Aug 2026 08:00:00 GMT

Astro 静态博客的部署看起来很简单：构建，然后把 dist 上传到服务器。但真正影响上线质量的，往往是这两个动作之间被省略的部分——搜索索引是否生成、路由是否正确、证书能否续期，以及出现问题时能不能迅速回到上一版。

这篇文章记录我为本站采用的发布思路。示例中的域名和目录均为通用占位值，不对应真实服务器信息。

先确认拿到的是完整产物#

本地环境固定使用项目声明的 Node.js 与 pnpm 版本，安装依赖时遵循锁文件：

Terminal window

1
pnpm install --frozen-lockfile
2
pnpm check
3
pnpm type-check
4
pnpm build

构建结束后，我不会只看退出码，还会检查几个关键文件：

1
dist/index.html
2
dist/404.html
3
dist/pagefind/pagefind.js
4
dist/rss.xml
5
dist/sitemap-index.xml

其中 Pagefind 最容易被忽略。Astro 页面构建完成不代表搜索索引已经生成，正式上线必须使用项目完整的 pnpm build。

Warning

如果刚删除过文章，旧的 Astro 数据缓存仍可能引用已不存在的内容。此时应清理项目构建缓存和 dist 后重新构建，而不是把不完整产物带到服务器。

服务器只接收静态文件#

站点采用本地构建、服务器托管的方式。服务器不需要安装 Node.js，也不上传源码、依赖目录或本地配置，只接收验证过的 dist 内容。

为了避免直接覆盖正在服务的目录，我把每次产物放进独立版本目录：

1
/var/www/example.com/
2
├── current -> releases/20260826-100000
3
└── releases/
4
    ├── 20260825-230000/
5
    └── 20260826-100000/

上传和解压都发生在新目录。确认首页、404、搜索、RSS 与站点地图齐全后，再原子切换 current：

Terminal window

1
ln -s releases/20260826-100000 /var/www/example.com/current.next
2
mv -T /var/www/example.com/current.next /var/www/example.com/current

这种结构有两个好处：切换瞬间不会出现“上传到一半”的页面，而且上一版仍然存在，回滚只需把软链接重新指回旧目录。

Nginx 要理解静态站点路由#

Astro 会为文章生成目录形式的页面，因此 Nginx 的站点根目录指向 current，并让路径依次匹配文件和目录：

1
server {
2
    listen 443 ssl http2;
3
    server_name example.com;
4

5
    root /var/www/example.com/current;
6
    index index.html;
7

8
    location / {
9
        try_files $uri $uri/ =404;
10
    }
11

12
    error_page 404 /404.html;
13
    location = /404.html {
14
        internal;
15
    }
16
}

展开收起

这里的 =404 很重要。若把所有未知路径都回退到首页，用户看似没有遇到错误，但搜索引擎和监控得到的状态码也是 200，真正的坏链接会被掩盖。

带哈希的 Astro 资源可以长期缓存，Pagefind 索引则保留较短缓存，方便文章更新后及时生效：

1
location ^~ /_astro/ {
2
    try_files $uri =404;
3
    expires 1y;
4
    add_header Cache-Control "public, immutable";
5
}
6

7
location ^~ /pagefind/ {
8
    try_files $uri =404;
9
    expires 1h;
10
    add_header Cache-Control "public, max-age=3600";
11
}

^~ 可以防止通用图片正则覆盖 _astro 的一年缓存规则。这是一个很小的配置细节，却会直接改变封面等哈希资源的缓存时间。

DNS 与 HTTPS 必须按顺序进行#

Let’s Encrypt 的 HTTP 验证要求域名已经指向目标服务器。因此顺序应该是：

先用 HTTP 配置验证新站点；
修改根域名与 www 的 DNS 记录；
从权威 DNS 和公共解析器确认记录生效；
申请同时覆盖两个域名的证书；
启用 HTTPS，并将 HTTP 与 www 跳转到正式根域名。

证书签发成功并不等于结束。Nginx 中的 ACME 验证目录必须与 Certbot 续期配置一致，最后还要执行一次续期演练：

Terminal window

1
certbot renew --dry-run

如果演练失败，就应该在上线阶段修复，而不是等证书临近过期时才发现问题。

验收不止是“首页能打开”#

我的上线检查分成四层：

内容：主页、文章、分类、标签、归档、搜索和关于页；
协议：HTTP 跳转、www 跳转、证书域名与有效期；
静态资源：Pagefind、RSS、站点地图、封面和长期缓存；
错误路径：不存在页面返回定制内容，同时保持真实 404 状态码。

另外还要检查 canonical 与站点地图中的域名，避免页面已经上线，SEO 地址却仍指向开发环境或旧域名。

回滚方案要在发布前存在#

发布完成后不要马上删除旧版本。若新版本出现阻塞问题，可以把 current 指回上一版并重新加载 Nginx；静态站点不涉及数据库迁移时，这种回滚通常很快。

只有在新版本稳定运行一段时间后，才清理更早的产物，并始终保留至少一个已经验证的旧版本。

这次上线让我更确定：静态站点降低了运行时复杂度，但没有消除发布工程。完整构建、独立版本、原子切换、真实 404、证书续期和可验证回滚，才共同组成一次真正完成的部署。