在线文档有哪些技术难点

实现一个多人协作在线文档有哪些技术难点？

想知道实现类似于语雀、石墨文档或腾讯文档等产品的难点在哪些地方？

大体上说，多人协作的在线文档在技术上主要分成三大块：“在线”、“多人协作”和“文档编辑”。

先说“在线”，在线其实就是个B/S或者C/S架构，也就是一个web/native用户端加上一个服务器端。这里的技术难点不算很大，主要就是把数据同步的问题解决了，即如何让用户端的输入及时准确地同步到服务器端，当然同时还要考虑网络传输失败、性能等等问题，这里web侧比较好的一个开源解决方案就是 PouchDB，它可以帮你快速实现数据在浏览器和服务器端的双向同步，有兴趣的可以了解一下。

然后是“多人协作”，本质上是一个分布式系统上常说的 Multiple Leader Duplication，任何一个用户端都可以视为一个 Data Leader，这些 Leader 之间同步数据必然会遇到冲突的问题。

对于 Multiple Leader Duplication 的冲突问题，解决方法也就那么几种：

直接避免产生冲突。具体方法就是不让多个用户同时编辑同一处地方，这种解决方法最有效也最粗暴，具体要看产品形态适不适合这种方案。

把冲突暴露给用户，让用户自己解决。现在大多数专业的版本控制软件就是这么做的，但不适用于在线文档这种大部分用户都是非专业的产品。

给写入操作打上一个全局 index，可以是时间戳，可以是序列号，总之是全局的并且是递增的即可，然后任何冲突的地方，都选择 index 较高的那个写入。这样的好处就是冲突的解决是完全自动化的，不需要用户参与。缺点就是如果遇到同步间隔很长的情况，会丢失很多用户的输入。比如你断网写了一小时文章，然后又连网同步，发现被你同事几分钟前的修改给覆盖了。

1、写 UI，并且把这些 Model 状态映射到 UI 上，这里完全不需要考虑输入，就是很纯净地把一堆 Model 映射到 UI 上。比如文档对象的渲染、编辑器各种状态的实现等等

2、处理用户的输入，修改相应的状态，比如用户在界面空白处点击了鼠标右键，我们需要打开右键菜单，具体做法就是把编辑器状态里的右键菜单设置为打开，并且设置好位置即可。

虽然说起来这么简单，但实际开发的时候确实有很多难点：

用户的输入具有复杂性。比如在一个地方按下鼠标（mousedown），那么光标应该移动过去，但如果用户这时继续拖动鼠标（mousemove），那么就应该是一个拖选事件，如何正确区分点击和拖选就是一个比较麻烦的问题。类似的问题还有快捷键的实现、点击穿透问题，如果有移动端的话还会遇到定制光标样式的问题。