多人同时在浏览器里打开同一张表，格子里的输入能实时汇到一起，这早已是协同表格的日常。可协同要同步的不只是格子里跳动的值。还有一类更根本的设置，一旦动了，会影响整张表的内容从何而来——那就是数据绑定。数据绑定把一张工作表的单元格、把某段区域，指到一份数据源的字段上。它决定"数据源是谁、铺进界面的是哪些列、当前显示第几条记录"。

协同里最棘手的，正是这类"结构性"的改动。值改了，别人那边跟着变，机制清晰；可若有人中途换掉整张表的数据源，或给当前记录翻页，其他成员屏幕上的表该如何跟随，才算不产生错乱？V19.2 把绑定也纳入了协同的范围。此前绑定与协同是两条互不相通的线，这版起，以数据管理器（DataManager）为数据源的几种绑定形态，都能进入协同会话，各成员看到的是同一份绑定结果与相关状态。

不只是格子里的值

协同范围明确覆盖四条绑定通路：

1. 整张工作表绑定数据管理器表；
2. 单元格以数据管理器表为源的单元格绑定，连同"当前记录号"一起协同；
3. 工作表里的表格通过绑定路径指到数据管理器记录的嵌套子表；
4. 表格直接绑定数据管理器表。

这四者正是另一篇文章里讲的四种形态，如今它们上面又叠了一层协同能力。

协同的粒度因此分成了两层。格子里值的改动，是最下面那一层，早已顺畅。绑定配置的改动，是上面这一层——谁把表接到了哪张数据管理器表、字段怎么映射、当前记录翻到第几条。只要绑定是以数据管理器为源，这些改动就会像普通编辑一样进入协同流转，落到其他成员的界面上。绑定的结果，各端保持一致。

数据源落在哪一侧

同样是"表格绑定数据管理器表"，支持到什么程度，取决于数据源落在协同会话的哪一侧。这个分水岭把能力划成两档。

数据源是本地数据（Local Data）时，协同按完整能力放行：查看、编辑、表格区域的各种操作，都正常参与同步。

数据源是远程数据（Remote Data）时，边界就收紧了——加入协同会话、同步绑定配置、同步表格区域与相关状态，都支持；但凡是会改动数据的操作，以及在绑定数据区域内产生影响的操作，包括改值、复制粘贴、拖动填充、增删表格行列、调整与扩展表格区域，都不在协同编辑流程的支持范围内。

这条线是画出来的，不是缺出来的

远程数据一侧的收紧，容易让人误以为是能力不足。它其实是一条现实存在的边界。原因要回到数据源的性质上，远程数据在服务端是许多人共享的同一份：若每个客户端都能经由表格操作自由改它，同一批数据被多个成员同时写入，冲突几乎是必然的。本地数据则不同，每个客户端各自持有一份，协同只需把大家的改动收敛到一起。数据源性质不同，能承诺的协同行为自然不同。

因此对远程数据，SpreadJS明确不做一件事：替业务系统判断哪一份数据更新。数据源是否只读、数据本身体现出的增删改能力、以及远程数据在服务端怎样保持一致，都由业务侧负责。界面层把不受支持的操作入口关掉；即便有人绕过界面、经由命令或接口触发这些操作，它们也会被忽略。而业务系统直接对远程数据源做的修改，并不受上述规则约束——那属于数据侧自己的行为。这些限制只作用于"远程数据加协同"这一种组合，本地数据不受任何影响。边界的含义很清楚：表格负责把协同的范围管好，数据的一致性，交还给本就该管它的那一方。

数据变了，界面跟不跟得上

远程数据还有一个绕不开的时刻：服务端的数据变了。协同会话里，变更通知的到达、各端何时去取最新数据，SpreadJS 不去替业务系统安排。它提供的是取数与调整版式的两套节奏。

直接的一条路是调用已有的数据拉取能力并带上刷新语义，一步完成"取回最新数据、并把绑定这张数据源的表格区域按新数据调整好"。简单直接，适合在线客户端不多、收到通知就希望立即对齐的场景。它也有代价：数据一变，许多客户端几乎同时动手调整版式，彼此就成了高并发下的竞争者。

于是产品提供另一条拆开的路径，把"取数"和"调版式"分成两步走。先只取回最新数据，不碰工作表表格的区域——这步之后，客户端手里是最新的数据，界面却可能仍是旧的。

再用一次检查来判断当前表格区域与最新数据是否已经不匹配：若已不匹配，再显式地按最新数据把区域调整到位，而这次调整会作为一次协同结果同步给其他人。版式同步的时机，由此从"数据一变就抢着做"，变成"业务系统按自己的策略决定何时做、由谁来做"。

多人几乎同时动手呢

多人同时触发版式调整，最终落到协同流程里，就是一次普通的协同操作。若大家基于同一版本的数据、得出了相同的调整结果，后到的重复同步不会产生多余的实际改动——幂等，安全。若各端基于不一致的数据得出了不同的调整，局面就麻烦一些：产品不比较远程数据的内容，也无从判断哪一端更新，这类冲突中的版式同步，可能在协同转换阶段失败，其中一侧的改动被拒。被拒的一侧并未丢失现场——回滚到服务器当前版本，或重新订阅最新快照，客户端即恢复到最新状态。

冲突策略因此留白得坦率：远程数据的版本由谁管理、变更通知按什么次序送达、是否允许某个客户端触发版式同步，这些都交由业务侧把控。实践上的建议同样由产品给出：收到数据变更通知后，先取数，再检查失配，最后决定是否调整；业务侧若维护数据版本，就只让基于最新版本的客户端来触发调整。把最大的决定权留在懂得数据的人手里，表格则把协同的秩序维持好。

绑定参与协同，意味着多人共同编辑的，不止是一张表的皮相，还有这张表与数据之间的那根连线。连线如何架设、各端如何保持一致，由表格负责；连线那一头的数据如何维持真相，仍由拥有数据的人负责。两个世界在 V19.2 交汇，边界却画得清楚——这大概正是协同与数据相处时最稳妥的姿态。