IT资源栈这篇博客详述了一个发生在基于 TipTap 和 Yjs 的协同编辑器迁移项目中的棘手 Bug。在早期版本中，部分用户反馈编辑器会出现“停止保存”且没有任何报错的静默失败，导致刷新页面后内容丢失。经过排查，发现该问题由产品经理在使用特定 Emoji（如 🟢 和 🔴）组合时复现：当在两个多字节 Emoji 之间进行插入或替换操作时，底层的 CRDT 库 lib0 在处理字符串拼接（splice）操作时，错误地使用了 JavaScript 原生的 `.slice()` 方法。由于 JavaScript 内部使用 UTF-16 编码，Emoji 等字符通常由两个 16 位代码单元组成的“代理对”表示。`.slice()` 仅按代码单元截断，导致代理对被从中间切开，产生了无效的孤立代理。这个无效字符串随后被传递给 `encodeURIComponent`，触发了未被捕获的 `URIError`，进而导致 WebSocket 同步进程悄无声息地终止。文章深入解析了代码单元、码点和字素簇的区别，并介绍了修复方案：上游修复 lib0 以检测并替换孤立代理，以及通过 ProseMirror 将 Emoji 定义为原子节点类型。作者最后推荐使用现代 API `Intl.Segmenter` 来进行安全的字符串操作，以从根本上避免此类 Unicode 处理错误。
事件分析
该事件揭示了 Web 开发中长期存在的 Unicode 处理盲区，特别是在复杂的富文本编辑和实时协同场景下。JavaScript 语言设计的遗留问题使得 `String.prototype` 方法默认基于 UTF-16 代码单元而非用户感知的字素簇操作，这在处理多语言文本和 Emoji 时极易产生数据损坏。对于构建类似 Cursor 或 Notion 等现代编辑器的开发者而言，底层文本序列化库对边界的容错能力至关重要。Yjs 和 lib0 的修复表明，社区正在从单纯的文本存储向更严谨的图式原子化方向演进，即不再将文本视为简单的字节流，而是视为具有结构约束的节点树。此外，`Intl.Segmenter` 的出现为解决此类问题提供了标准化路径，未来有望成为新一代编辑器框架处理文本切分的基础设施。
💡 核心观点：看似简单的 Emoji 编辑实则是协同系统稳定性的“试金石”，底层字符串处理对 Unicode 边界的忽视往往是导致数据静默丢失的隐形杀手。
原文链接：Hacker News
评论前必须登录！
立即登录 注册