自部署 |

CloudMail 自托管邮箱服务

Mon, 01 Jun 2026 00:00:00 +0000

弃用传统邮箱平台，用自己域名收发邮件的自托管方案：前端 Vue3 SPA、后端 Hono Worker，数据落在 D1/KV/R2，服务器成本为零。

概述

个人域名邮箱的需求很朴素：用自己的域名收发邮件、注册各类服务、随用随建隔离别名。商业邮箱平台按席位收费且数据在他方，传统自建（Postfix + VPS）又运维繁琐、IP 信誉难维护。CloudMail 把整套邮件服务搬进 Cloudflare 无服务器生态——一个域名、一个 Worker，就能拥有多邮箱、附件收发、管理后台的完整邮件服务。

核心功能

收件

多邮箱管理：一个域名创建多个邮箱，类似主流邮箱平台的多账户体验
附件接收：入站邮件附件自动转存 R2 对象存储，支持在线预览与下载
实时推送：新邮件可转发至 Telegram 机器人或其他邮箱，不错过任何验证码
验证码识别：Workers AI 自动从邮件中提取验证码，免复制粘贴

发信

Resend 集成：稳定送达率，支持群发、内嵌图片与附件
发送状态：每封信的投递状态可查，失败可追溯

管理与安全

RBAC 权限：按角色控制功能与资源配额，用户/邮件后台管理
人机验证：Turnstile 集成，防止批量注册
开放 API：批量生成用户、多条件查询邮件，便于自动化接入
数据可视化：ECharts 展示系统数据与用户邮件增长趋势

架构

┌─────────────┐ ┌──────────────────────┐
│ Email Routing│────▶│ Mail Worker (Hono) │
│ (CF 收件路由) │ │ API + 邮件处理 │
└─────────────┘ └──────┬───────────────┘
 │
 ┌────────────┼────────────┐
 ┌─────▼─────┐ ┌────▼────┐ ┌────▼────┐
 │ D1 (数据) │ │ KV(缓存) │ │ R2(附件) │
 └───────────┘ └─────────┘ └─────────┘
 ▲
 ┌───────┴────────┐
 │ Vue3 + Element │
 │ Plus 管理前端 │
 └────────────────┘

收件链路：Cloudflare Email Routing 接收入站邮件 → 投递至 Worker email 事件 → 解析 MIME、附件落 R2、正文落 D1 → 触发推送
分层后端：api/ 接口层、service/ 业务层、dao/ 数据访问层、security/ 认证鉴权，职责清晰
前端：Vue3 + Element Plus 响应式布局，PC 与移动端自适应

挑战与解决

邮件接收链路

问题：无服务器环境没有常驻 SMTP 服务，如何收邮件？

解决：利用 Cloudflare Email Routing 将域名 MX 收到的邮件直接投递给 Worker 的 email 事件，配合 MIME 解析库在边缘完成正文与附件分离，全程无需一台服务器。

附件存储与流量成本

问题：附件体积大，塞进数据库既撑爆 D1 又拖慢查询。

解决：附件与元数据分离——D1 只存索引，二进制内容进 R2，下载走预签名直链，边缘缓存降低回源。

验证码提取

问题：验证码邮件模板千差万别，正则规则维护不过来。

解决：接入 Workers AI 对邮件正文做智能提取，规则兜底为辅，验证码一键复制。

技术栈细节

后端

Cloudflare Workers + Hono：路由、拦截器、全局异常、i18n
Drizzle ORM 操作 D1（SQLite），KV 做缓存加速
Resend 发信，Email Routing 收信

前端

Vue3 + Element Plus 组件库
ECharts 数据可视化
Axios 统一请求层，Pinia 全局状态

安全

JWT 身份认证 + RBAC 鉴权
Turnstile 人机验证
自定义异常体系与错误码

成果

成本：Workers + D1 + KV + R2 免费额度内运行，零固定支出
隐私：邮件数据完全自持，不经过第三方邮箱平台
灵活：别名随用随建，注册服务时一键生成隔离邮箱
体验：验证码自动识别 + TG 实时推送，收验证码快过手机短信

后续计划

邮件搜索全文索引
日程/订阅邮件智能归档
自定义域名多域支持
移动端 PWA

项目状态：✅ 生产运行中
GitHub：
Demo：

SubsTracker 订阅提醒系统

Sun, 24 May 2026 00:00:00 +0000

一套自托管的订阅管理与到期提醒系统，部署在 Cloudflare Workers 边缘运行时上，用 KV 做持久化存储，零服务器成本管理域名、会员、账单等各类订阅的到期提醒。

概述

日常订阅的服务越来越多——域名、云服务、会员、保号套餐——散落在各个平台的续费日期很难手动追踪。SubsTracker 提供了一个网页管理后台统一录入订阅，由 Cloudflare Cron Triggers 每小时整点检查，命中提醒规则时自动通过即时消息渠道推送，避免因忘记续费导致服务中断。

核心功能

订阅管理

增删改查：名称、周期、金额、分类、备注一目了然，支持克隆同构订阅
两种续订模式：循环订阅（从当前到期日顺延）与到期重置（从支付日重新起算），覆盖会员续费和充值重置两类场景
周期灵活性：季度/半年/年快捷选项、公历"每月最后一天"、农历周期
支付记录：手动续订时记录支付历史，配合仪表盘统计多币种支出

提醒调度

多规则提醒：默认预设到期前 7/3/1 天与到期当天，每条订阅可自定义多条规则
精确日语义：仅在剩余天数正好等于 N 的当天发送一次，配合去重机制避免重复打扰
发送时间窗口：可配置允许发送的小时（如仅早 8 点），按时区判断，非窗口整点正常跳过
到期后追偿：支持"到期后每隔 X 小时提醒，直到续费"

消息渠道

Telegram（支持群话题 Topic）、Bark、企业微信、ntfy、Resend 邮件、Webhook、Gotify、Server酱、PushPlus、NotifyX 共 10 种渠道，任意勾选组合，每渠道可一键发送测试通知。

可观测性

通知历史：每条发送的成功/失败明细与错误原因
调度日志：命中、去重、跳过的完整链路记录，排查"为什么没收到"不求人
/debug 诊断页：时区与通知窗口实时检查

架构

┌──────────────┐ ┌───────────────────┐ ┌─────────────┐
│ 管理后台(SPA) │────▶│ Worker (Hono) │────▶│ KV 存储 │
└──────────────┘ │ API + 定时调度 │ └─────────────┘
 └─────────┬─────────┘
 │ Cron Triggers（每小时整点）
 ┌─────────▼─────────┐
 │ 通知服务（10 渠道）│
 │ Telegram/Bark/... │
 └───────────────────┘

入口：fetch 处理网页与 API 请求，scheduled 处理定时调度
分层设计：core/（时间、农历、货币、JWT）、data/（KV 与迁移）、services/（调度器与渠道）、api/（路由）、views/（管理端页面）
数据迁移：首次访问自动执行 KV 结构迁移，升级无感

挑战与解决

时区一致性

问题：Cron 按 UTC 触发，“到期前 3 天"“早 8 点发送"的判断若按 UTC 理解会整天偏移。

解决：所有调度判断统一收敛到配置时区（如 Asia/Shanghai），配置页提供实时预览（当前会发/不会发），并有 /debug 页面诊断时区与窗口。

通知可靠性

问题：用户常反馈"没收到通知”，可能原因横跨渠道配置、时间窗口、规则命中、去重四层。

解决：把每次调度决策落盘——通知历史记录发送结果与错误详情，调度日志记录命中/去重/跳过原因，配合 FAQ 排查路径，让每次"没收到"都能定位到具体一层。

零成本持久化

问题：Workers 无本地磁盘，传统数据库在免费额度内成本高。

解决：采用 Cloudflare KV 单键 JSON 文档存储，配合结构版本迁移与 JSON 备份导入导出（合并/覆盖两种模式），免费额度内即可长期稳定运行，数据随时可迁移。

技术栈细节

运行时

Cloudflare Workers 边缘运行时，全球就近响应
KV 低延迟读、最终一致性写，契合订阅场景

框架与工程化

Hono 轻量 Web 框架，路由与中间件
Vitest + workerd 单元/集成测试
GitHub Actions 自动化 CI
第三方通知 API 令牌，便于外部系统接入

成果

成本：完全运行在 Cloudflare 免费额度内，零固定支出
可靠性：整点调度 + 去重 + 失败明细，漏发/重发可追溯
可移植：JSON 备份一键迁移，不锁定平台
可扩展：10 种渠道抽象统一接口，新渠道接入成本低

后续计划

支出趋势图表
日历视图
更多币种汇率源
PWA 离线查看

项目状态：✅ 生产运行中
GitHub：
Demo：

MoonTV 影视聚合播放器

Fri, 18 Jul 2025 00:00:00 +0000

开箱即用的影视聚合播放器：输入片名一次搜索，聚合数十个免费资源站的结果，直接在线播放，收藏和观看进度跨设备同步——自托管，全端适配。

概述

看片资源的痛点从来不是"没有源"，而是源太散：不同资源站各自搜索、画质参差、进度互不相通。MoonTV 用一个 Web 应用把这些源聚合起来——前端 Next.js 14 App Router + Tailwind CSS，播放器集成 ArtPlayer 与 HLS.js，存储层抽象出 localStorage / Redis / Cloudflare D1 / Upstash 四种后端，从单机自用到多账户同步都能覆盖。

核心功能

聚合搜索

多源并发：内置数十个免费资源站，一次输入立刻返回全源结果
详情聚合：剧集列表、演员、年份、简介等完整信息一页展示

播放体验

HLS 流媒体：HLS.js 处理 m3u8 切片，ArtPlayer 提供统一的播放控制
智能去广告：自动跳过视频中的切片广告（实验性）
播放记忆：继续观看自动定位到上次进度

数据同步

多账户隔离：账号体系下各用户收藏、播放记录互不干扰
跨端同步：Redis / D1 / Upstash 云端存储，手机、平板、电脑进度无缝衔接
管理后台：站长可管理用户与站点配置

多端适配

响应式布局：桌面侧边栏 + 移动端底部导航
PWA：离线缓存、安装到桌面/主屏，移动端接近原生体验
AndroidTV：适配电视端使用场景

架构

┌────────────────────────────────────────┐
│ Next.js 14 (App Router) │
│ 搜索聚合页 │ 详情页 │ 播放页 │ 管理后台 │
└───────────────┬────────────────────────┘
 │ 存储抽象层（统一接口）
 ┌────────────┼────────────┬────────────┐
┌──▼─────┐ ┌────▼───┐ ┌──────▼───┐ ┌──────▼─────┐
│localSt.│ │ Redis │ │ CF D1 │ │ Upstash │
│(单机) │ │(Docker)│ │(CF Pages)│ │(Vercel) │
└────────┘ └────────┘ └──────────┘ └────────────┘

存储抽象：四种存储后端实现同一套数据接口，按部署环境选择，业务代码无感知
资源站配置化：config.json 声明采集源，增删源不改代码
部署矩阵：Docker（含 Redis 全家桶 Compose）、Vercel（Upstash）、Cloudflare Pages（D1 + nodejs_compat），各自有最佳实践文档

挑战与解决

多源搜索的延迟与稳定性

问题：数十个资源站并发请求，慢源会拖垮整体响应，个别源宕机还会报错。

解决：并发聚合 + 单源超时熔断，单个源失败不影响其余结果返回，全局错误指示器提示降级状态。

四种存储后端的统一

问题：localStorage、Redis、D1、Upstash 的数据模型与能力差异大，逐处 if/else 会迅速腐化。

解决：抽象出统一的存储层接口（收藏、播放记录、用户），各后端独立实现，部署时通过 NEXT_PUBLIC_STORAGE_TYPE 一个环境变量切换。

跨平台播放兼容性

问题：浏览器、移动端 WebView、电视大屏对 HLS 与编解码支持参差。

解决：HLS.js 统一处理 m3u8 拉流与分片调度，ArtPlayer 抹平各端播放器 UI 差异，PWA 与响应式布局覆盖剩余的端侧差异。

技术栈细节

前端

Next.js 14 App Router + TypeScript
Tailwind CSS 3 响应式主题
ArtPlayer + HLS.js 播放内核

存储

localStorage：零依赖单机模式
Redis（Docker 自建）/ Upstash（Serverless）：多账户同步
Cloudflare D1：Pages 部署的配套数据库

工程质量

ESLint + Prettier + Husky 统一规范
Jest 单元测试
GitHub Actions 自动构建，Docker 镜像多架构发布

成果

聚合：一次搜索覆盖数十个资源站，找片效率数量级提升
同步：收藏与进度跨设备无缝衔接，换设备不用重找进度
成本：Vercel / Cloudflare 免费额度可跑，Docker 版单容器即可
体验：PWA 安装到主屏，移动端接近原生 App

后续计划

弹幕功能
更多存储后端
播放画质偏好记忆
资源站健康度监测面板

项目状态：✅ 生产运行中
GitHub：
Demo：