【文档协同编辑】 协同编辑引论
来历
协同编辑是什么？顾名思义就是多人的编辑。当然也不是这么简单，还要加上有规律的、有先后的定语修饰。
为什么会有这个东西？我们先从场景分析入手：
对于使用git的程序员来说，以下场景再熟悉不过：从主干fork一个分支修改代码，花了半天修复之后准备合入到主分支，发现主分支已经被B修改了，此时如果历史中已经修改了相同的文件，则会出现冲突。此时需要自动或通过手工合并。
在此过程中，git服务器充当了集中管理的角色，但是冲突一般是在本地解决后再push上去的。如果在解决的时候又有新的合并，可能又要合并，解决冲突，合并。。。尽管这并不太可能在一个好的团队发生。
而对于其他场景，例如产品、运营团队修改产品页面，美工、策划在设计文案图画，会计在对账的时候如果他们足够有经验，可能会使用共享的文档，而不是使用一份文件拷来拷去做修改。
还有一个人的：打开A文档的草稿，长时间不用；重新打开A文档，修改，记为A2保存；此时在A文档的草稿中再改一下，保存，便会出现冲突。
以上种种，都是编辑冲突。而要解决这种问题，就需要协同编辑的技术。当然，协同编辑的门槛从简单到复杂有很多层级，需要的技术能力也不完全相同，但是核心的总是涉及到数据格式、网络编程、页面UI。如果是复杂的文档和超大规模的共享文档，还需要更加苛刻的技术能力要求。但是在目前业界的情况下，普通的场景仅涉及几十个人，极端场景本来在共享文档中就很难出现，属于边界情况，性价比极低，也可以放弃设计。
显然，在网络不发达的20世纪，协同文档是没什么需求的。尽管如此，1989年已经有了微软的Office，协同编辑理论就此出现在论文中。
若干年过去，虽然共享文档软件已经有了很多的应用，但是还没有达到完美。协同编辑功能仅仅是办公软件中小小的一环，自然不会引起人们的太多关注。而在文档软件中，国外的产品是Google Docs/Notion/Adobe，国内有语雀、腾讯文档、钉钉文档、飞书、WPS等等你能想到的大部分的支持在线文档的软件。
尽管如此，协同文档编辑仍然作为一个基础的技术在文档编辑中发挥着作用。而到目前为止，并不是所有的公司都把这个功能做到最好。更多的情况是像有道云笔记一样出了冲突就给出提示，让你自己决定要保留哪些文本（当然在这种场景下是合理的，只是冲突本身经常是由于误操作）。
同时，还有其他一些应用，例如共享的WebIDE，也需要Collaborative Editing的支持。
应用场景
企业内各种形式文档的交互，公共文档（附加权限）的编辑；共享电子表格；
实现的功能：冲突合并；光标回显；撤销与重做；富文本编辑；
草稿冲突解决；WebIDE；各种共享软件，包括图形设计，思维导图；
数据的转换与冲突解决算法
如何实现冲突解决？其实这个是一个产品体验问题，需要我们定义什么是冲突解决。如果两个操作冲突，其实可以按顺序合并，但是需要让人感知到编辑的流程，即你不能看到文档的突变。
数据的转换：协同编辑不仅要处理文本，还有各种附加在文本上的数据和结构，包括各种文件格式，文字排版格式；可能还有矢量图；
解决其他问题
协同编辑可能会遇到网络问题、跨端编辑、数据传输；
冲突解决算法OT是中心式的，服务器压力；而CRDT是去中心化的；
其他软件的领域知识，包括富文档编辑，不同的文档格式和patch的方法；
云存储与本地存储；
