C1.24.2Concurrent interaction arbitration设计研究
多用户同时操作同一区域需要仲裁规则决定谁的动作生效
别名: 并发编辑 · 仲裁 · 冲突处理
概念解释
当多人同时拖动同一对象、编辑同一字段或点击互斥控件时，系统必须有仲裁规则决定动作如何合并、排队、拒绝或覆盖。没有可见规则，某人的操作会悄然丢失，或所有参与者看到不一致状态。
机制
仲裁可采用最后写入胜出、锁定、操作转换、乐观并发与冲突提示等策略，但选哪一种从来不是界面偏好问题，而是由对象自身状态的代数性质决定的：一个复选框只有开、关两种取值，两人同时切换它，无论谁的操作最后生效，最终状态都只会是这两种之一，后果轻微，最后写入胜出完全够用；但同一段文本字段如果两人同时输入，没有操作转换这类专门处理顺序和插入位置的机制，两串按键会直接交错拼接成乱码，这不是"运气不好选错了策略"，而是文本编辑操作本身依赖顺序、不满足可交换性，任何忽略顺序的简单覆盖策略在这类对象上都必然出错。规则还需要通过实时反馈、版本标记或占用提示被用户理解，否则即使底层技术上做到了一致，体验上仍然像是随机丢失了操作。
怎么研究
模拟同时编辑和网络延迟，记录冲突率、丢失工作、恢复时间、轮流行为和对公平性的理解。比较静默覆盖、显式锁定和可合并操作，检查用户能否在冲突发生前预测什么会生效。针对每一类对象，专门构造"两人同时发出冲突操作"的模拟场景，检验合并后的结果是否符合任何一个理性用户的预期，而不只是检查系统没有崩溃或没有报错。
边界
没有一种策略适合所有内容。严格锁定能防止冲突却阻碍协作；最后写入简单却可能抹掉高价值工作。低风险、可撤销对象可容忍乐观合并，审批或支付这类高风险动作通常需要更明确的悲观锁定——因为这类动作一旦生效，撤销的代价和阻止它发生的代价完全不对等，一次误放行的支付不能靠"稍后撤销"简单抹平。
怎么落地
- 明确每类对象的并发语义——先判断它的状态更新是否可交换、是否依赖顺序，再决定用最后写入、锁定还是操作转换，而不是全站统一套用一种策略。
- 保留可撤销历史与冲突解释，使被拒绝或覆盖的动作可恢复。
- 验证办法：对每一类关键对象单独模拟"两个会话同时发出冲突写入"，检查合并结果是否是任何理性用户都能预期的状态，而不是仅仅确认系统运行正常、没有报错。