[]
协同编辑的目标是：支持多名用户同时编辑同一份工作簿，所有客户端的画面实时保持一致，且修改不会相互覆盖。
本文从原理层面介绍协同编辑的运作机制，不涉及具体算法与代码，重点说明以下三方面：
协同系统的构成角色
一次编辑从发起到同步至其他客户端的完整过程
多人并发编辑时的冲突处理方式
算法实现、分片机制等细节属于进阶内容，不在本文范围内。
一套协同系统由三种角色构成：
角色 | 职责 |
|---|---|
客户端 | 运行于每个用户浏览器中的 SpreadJS 工作簿，负责产生编辑并呈现其他用户的编辑。 |
服务器 | 协同的中枢。所有编辑先提交至服务器，由其排序、转发，保证所有客户端呈现一致的内容。 |
操作（op） | 对一次编辑的标准化描述，例如"将 A1 改为张三"或"在第 3 行前插入一行"。客户端之间不直接通信，统一通过"操作"这一标准格式交换数据。 |
概括而言：每个客户端将本地编辑封装为"操作"发送给服务器，服务器排序后转发至所有客户端，客户端应用操作后更新画面。
一次编辑在系统中经过以下 5 个步骤：
用户修改单元格（例如将 A1 改为"张三"）。
SpreadJS 协同插件捕获修改，将其封装为一个"操作"，记录"操作者、位置、变更内容"。
操作通过长连接发送至服务器。
服务器将操作排入队列，按到达顺序广播给当前房间内所有在线客户端。先到达的操作排在前面。
其他客户端接收操作并应用到本地工作簿，对应单元格（如 A1）同步更新为"张三"。
整个过程中，服务器的核心职责是为所有操作建立统一的顺序。所有客户端看到相同的操作序列，画面才能保持一致。这也是下一节冲突处理的基础。
当多人同时编辑时，系统通过以下两种机制分别处理位置冲突与值冲突。
A 与 B 同时编辑同一份工作簿：
A 在第 3 行前插入一行。
几乎同一时刻，B 在第 5 行前插入一行。
两个操作几乎同时到达服务器。服务器分两步处理：
排序：假设 A 的操作先到达。
校准后续操作的位置：A 已在第 3 行前插入一行，原来的第 5 行相应变为第 6 行。服务器据此将 B 的"在第 5 行前插入"校准为"在第 6 行前插入"，再广播出去。
结果：A 与 B 的插入均生效，两者画面最终完全一致。
这就是 OT（操作转换） 的作用——根据已发生的改动，自动校准后续改动的位置。该过程对用户透明，最终结果为两条记录均被加入。
A 将 A1 改为"张三"，几乎同一时刻 B 将 A1 改为"李四"。
此时两个意图无法同时满足——A1 单元格只能保存一个值。协同系统对此的约定是：
一致性：所有客户端的画面最终必定相同，不会出现 A 看到"张三"、B 看到"李四"的情况。
先到先得：先到达服务器的修改先生效；后到达的修改会覆盖前者。
最终 A1 的值取决于哪条操作后到达服务器。对于"同一单元格写入两个不同值"这类真实冲突，系统必然二选一，关键在于保证全员一致。
OT 处理的是"位置变化"问题，而非"取值裁定"问题。 位置冲突由 OT 自动校准、操作不会丢失；值冲突则按"先到先得"统一裁定，以保证全员一致。
OT 的内部实现由 SpreadJS 内置，使用者无需关注其计算细节。
协同编辑采用经典的客户端-服务器架构：
[ 客户端 A ] ─┐
[ 客户端 B ] ─┼──→ [ 协同服务器 ] ──→ 数据库（可选，用于持久化）
[ 客户端 C ] ─┘ │
▲ │
└───────────────────┘
服务器把操作广播回所有客户端每个客户端通过一条长连接与服务器双向通信。
所有操作均经服务器排序、校准后再广播。
数据库为可选项，负责将文档状态持久化，服务重启后数据不丢失。
客户端和服务器需各自引入一组配套的包才能运行（并非只有服务器需要安装）。具体安装哪些包及各自的作用，请参见 快速开始 的"安装依赖项"步骤；如需光标共享或数据落库，请参见对应的配置教程。
常用术语说明如下，便于阅读其他文档时参考：
op（操作）：对工作簿的一次原子修改，例如"将 A1 改为张三"。
ot（操作转换）：根据已发生的改动校准后续改动位置的技术。
presence（在线状态）：表示用户的在线情况，包括光标位置与选区。
room（房间）：将用户归入同一协同空间的逻辑分组。
broadcasting（广播）：服务器将一个操作同时发送给房间内的所有客户端。
掌握以上原理后，即可进行协同编辑的常规开发，算法与 API 的细节可在实际使用中按需查阅。
根据后续目标，可选择相应的文档继续阅读：
动手搭建一个可运行的协同示例 —— 参见 快速开始：搭建一个支持实时协同的 SpreadJS 设计器。
深入了解 SpreadJS 协同的内部机制（如撤销、冲突处理行为、工作表模式等） —— 参见 协同框架架构。
查阅协同相关名词解释 —— 参见 协同术语表。
回顾以下三点，即可确认对协同原理的理解：
运转机制——客户端将编辑封装为"操作"，由服务器排序转发，三者协同配合。
流转过程——捕获 → 封装 → 上传 → 排序广播 → 其他客户端应用。
冲突处理——服务器为所有操作统一排序；位置变化由 OT 自动校准，值冲突按"先到先得"裁定，保证全员一致。