V3.01.1Concurrency control in collaborative editing设计研究
同时编辑同一处需要合并策略
别名: 并发控制 · 合并模型 · 乐观并发与悲观并发
概念解释
一旦允许多于一人编辑同一份文档，系统就必须回答一个问题：两个人改了同一处，结果算谁的？对这个问题的结构性回答就是并发控制（concurrency control），落成产品功能就是合并策略。它不是多人协作的可选增强，而是地基——没有它的「协作编辑」要么靠人自觉轮流改（把并发问题推回给人），要么在两人同时保存时悄悄丢掉一方的修改。一个协作工具允许谁、以什么粒度、在什么时机并行写入，全部由并发模型决定。
机制
并发的根源是复制与延迟：每个编辑者的客户端都持有一份本地状态，修改传播到他人之前存在一个时间窗；两个人在这个窗口内改了同一处，就产生了两段同样合法、却互不知情的历史。合并策略决定系统如何把分叉的历史收敛成一份结果，大致两路：悲观策略在冲突发生前阻止它——想编辑某区域先拿到锁，拿不到就等；乐观策略先让所有人自由编辑，事后用算法把并发操作融合成一致结果（操作变换、无冲突复制数据类型都属于这一路）。选择哪一路，直接决定协作的并行度上限，以及冲突以「被挡住」还是以「被自动融合」的面目出现在用户面前。
怎么研究
- 范式：真实协作系统的日志分析——统计并发编辑事件中「同一区域被两人同时修改」的频率，看冲突率如何随人数、文档长度、任务类型变化；受控实验——被试结对或成组完成同一文档任务，操纵合并策略（锁定式 / 自动合并式 / 检测后人工合并），观测任务时长、额外沟通量、修改丢失率与主观负荷。
- 变量：自变量为并发模型、冲突区域粒度、群体规模；因变量为冲突发生率、等待时间、修改丢失量与合并结果的可接受度。
- 在界面研究里的用途：判断一个协作系统的并发模型是否与其任务的冲突密度匹配，为「该上锁还是该上算法」提供数据依据。
- 方法论注意点：实验室里安排两人共写一小段文字，冲突密度是被人为抬高的；真实文档协作中同一处并发的概率很低，且高度集中在少数区域（开头、标题、刚被提及的段落）。两类数据不能互相外推，评估时要以目标场景的真实冲突分布为准。
边界
合并策略以「多人可写同一对象」为前提。只读共享、单人编辑多人评论、按时间严格接力的流程，都不会触发并发，为其引入复杂的合并机制是纯成本。冲突频率还随任务形态剧烈变化：异步接力式写作几乎不触发，会议纪要共创、白板头脑风暴则高频触发。算法层面的「收敛」只保证两端结果一致，不保证融合后的文字语义通顺——语义正确性没有形式化保证，仍需人来判断。
怎么落地
- 做多人文档、白板、代码协作功能时，并发模型是第一个要定的设计决策，不是上线后打的补丁。
- 按任务冲突密度选型：低冲突的异步场景用「检测到并发就通知人工合并」的简单方案即可；高冲突的实时共创才需要操作变换或无冲突复制数据类型这类重型机制。
- 把「同一处」的粒度（字符、段落、对象、行）作为显式的产品决策定下来，粒度决定了冲突被感知的频率。
- 任何自动合并都要能向用户解释「刚才合了什么、动了谁的修改」。
- 验证：找两组真实用户分别在高冲突任务（共写纪要）和低冲突任务（分章各写）里使用，统计触发并发处理的次数与用户 noticing 率；若用户经常在事后才发现自己的修改被动过，说明策略不可见或粒度选错。