从 30 秒到 100 毫秒：我们如何让笔记通知「快」到感知不到

你有没有这种体验：在电脑上用浏览器扩展剪藏了一篇文章，然后切到手机 App 想继续阅读，却迟迟看不到刚才的笔记？

这是个小问题，但它困扰了我们很久。

30 秒，太慢了

在之前的版本里，MuseNotes 使用的是最传统的「轮询」方案——每 30 秒问一次服务器："有新笔记吗？"

这个方案简单、稳定、成本低。但对于一个追求极致体验的笔记应用来说，30 秒是一个让人抓狂的等待时间。你在浏览器里一键剪藏，然后盯着手机屏幕干等，感觉就像给朋友发了微信消息却迟迟不亮的已读。

我们决定把这个时间压缩到人类几乎无法感知的 100 毫秒以内。

实现这个目标，我们选择了 WebSocket + Cloudflare Durable Objects 的架构。

想象一下：

技术上，我们创建了一个名为 UserNotificationDO 的 Durable Object，专门为每个用户维护一条 WebSocket 长连接。当你在任何设备上创建新笔记时：

浏览器剪藏 → 笔记写入数据库 → 通知你的 Durable Object → 广播到所有连接的设备

整个链路耗时不到 100 毫秒。

更妙的是，我们使用了 Cloudflare 的 Hibernation API——当没有消息时，Durable Object 会"休眠"，几乎不消耗资源。只有当有新消息需要推送时才会被唤醒。这意味着实时推送不会增加你的使用成本。

当新笔记到达时，你会在笔记列表顶部看到一个浮动的提示横幅。

我们在设计这个横幅时纠结了很久：

要不要占用布局空间？ 不要。我们使用了绝对定位，横幅漂浮在内容上方，不会把你正在阅读的笔记往下挤。
要不要显示数量？ 要。"有新笔记" 和 "3 条新笔记" 给人的感受完全不同，后者更有紧迫感，也更能激发你点击的欲望。
点击后要刷新整个列表吗？ 不需要。我们只拉取那几条新笔记，然后插入到列表顶部。这就是「增量获取」的魅力——你可能有 100 条笔记，但我们只传输那 3 条新的。

既然说到「快」，我们顺手把归档和删除操作也优化了。

以前，当你点击「归档」时，流程是：

点击归档 → 发送请求 → 等待响应 → 刷新整个列表

现在变成了：

点击归档 → 笔记立刻消失 → 后台悄悄发送请求

这叫「乐观更新」——我们乐观地假设操作一定会成功，先让 UI 响应，再让网络去处理剩下的事。万一请求失败（比如网络中断），我们会把笔记恢复回来并给你提示。

这种设计让每一次操作都感觉「瞬间完成」，没有任何等待。

这次更新没有炫酷的新功能，只是把一些「本该如此」的体验做到位了：

有时候，好的产品不是「做了什么」，而是「让你感觉不到什么」。