随着云端折腾经验的不断丰富以及长线运营计划的推进，建立一个长期、可扩展的底层基础设施来承载内容与软件工具矩阵，变得尤为重要。传统的 VPS 建站虽然自由度高，但往往伴随着繁琐的服务器维护、环境配置以及续费焦虑。

今天这篇文章，我们将彻底转换思路，利用 Serverless 架构与 GitHub Actions 自动化流，手把手教你零成本、高可用地部署个人内容大本营——Rin 博客系统，以及一个全能的双模式工具导航枢纽。

⚖️ 避坑指南：开源项目的商用边界

在开始动手前，作为创作者必须理清这些底层框架的“商用”红线，避免未来流量做大后产生版权纠纷：

一、 核心底座：部署 Rin 博客系统

Rin 是一款极其轻量且专为 Cloudflare 生态打造的现代博客系统。它完全依赖 Cloudflare 提供的 Serverless 矩阵：Workers 提供后端计算，D1 承担数据库，R2 作为对象存储（图床）。

1. 准备源码与获取 CF 授权

首先，需要获取源码并赋予 GitHub Actions 自动化部署到 Cloudflare 的权限。

• Fork 仓库：前往 GitHub，访问 openRin/Rin 仓库，点击右上角的 Fork。
• 获取 Account ID：登录 Cloudflare 控制台，在页面右下方找到 账户 ID (Account ID) 并复制。
• 创建 API 令牌：进入 我的个人资料 -> API 令牌 -> 创建令牌，选择 编辑 Cloudflare Workers 模板。
  • 修改权限：保留 Workers 脚本 (Edit)、R2 存储桶 (Edit)、Cloudflare Pages (Edit)。
  • 新增权限：手动添加一项 D1 (Edit)。
  • 资源范围：在底部“账户资源”区域，选择 包括 -> 所有账户。创建并妥善保存这串 Token。

2. 配置 GitHub Secrets (机密环境变量)

为了让 Actions 能顺利建库和部署，必须将凭证存入仓库。进入你 Fork 的 Rin 仓库，点击 Settings -> Secrets and variables -> Actions，在 Secrets 下依次添加：

3. 配置站点信息与 R2 图床 (Variables)

Rin 博客的站点名称和图床依赖，推荐通过 Variables 固化，避免重新部署时设置丢失。

切换到 Variables 标签页，点击 New repository variable 依次添加：

• NAME: 你的博客站点名称（例如：mliaomcx）
• DESCRIPTION: 你的站点描述
• R2_BUCKET_NAME: 预先在 CF 创建的 R2 存储桶名称（填入后即可在后台正常上传图片）。

4. 触发自动化构建 & 绑定域名

• 进入 Actions 选项卡，启用工作流。
• 在左侧工作流列表中选择 build，点击右侧的 Run workflow 手动触发构建。
• 等待 3-5 分钟绿灯亮起，代码编译并推送到 CF 完成。
• 在 Cloudflare 控制台的 Workers 选项中找到新部署的 Rin 服务，进入 设置 -> 触发器 -> 自定义域，绑定你的专属域名即可开始创作！

二、 效率枢纽：双模式导航站方案

当你的 VPS 探针、软路由后台、云端面板越来越多时，我们需要一个集中的导航页。这里提供两种不同定位的部署方案。

方案 A：极致轻量的“发现导航” (xjh22222228/nav)

🚀 零成本极速部署“发现导航” (Cloudflare Pages 终极方案)

整个过程分为三个阶段：源码准备、配置自动化流水线、云端加速发布。

第一阶段：源码与权限准备（在 GitHub 操作）

1. Fork 原仓库
   • 打开 xjh22222228/nav 项目主页。
   • 点击右上角的 Fork 按钮，将项目复制到你自己的账号下。
2. 开启 Actions 的代码写入权限（极其重要）
   • 在你 Fork 过来的仓库中，点击顶部的 Settings。
   • 左侧菜单栏找到 Actions -> General。
   • 滚动到页面最底部的 Workflow permissions 区域。
   • 勾选 Read and write permissions，然后点击 Save 保存。
   原理说明：这能允许 GitHub Actions 稍后把编译好的网页代码，塞进你的仓库分支里。
3. 生成 GitHub 个人访问令牌 (PAT)
   • 点击 GitHub 页面右上角的个人头像，选择 Settings。
   • 在左侧菜单滑到最下面，点击 Developer settings。
   • 选择 Personal access tokens -> Tokens (classic)。
   • 点击 Generate new token -> Generate new token (classic)。
   • Note 随便填（如 Nav-Deploy），Expiration 建议选 No expiration（永久有效）。
   • ⚠️ 关键操作： 勾选 repo 和 workflow 这两个选项。
   • 滑到最底部点击 Generate token，立刻复制这串生成的 Token 代码（关闭页面就找不到了）。
4. 将 Token 配置为仓库密钥 (Secret)
   • 回到你刚才 Fork 的导航仓库，进入 Settings -> Secrets and variables -> Actions。
   • 切换到 Secrets 标签页，点击 New repository secret。
   • Name 填入：GIT_TOKEN （全大写，一字不差）
   • Secret 填入：你刚才复制的 Token 字符串。
   • 点击 Add secret。

第二阶段：触发自动化编译（在 GitHub 操作）

1. 必填核心配置（关乎构建能否成功）

• gitRepoUrl: 必须修改。
  • 作用：告诉后台 Actions 脚本构建好的文件该推送到哪个仓库。
  • 填写：https://github.com/你的用户名/nav。
• branch: 默认为 main。
  • 说明：这是你的源码分支，除非你 Fork 之后改了主分支名字，否则不用动。

2. 站点品牌化配置（关乎第一印象）

在文件的中后段（虽然你提供的片段里没写全，但原文件里有），还有几个至关重要的字段：

• title: 你的站点标题（显示在浏览器标签页上）。
• description: 网站描述，对于 SEO 非常重要。
• keywords: 关键词，方便搜索引擎收录你的 mliaomcx.com 相关矩阵。

3. 功能与存储配置（进阶玩家必看）

• imageRepoUrl: 推荐配置。
  • 深度解析：默认情况下，如果你在后台上传 Logo，图片会存在当前仓库。但长期运行建议新建一个公开仓库（如 image-host）专门存图。格式为：https://github.com/用户名/仓库名?branch=main。
• hashMode: 关键！
  • 设置：对于 Cloudflare Pages 或 GitHub Pages，请务必保持为 true。这能确保在刷新页面时不会出现 404 错误。

4. 静态部署可以忽略的字段（避坑指南）

你代码中看到的 address、password、port、mailConfig 等字段：

• 结论：在 Cloudflare Pages 这种“纯静态部署”模式下，这些配置项大多是无效的。
• 原因：这些是给“自有服务器（VPS）”部署方式准备的。静态页面没有 Node.js 后端环境，无法通过 SMTP 发送邮件，也无法通过这个 password 来保护静态文件夹。
• 注意：如果你需要保护后台，应该利用 Cloudflare 的 Access 功能或是 GitHub 本身的仓库权限。

这样处理后，你的 nav 就不再是一个简单的 Demo，而是一个具备生产环境稳定性的“内容枢纽”。在提交修改时，记得在 Commit 信息里写上 chore: update nav config，然后去 Actions 页面盯着那个绿灯亮起。

1. 等待自动化流水线完工
   • 代码提交后，点击仓库顶部的 Actions 选项卡。
   • 你会看到一个名为 deploy 的工作流正在转圈运行。
   • 等待约 1-2 分钟，直到它变成绿色的对号 ✔。
2. 检查产出物（非常关键的一步）
   • 回到仓库的 <> Code 主页。
   • 点击左上角的 main 分支切换按钮，查看下拉菜单。
   • 如果此时出现了一个名为 gh-pages 的分支，恭喜你，代码已经成功编译成纯静态网页了！

第三阶段：全网极速发布（在 Cloudflare 操作）

现在，我们要把装满网页成品的 gh-pages 分支交给 Cloudflare 去发布。

1. 创建 Pages 项目
   • 登录 Cloudflare 控制台，选择左侧菜单的 Workers 和 Pages。
   • 点击 创建 -> Pages -> 连接到 Git。
   • 选中你刚才配置好的 nav 仓库，点击 开始设置。
2. 配置构建指令（这里的设置决定成败） 在“设置构建和部署”页面，严格按照以下参数进行配置：
   • 项目名称： 随便起，比如 my-nav。
   • 生产分支 (Production branch)： ⚠️ 下拉选择 gh-pages（绝对不能选 main）。
   • 框架预设 (Framework preset)： 选择 无 (None)。
   • 构建命令 (Build command)： 保持 空白。
   • 构建输出目录 (Build output directory)： 保持 空白 或默认为 /。
3. 部署上线
   • 点击底部的 保存并部署。
   • 因为已经是静态文件，Cloudflare 几秒钟就能完成拉取和部署。页面会弹出一个由 .pages.dev 结尾的免费测试域名。
   • 访问这个域名，你的导航站就已经丝滑上线了！

🎉 后续维护： 以后你需要添加新网址或修改分类，直接去 GitHub 里修改 nav.config.yaml 文件即可。 只要你点下保存，GitHub Actions 就会自动帮你重新编译，Cloudflare 会在几十秒内自动把新网页同步到全球节点。完全不需要服务器，彻底解放双手！

方案 B：商业级表现的 WebStack 导航 (WordPress 修复优化版)

如果你有将导航站投入商业运营的打算，或者你的服务器上正好已经跑着 WordPress 环境，那我强烈推荐我在视频里顺带提到的 WebStack WordPress 修复版。

• 核心优势（安全与深度修复）：WebStack 虽然原生功能极其强大且全面，但原版主题代码中存在大量的历史 Bug 甚至是严重的安全漏洞（此前有不少采用原版主题的网站因此遭到黑客攻击）。我提供的这个修复版，对底层代码进行了彻底的排查与重构，堵住了已知的安全隐患，并修复了所有影响体验的 UI 错位和锚点失效问题。它不仅保留了大而全的专业功能，更赋予了站点真正达到商业交付标准的安全性。
• 部署方式：作为一款经典的 WordPress 动态主题，它的部署方式非常成熟。你只需要在你的 WordPress 后台找到 外观 -> 主题，直接上传这个修复版的源码压缩包并启用，即可拥有一个既专业又安全的高可用导航网站。(注：修复版主题源码见视频下方简介)

结语

至此，你已经拥有了一个基于 Serverless (Rin) 的内容发布中心，以及一个通过 GitOps 自动更新的工具导航矩阵。这种方案将底层运维压力全部交给了 Cloudflare 的边缘计算和 GitHub 的自动化流水线。

这种“免维护”的基建思路，让你能从繁琐的 Linux 环境配置中彻底解脱出来，将更多的时间专注投入到高价值的“技术输出”与“矩阵运营”本身。无论是在宿舍高强度折腾 AI 模型，还是管理分布在全球的 VPS 实例，这套底座都将是你最可靠的数字大本营。