Ghost 还是 Astro？一个双语个人网站从选型到上线的实践指南

搭建个人网站，最容易花冤枉钱的阶段，可能发生在购买服务器之前。

你准备写文章，于是开始研究 CMS；想做邮件通讯，于是比较会员系统；想到未来可能卖产品，又开始挑选支付工具和营销自动化服务。等这些功能比较完，第一篇文章还没发布，网站已经背上了一个小公司的配置。

我搭建 Hammersmith · 打铁客时，也是一样。

最初的计划是购买两台 VPS：一台运行 n8n 和数据库，另一台部署 Ghost。后来，我重新梳理需求，最终采用了：

Astro 双语主站＋GitHub 版本管理＋Cloudflare Pages 托管＋Kit 免费邮件通讯。

这篇文章整理选型依据，以及从内容规划到域名、邮件和搜索接入的实际做法。它适合希望同时发布文章、积累方法、展示工具和项目，又暂时不以付费订阅为核心的个人创作者。

本文的搭建结果以 2026 年 10 月 22 日首次上线验收为准，价格于 10 月 23 日核验。双语页面、订阅确认和退订流程已经验证；长期访问表现、订阅增长和收入效果，还需要继续观察。

一、先确定网站的任务，再比较 Ghost 和 Astro

让我改变选型的三个需求

我已经有域名 lens78.cn，也有一些文章和原则。真正需要解决的是：怎样把这些内容组织成一个可以持续更新的公开网站。

梳理之后，需求集中在三件事：

第三条直接改变了我的选型。

此前，我一直在为“以后可能需要”的收费订阅、自动营销序列和销售漏斗比较成本。重新看自己的阶段，这些功能还没有明确的商品或服务可以承接。

于是，第一版的范围收到了一个更具体的目标上：

让读者能够阅读我的内容、找到真实实践，并自愿订阅后续更新。

Ghost 与 Astro 应该怎样比较

Ghost 是一套出版系统，把编辑、网站发布、会员和邮件通讯组织在一起。Astro 是网站框架，网站结构和发布流程需要自己搭建，邮件等能力再连接外部服务。两者解决问题的方式不同。Ghost 官方介绍

我的选择依据，是愿意怎样长期维护网站。

如果你希望主要精力放在编辑后台里，持续写作、发信和经营会员，Ghost 值得优先考虑。

如果你希望网站同时是文章库、方法库和作品集，愿意使用 Git 维护页面，Astro 就有吸引力。

我选择 Astro，也接受了文件编辑、构建检查和多服务配置这些工作。

二、第一版架构与成本

本站的内容发布和邮件订阅，分别沿着图中的路径完成。Notion 保存写作母本，网站版本经过适配和检查后发布；读者通过网站进入 Kit 订阅流程。

这样做之后，主站不需要额外租用 VPS，现有 n8n 和数据库也不必参与网站运行。

代价是服务之间存在连接处：域名与托管需要连接，网站表单与 Kit 需要连接，发件地址也需要单独验证。后面的困难，大多就发生在这些地方。

与 Ghost 相比，起步成本差在哪里

为了便于比较，下面只算建站与通讯服务费用。各方案都继续使用已有域名，因此域名续费不计入差额；AI 工具和人工投入也不计入这张服务费用表。

价格依据：Ghost(Pro) 定价、Kit 定价、Cloudflare Pages 免费档限制。Ghost 的数值是年付折算价，会员数量、计费周期和税费会影响实际账单；免费服务也需满足各自的计划条件。

对我而言，第一阶段暂时用不到付费会员，也不需要一个统一的出版后台。采用现有免费服务，可以先把每年 216—348 美元的 Ghost(Pro) 基础套餐支出留在后面，再根据实际使用决定是否值得付费。

如果统一后台能明显节省你的编辑和维护时间，这笔费用也可能很划算。Ghost 自托管则需要单独核算，不能只拿“软件免费”与托管套餐总价比较。

三、内容规划：用真实材料填满最小结构

栏目要让读者知道能找到什么

“打铁客”可以有鲜明的品牌意象，但导航仍然需要容易理解。

我保留了文章、原则、实践和通讯等直观入口，把 Lifesmithing——人生锻造术——放在方法介绍中展开。

起步材料不必很多，但要有完整用途

本站首批只准备了两篇文章、两条原则和一个 FreshRSS 案例，再分别制作英文版本。

文章让读者了解我的思考方式，原则把个人感想整理成可讨论、可应用的判断，FreshRSS 则展示一次真实构建，并补充本地 Docker 安装说明。

我当时没有正式完成的商业 MVP，因此没有为作品集编造“成熟产品”。已有工作流足以作为案例，前提是讲清楚解决了什么问题、怎样实现、验证到了哪里。

对于项目页，我建议至少交代六件事：问题、使用对象、实现方式、关键取舍、已验证结果、当前限制。

这些信息比一张漂亮截图更能帮助读者判断，项目是否与自己有关。本站的 FreshRSS 阅读工作流就是按照这个方向整理的。

双语内容要建立明确的配对关系

本站的中文和英文使用独立文件，共享同一个 contentId：

src/content/
├── essays/
│   ├── eight-atoms.zh.md
│   └── eight-atoms.en.md
├── principles/
│   ├── connected-points.zh.md
│   └── connected-points.en.md
└── projects/
    ├── freshrss-reading.zh.md
    └── freshrss-reading.en.md

每篇文件开头包含元信息，例如：

---
contentId: connected-points
lang: zh
section: principles
title: "优先在关键连接点发力"
description: "寻找能够同时改善多个环节的行动位置。"
draft: false
reviewed: true
---

这里的 draft、reviewed 是本站自己定义的发布控制字段。只有通过本站筛选条件的内容，才会进入页面、RSS 和站点地图。

中英文配对之后，还要实际检查语言切换：中文文章应跳到同一篇英文文章，译文尚未发布时要明确提示。

翻译也需要人工审阅。数字、操作步骤、事实和项目状态尤其不能因为换了一种语言就发生变化。

四、品牌设计：先确定表达，再检查阅读体验

本站最后确定为 Hammersmith · 打铁客，副标题是：

一个每天用代码和文字挥锤锻造自己的人。

这个过程经历了改名，也经历了配色调整。

最初采用深色背景，想突出铁与炉火的感觉。实际看过页面之后，我觉得太黑，最终恢复暖白底，保留深色文字和少量铜锈橙。

这次调整给我的经验是：品牌意象可以很强，阅读体验仍然要单独检查。长文章、代码块、手机屏幕和订阅表单，未必都适合首页效果图里的颜色。

五、搭建与上线：把本地、预览和正式环境分开

先让本地版本通过检查

本站先完成本地版本，再连接云端。主要检查了中英文页面和同篇语言切换、手机下的长文与导航、代码块与复制功能、图片和内部链接，以及品牌、RSS、站点地图和错误页面。

构建流程也包含自动检查。本站的 build:check 会依次执行 Astro 检查、静态构建和已有测试。

这里有一个实际遇到的问题：本机系统 Node 版本不满足项目要求。解决时使用了本机已有的兼容运行时，没有为了一个网站直接替换全局环境。

对新项目而言，应按所用 Astro 版本的要求安装 Node，并让本地与云端构建环境保持一致。

再连接 GitHub 与 Cloudflare Pages

本站使用 GitHub 私有仓库保存代码，Cloudflare Pages 连接该仓库。

build:check 是本站自己配置的脚本；其他项目应使用自己实际存在的构建命令。Cloudflare 的 Astro 部署文档提供了相应配置入口。官方部署说明

推送代码以后，还要检查云端构建结果。GitHub 收到提交，只能证明代码上传了，不能证明新网站已成功部署。

最后切换正式域名

我的域名以前使用过，因此先备份原 DNS，再调整与网站有关的记录，保留邮件和其他服务所需记录。

上线时完成了：

1. 在 Pages 中绑定 lens78.cn。
2. 按控制台要求配置网站 DNS。
3. 核验正式域名的 HTTPS。
4. 将 www 和正式 pages.dev 地址跳转到主域名。
5. 保留分支预览入口。
6. 检查旧文章链接的跳转，以及未知地址的真实 404。

六、邮件接入：表单出现以后，还要走完确认与退订

先区分收信与发信

本站使用两种服务处理不同方向的邮件：

Email Routing 负责处理或转发来信。配置转发后，并不会自动得到一个可以从 Gmail 任意使用 hello 地址发信的完整邮箱；一对一发信还需要另行配置。Cloudflare 官方说明

中英文分别建立订阅入口

本站在 Kit 中建立中文、英文两个表单，分别嵌入对应语言的通讯页面，并开启订阅确认。

这样，发信时可以按表单归属选择语言受众，不需要通过姓名、国家或邮箱后缀猜测读者语言。

同时订阅两种版本的人，可以收到两种通讯；只订阅中文的人，则不应因为后台默认选中了全部订阅者而收到英文邮件。

这次真正卡住的，是账号审核

首次测试时，订阅记录已经出现在 Kit，确认邮件却没有收到。

继续检查才看到，账号部分功能仍被限制，需要完成审核沟通。我们和 Kit 客服沟通，说明网站用途、订阅来源，并在品牌更名后补充对应资料。

审核通过以后，重新从正式网站提交中英文测试订阅，两封确认邮件才真正送达。

这个问题留下了一套可复用的排查顺序：

把“退订成功”也列入验收

本站最后走完了四步：提交订阅 → 收到确认信 → 点击确认 → 退订并核对状态。

中文测试保留，英文测试退订。后台结果与操作一致，才把订阅流程记为验收完成。

第一次看到这两封带着 Hammersmith 署名的邮件进入收件箱，我才真正放松下来。此前已经看过很多页面和配置，这一次终于看见了读者会经历的完整过程。

七、搜索接入：先做到可访问、可理解、可检查

我在选型时就考虑过 SEO 和 GEO，但第一版没有围绕这些词额外堆砌功能。

Google Search Console 通过 DNS 验证，Bing 也通过 DNS 完成了所有权验证。

首次上线记录中，Google 已成功处理站点地图，显示发现 27 个页面；Bing 已接收站点地图，处于处理中。这些是当时的验收结果，不能直接写成“全部收录”。

对于 AI 搜索，也没有必要承诺某个框架天然具备排名优势。Google 对自身 AI 搜索功能的说明是，既有 SEO 基础仍然适用，并没有额外的专用优化要求。Google 官方说明

我的内容侧做法是：把问题讲具体，提供真实步骤和验证依据，明确结论的适用条件。以后再根据实际搜索与引用数据调整。

八、上线后怎么维护，决定这套方案是否真的省事

本站目前的维护流程是：整理材料 → 更新中英文文件 → 本地或分支预览 → 确认 → 推送正式分支 → 核验线上页面。

我在 Notion 撰写初稿，然后补足材料成为母本。后续无论是发布到 X 长文还是个人主站，都是依据母本来适配文章格式和要求的。

当前没有开启 Notion 到网站的自动同步。母本修订后，需要把相关变化落实到网站版本，并同步检查英文内容。

第一版也有尚待完善的地方。例如，列表目前按内容标识排序，首页项目推荐仍固定为 FreshRSS。后续扩充内容时，需要继续核对栏目呈现与检查规则。

Kit 的邮件发送和网页发布是分别控制的；在 Kit 发布网页，也不会自动更新 Astro 主站。Kit 官方操作说明

九、这次建站，真正值得复用的选择

如果重新做一遍，我仍然会先写清楚网站的当前任务。

双语内容、原则积累、项目展示和免费通讯，这几个需求足以支撑第一版。付费会员、销售漏斗和复杂自动化，可以等真实商品或服务出现以后再决定。

我也会更早准备几份真实内容。页面放进实际长文、代码和项目说明之后，布局、配色和栏目是否合适，很快就能看出来。

首次上线验收时，网站已经能够阅读、订阅，也完成了搜索服务接入。那时正式通讯尚未发出，长期效果仍然等待后续内容来证明。

完成它的喜悦很具体：原来那个基本荒废的域名，现在有了我的文章、原则和实践；下一次做出一个工具，或者修正一个判断，我知道该把它放到哪里。

Hammersmith · 打铁客的首页写着：

一个每天用代码和文字挥锤锻造自己的人。

网站已经上线。接下来，该继续往里面放值得留下的东西了。