终于，Nami 驶出了港口

终于，Nami 驶出了港口 一个博客真正属于你的那一刻，不是代码写完的时候，也不是仓库创建成功的时候。 而是当你在浏览器里输入那个地址，页面真的出现在眼前。 今天，Nami Blog 终于成功部署了。 这篇文章不讲什么宏大的技术理想，只想认真记录一下：我们确实把它做出来了。 从一个简单的想法开始 最初的目标其实很朴素：做一个运行在 Cloudflare 上的轻量博客。 它不需要购买服务器，不需要维护复杂的运行环境，也不想依赖一大堆笨重的服务。前端交给 Cloudflare Pages，API 运行在 Cloudflare Workers，数据存放在 D1。 Astro 负责生成轻快的静态页面，Hono 负责 API，后台可以写文章、管理分类、标签、评论和站点设置。 听起来很简单。 但真正开始部署后才发现，“能在本地运行”和“能让互联网上的人正常访问”，中间隔着不少细节。 那些看起来很小的问题 本地开发配置一开始分散在 .env 和 .dev.vars 中。对于熟悉工具的人来说，这不算问题，但对于第一次接触项目的人来说，它意味着更多文件、更多概念，也意味着更多出错的机会。 所以我们重新整理了配置，让 API 和 Web 在本地统一读取根目录的 .env。 前端端口固定为 4322，API 端口固定为 8788。新用户只需要复制配置模板、安装依赖，然后启动项目。 部署文档也经过了几次调整。 什么时候填写 PUBLIC_API_URL？什么时候才能知道 SITE_URL？使用 Cloudflare 提供的 .pages.dev 地址时该怎么填？以后换成自己的域名，又应该改哪些地方？ 这些问题如果只站在开发者角度看，很容易一句话带过。但如果真的希望一个刚接触 Cloudflare 的人也能完成部署，文档就必须按照他实际看到页面和获得地址的顺序来写。 最后一块暗礁 部署过程中，我们还遇到了一个很有代表性的错误。 Cloudflare Pages 在仓库根目录发现了一套旧的 functions/ 代码，于是把它当作 Pages Functions 自动构建。那套代码早已被新的 Hono Worker 取代，却仍然留在仓库里。 结果就是构建日志里不断出现： Could not resolve "@/lib/auth" Could not resolve "bcryptjs" Failed building Pages Functions 刚看到这些信息时，很容易以为应该补依赖、修改路径别名，或者继续修复那套旧代码。 但真正的问题不是“旧代码缺少什么”，而是“旧代码为什么还在这里”。 最终，我们删除了已经废弃的 Pages Functions，让项目只保留一套明确的 API：apps/api 中运行在 Cloudflare Workers 上的 Hono 应用。 这个问题也提醒了我们：优化项目并不总是增加代码。有时最正确的修改，是删掉已经不该存在的东西。 部署成功意味着什么 从技术上看，这次部署完成了几件事： Astro 前端成功运行在 Cloudflare Pages； Hono API 成功运行在 Cloudflare Workers； D1 负责保存文章、评论和后台数据； 前端与 API 通过正确的 CORS 配置通信； SITE_URL 能生成正确的 SEO、Sitemap、RSS 和分享链接； 管理后台可以安全登录并维护内容； GitHub 的最新提交可以自动触发 Cloudflare 部署。 但对我来说，真正值得纪念的不是这张技术清单。 更重要的是，这个项目已经从硬盘里的一个文件夹，变成了互联网上真正可以访问的东西。 它有自己的地址，有干净的 Git 历史，有面向新手的文档，也有了第一篇文章。 这是第一篇航海日志 “Nami”这个名字本来就让人想到海洋、地图和航行。 部署过程也确实很像一次出航：配置是航线，文档是地图，日志是仪表盘，而每一次报错都是突然出现的暗礁。 我们绕过了一些弯路，也修正了一些一开始看起来理所当然的设计。好在每解决一个问题，Nami 就更稳定一点，也更容易被下一个使用它的人理解。 成功部署不是终点。 接下来还可以继续写文章、调整主题、完善交互、绑定自己的域名，让这个小小的博客慢慢长出真正属于自己的样子。 但今天可以先停一下，看看已经完成的这些事情。 Nami 已经驶出港口。 而这里，是它的第一篇航海日志。