熟悉的界面隐藏着多个系统

收件箱是一种很有说服力的表象。发件人、主题和日期排成一行，让产品看起来像一个简单的数据库应用。对小型产品工作室来说，难点在于让这一行在不同服务商、设备以及相隔数十年的邮件中依然可信。界面紧凑，是因为它隐藏了内部机制，而不是因为机制简单。

邮件通过不同标准逐步发展，而非依靠一套应用契约。SMTP负责邮件服务器之间的传递，IMAP让客户端访问和管理邮箱，MIME描述正文的媒体类型和编码。混淆这些职责，就容易夸大新客户端或协议能解决的问题。 SMTP (RFC 5321), IMAP4rev2 (RFC 9051) 和 MIME (RFC 2045).

兼容性成为产品行为

邮件不只是UTF-8段落加一个附件。它可能包含嵌套的多部分结构、纯文本与HTML备选正文、经过编码的头部，以及需要解释的附件文件名。一次显示决策可能决定旧收据是否仍可阅读；解析器中的捷径可能让熟悉的邮件变成空白预览。历史上的多样性成为今天界面的责任。

邮箱状态同样分布在多处。电脑离线时，用户可能在手机上读过邮件，另一个客户端又将它移动。某些服务商用邮箱模型表达标签。应用必须协调邮件身份、归属和标记，不能把每个差异都当成新邮件。进度显示“完成”也必须有可以验证的含义。

先设计恢复，再打磨顺畅流程

IMAP并没有停留在最初的版本。现代IMAP及其扩展也支持更高效的同步。实际工作是发现服务器支持哪些能力，并实现产品所需的路径。兼容性涉及服务器行为、认证、网络中断和本地持久化，不是旧缩写与新缩写之间的竞赛。

对工作室而言，工作顺序很具体：将传输和解析与本地模型分离，保留特殊邮件作为测试样本，让中断的任务可以继续。区分“尚未下载”和“服务器上不存在”。测试删除与重连时，应像首次导入一样认真。这些工作很少出现在发布截图中，却决定了截图里的界面能否让人信赖。

更清晰的协议契约为产品留出空间

MailVault的开发也让这个边界显得重要。改善客户端与服务器之间的对话，可以减少协调工作；可靠地在本地保存邮件仍是独立的工程任务。真正的问题是：哪些复杂性应由协议契约承担，哪些仍属于应用。

配套文章 JMAP与现代邮件应用的架构从这一角度讨论JMAP。MailVault的 为什么邮件仍然复杂则面向用户解释这段历史。更好的协议能让开发者更专注于可靠行为，但不会抹去邮件长期积累的历史。