这个项目本身是一个 Web 业务，后来用 Capacitor 封装成了 App。登录这块 OAuth 已经在 Web 端跑通了，所以最初的设想很顺理成章：App 里不做登录，直接复用 Web 的 OAuth。

流程设想是：App 跳转到 OAuth 授权 → 用户登录 → 授权服务 redirect 回 callback URL → App 接管，处理登录态。

前面几步都没问题，Web 实现完全够用。问题出在最后一跳。

之前写过一篇《一个比较诡异的部署逻辑》，记录的是一段很折腾的历史：为了绕开备案，域名解析到一台海外 vps，再由 nginx 反向代理到内地另一台机器上的 hugo 服务。绕了一大圈，代价是要自己盯着一台可能 OOM 的机器。

现在这套折腾终于可以收掉了，整个链路简单到有点无聊。

在最近做一个 App 的内容审核功能时，我发现了一个挺有意思的模式：

有些简单的 Admin 操作，其实根本不需要做一个 Admin Dashboard。

如果管理员只是偶尔收到一些待处理事项，然后对某个具体对象执行几个简单操作，那么 Email 本身就可以成为一个非常轻量的 Admin UI。

一个实际的例子

在这个项目里，有两个比较简单的后台业务。

Story 审核

用户提交一条 Story：

User
  ↓
POST /api/feedback
  ↓
feedback.status = pending

服务器在几十秒内把待审核 Story 发到管理员邮箱：

📖 New community story #123

John:
"I finally reached my goal..."

[ Approve ]    [ Reject ]

树莓派摄像头直播，尝试了多种方案，记录一下。

🚀 核心工具简介

调试iOS应用的时候，编译成功，安装app到设备也成功，启动app也成功，但Xcode自动结束调试，报错如下：

Could not attach to pid : “20860”

attach failed (Not allowed to attach to process.  Look in the console messages (Console.app), near the debugserver entries, when the attach failed.  The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.)

虽然不想说，但这次部署的方式确实有点难受的。

之前博客部署在DO的vps上，但这台机器资源比较有限，经常会碰到运行一段时间后因为OOM被系统干掉的情况。

然后想说部署在aliyun的机器上，但问题是域名解析过来，需要进行个人备案，我不太想这么操作，避免后续某个时间这个域名不用的时候，备案还在我的名下。

我还有另外一台机器，也不需要备案，资源也算充裕，但问题是那上面运行的服务后续可能会膨胀，如果不膨胀，大概率是要删除的，又不稳定。

嗯，背景就是上面讲的这样。于是一个很诡异的逻辑诞生了：

在aliyun的机器上部署hugo运行服务，开放端口；博客域名解析到DO的vps上，流量通过nginx转发到阿里云的机器上。

其实是第二次折腾hugo了，但还是踩了一些坑，浪费了挺多时间。

版本问题

linux下特别是ubuntu下，apt安装的hugo版本比较旧，记得使用github的release里面，安装最新的版本。