Marco：隐私优先、离线优先的基于 IMAP 的邮件客户端
Source: Dev.to
它是如何开始的
我去年从 Android 换到 iPhone，并把自定义域名的邮箱从 Gmail 迁移到 iCloud。这意味着要使用 iOS 和 macOS 上的 Apple Mail 应用。几周后，我遇到了糟糕的用户体验，并发现 iOS 版 Apple Mail 的邮件字体大小与 macOS 版不同（且不可配置），于是开始寻找替代方案。我花了两周时间评估了能找到的每一个邮件客户端。它们全部可以归为三类：
- 传统且难看
- 免费但会出售你的数据
- 真正优秀但每年要花 250 英镑以上
我很想用 Superhuman，但我无法为个人邮件 justify 那么高的费用。市场上有空白，而似乎没有人填补它。
邮件客户端的坟场
我们研究得越多，发现的死亡邮件创业公司就越多——Tempo、Big Mail、Caley.io，以及无数被放弃的开源尝试。大多数公司只能存活 1–2 年。导致它们倒闭的两大原因：
- 构建邮件客户端的复杂度极高。
- Google 对邮件范围的 OAuth 安全审查费用高得惊人。
为什么 IMAP‑first 很重要
几乎所有邮件创业公司都基于 Gmail API。虽然方便，却把你锁定在 Google 生态。我们采用了 IMAP‑first，这保证了与世界上几乎任何邮件提供商的互操作性。IMAP 也很古老、怪异且充满边缘案例——既有乐趣，也有大量学习成本。
离线优先的漫长旅程
这几乎把我逼疯。我们在早期就承诺要实现完整的离线支持（在没有 Wi‑Fi 的飞机上阅读、回复、删除、整理邮件）。听起来很直接，直到你意识到 Marco 需要处理数十万条实体和每个账号 100 MB 以上的数据。
在大约三个月的时间里，我们尝试了五种离线‑first 方案：
WatermelonDB
- 最初可用，但使用内存中的 JS 数据库（LokiJS）来规避 IndexedDB 的性能问题。
- 将 100 MB+ 的数据库放在内存中……并不理想。
- 维护进度放慢。
Triplit
- 开发者体验一流，API 真是太棒了。
- 订阅在不足 10 万实体时就会超时；我们多次把他们的服务器压垮。
- 仍然为这个团队加油。
InstantDB
- 没有 TypeScript 类型、没有排序/顺序、没有 webhook。
- 在 WatermelonDB 中 2–5 ms 的查询，在这里要耗时 200–500 ms。
- 产品自此改进了很多，许多问题似乎已经解决。
PowerSync
- 纸面上最成熟的选项。
- 自托管需要在 Postgres WAL 集成之上再部署一个 MongoDB 副本集。
- 前端在线程之间以 JSON 序列化所有数据，导致渲染 50 封邮件耗时 200 ms+。
Replicache
- 最终找到了合适的方案。它只是基于 IndexedDB 的 KV 存储——没有巧妙的关系层，也没有图模型。
- 超快。我们在其之上构建了自定义的内存索引层来处理查询。
- 完全开源；概念上类似 WatermelonDB，却没有内存占用的缺点。
根本原因： 所有离线‑first 的网页方案最终都是在 IndexedDB（仅键值存储）之上进行的 hack。把关系模型套在 KV 存储上在 10–50 k 行左右就会开始崩溃，而我们的数据量是几百万行。
我们现在的状态
- 超过 2,000 名自然增长用户
- 自主创业（无 VC）
- 支持 iOS、macOS 和 Web
- 技术栈：React Native、Expo、TanStack DB/Query，后端使用 Postgres
- 隐私优先：我们不出售数据，也不为广告扫描邮件
我是一名三次创业者，曾任 CTO。虽然我之前也构建并扩展过产品，但邮件是我碰到的最难的领域。正如邮件社区的一位朋友对我说：“从事邮件的人很少，但想要有人在做邮件的人却很多。”
欢迎随时提问，关于 IMAP、离线‑first 架构、邮件客户端生态，或其他任何话题。