一个 Cloudflare 域名邮箱系统，应该怎样拆分职责

域名邮箱是一个很适合练习 Serverless 架构边界的场景：它同时涉及 HTTP 服务、邮件接收、数据持久化、认证、静态前端和第三方发信。

研究 Cloud Mail 时最有价值的不是某个部署命令，而是职责拆分。

组件各做一件事#

一个简化的架构可以这样划分：

这个划分的重点是：不要把 KV 当成通用数据库。KV 的读性能很好，但高频写入会受到额度和一致性模式的约束。长期记录、计数和可查询业务数据，更适合进入 D1。

入站邮件通常是：DNS/MX → 邮件路由 → Worker 邮件处理器 → 元数据写入 D1 → 附件进入对象存储 → 前端通过 Worker 查询。

出站邮件则是：用户操作 → Worker 鉴权与限流 → 写入发送记录 → 调用发信服务 → 接收状态回调。

把入站和出站分开理解，会更容易设计错误重试、配额控制和日志追踪。

每日计数、登录状态或轮询结果如果每次都写 KV，很容易消耗掉免费额度。应该通过批量、缓存窗口或迁移到更适合的存储来控制写入。

邮件服务会接触 API Key、域名配置和用户身份信息。它们只应存在于平台 secret 或本地环境变量中，不能写入仓库、文档或客户端代码。

邮件事件天生异步。至少应保留可关联的事件 ID、状态和错误摘要，避免用户只看到“发送失败”却无法定位发生在哪一层。

Serverless 的优势不是“没有服务器”，而是让每个组件的职责和成本更透明。前提是你不要用一个存储或一个 Worker 硬塞所有事情。