真正影响体验的是这个 - 一起草｜网页版这件事；我试了三种方法才搞明白！十个里九个都错在这

真正影响体验的是这个 - 一起草｜网页版这件事；我试了三种方法才搞明白！十个里九个都错在这

我做网页版“一起草”这类实时协作编辑器已经好一阵子了。上线前我像大多数人一样把注意力放在功能表、实时光标、权限、版本历史这些“看得见”的东西上。可是真正决定用户心情、决定用户愿不愿意继续敲字的，往往不是那些花里胡哨的功能，而是一个看不见却能马上被感知的细节：输入的即时性和光标/输入法的稳定性。

下面把我试了的三种方法、它们的短板和最终解决思路写清楚，省你走弯路。

我遇到的问题是什么

• 用户在多人同时编辑时，输入会有卡顿感；光标跳走或选区被重置导致输入断裂。
• 中文输入法（IME）下，组合输入被打断或丢失，体验特别糟糕。
• 有时页面看着很快，但敲字就能立刻感到延迟，用户会怀疑整个产品“卡”。

我试过的三种方法（以及为什么它们成不了气候） 方法一：把服务端当权威，按每次变更频繁同步回服务端

• 思路：所有变更先提交到服务器，服务器再下发更新到所有客户端。
• 问题：网络延迟、服务器处理时间直接拖慢输入反馈。用户每次敲字都像在等确认。协作时的冲突处理和回滚还会让光标和选区乱飞。

方法二：使用 contenteditable/虚拟 DOM 全量渲染，每次变化重绘

• 思路：把内容当成状态树，每次更新都用虚拟 DOM 或 innerHTML 刷新视图。
• 问题：innerHTML/全量替换会导致浏览器重建节点、丢失焦点与光标位置；虚拟 DOM 若没有精细选择保护同样会重置 selection。尤其在中文输入时，composition 事件被打断，用户会看到已输入的字消失或多出字符。

方法三：实现 OT/CRDT 协作算法，但直接把远端补丁应用到 DOM

• 思路：用复杂的 CRDT/OT 保证并发安全，然后把远端操作直接打到页面上。
• 问题：算法层面解决了冲突，但如果没有本地优先的输入回显和对 selection/IME 的保护，远端补丁仍会干扰正在输入的用户。很多人以为有 CRDT 就万事大吉，实际上大部分体验问题来自“什么时候、如何把远端变化合并进正在输入的本地视图”。

真正影响体验的那一件事：输入即时性 + 光标与 IME 的稳定性 这两点合起来形成了用户对“顺滑”“可靠”“值得使用”的直观感受。用户不会去读你的版本日志，他们只看感觉：打字流畅吗？输入会不会被打断？光标会不会突然跳走？IM E 下会不会丢字？

把体验做顺的实战要点（可直接落地） 1) 本地优先（local-first）和即时回显

• 用户的每次编辑都立刻在本地应用并渲染（乐观更新），并把操作异步发到服务端/广播给其他客户端。不要把本地渲染绑到服务端确认上。

2) 严格保护 selection（光标/选区）

• 在任何 DOM 更新前后捕获并恢复 selection。对富文本要用能保存位置的方案（如基于节点路径 +偏移量），避免简单的 caretIndex 因节点重建失效。
• 使用 Range/Selection API 做精确恢复，尽量减少对当前输入节点的修改。

3) 不要用 innerHTML 全量替换来更新用户正在输入的区域

• 设计渲染层时，把编辑输入层隔离成尽量小的可控单元。对变更做最小差异化的 DOM patch（或使用能保留 selection 的编辑框架）。

4) IME（中文输入）要特别小心

• 正确处理 compositionstart/compositionupdate/compositionend，不要在 composition 未结束时把远端补丁强行合并到同一编辑节点。
• 有的实现会在 composition 期间暂停远端更新应用，或把远端更新合并但保证不影响 composition 的临时文本显示。

5) 批处理与节流：合并远端更新、避免逐键渲染

• 把来自其他人的高频更新合并或缓冲（例如 16–50ms 的短延迟合并），在视觉上几乎感觉不到延迟，同时减少渲染抖动。
• 对高频输入事件用 requestAnimationFrame/requestIdleCallback 来安排更新，避免阻塞 UI 线程。

6) 把耗时计算移到 worker

• 文档 diff、序列化和复杂算法可以在 WebWorker 中运行，主线程只做最小 DOM 更新，保持输入链路畅通。

7) 使用成熟的编辑器/库（但别把它当“万能药”）

• 可以考虑 Yjs、ProseMirror、CodeMirror 6 等方案，它们在协作与编辑器基础设施方面有很多考虑。但即使用这些库，也要在输入/selection/IME 细节上做额外打磨：默认配置不一定满足你的场景。

8) 传达延迟但保证“输入不被否决”

• 对用户展示延迟状态（比如小小的同步指示），但输入先显示本地结果，服务器冲突用可视化方式呈现而不是直接回退用户当前输入。

如何检验你做对了

• 打字测试：测量从 keydown 到 DOM 可视变化的时间差，目标是保持在 16ms-50ms 内（感知上越短越好）。
• IME 场景：在手机和桌面各主流输入法下输入长词和复杂组合，确保 composition 不被打断。
• 多人并发：多客户端同时乱按，光标、选区和本地输入仍保持稳定且不会出现内容丢失。

结论（一句话） 功能再多也比不上“打字顺不顺”的直观感受；把输入做到本地优先、光标与 IME 稳定，协作体验才能真正顺滑。

如果你正准备把“一起草”搬到网页版：先把上面的输入链路和 selection 保住，再去做光标指示、权限、版本。这把基本功打牢了，后续加功能用户才愿意留下来继续用。想要我帮你看下具体实现或检查一个特定问题（例如 IME 在某款浏览器上的表现），发来例子我们一起排查。

继续浏览有关 真正影响体验 的文章