做过金融系统的人，大概都有一个共同感受：业务流程越来越线上化，但很多关键工作，最后还是回到了一张 Excel。

预算编制、经营分析、财务报表、指标填报、风险数据补录……这些场景几乎都离不开表格。原因很简单，用户已经习惯了 Excel 的操作方式：输入数据、复制粘贴、调整公式、查看结果，一切都非常自然。

但传统 Excel 也存在明显的问题：文件在邮件、IM 或网盘之间来回传递，版本很容易混乱；多人修改同一份数据，很难确认最终应该以哪个版本为准；谁修改了哪些内容、什么时候修改的，也缺乏完整的追溯能力。更重要的是，金融业务中的表格往往同时包含输入区、公式区、汇总区和说明区，不同区域对应不同角色，权限控制远比普通文档复杂。

因此，越来越多的金融系统开始把 Excel 的能力搬到 Web 页面，希望用户不用离开业务系统，也能获得熟悉的表格体验。表面上来看，在线表格协同的核心就是"多人同时编辑一张表"，但真正做过项目之后就会发现，多人编辑只是开始，真正困难的是如何保证整个工作簿始终保持一致。

表格协同难点：不只是同步单元格

很多团队第一次做在线表格协同时，都会有一个比较自然的想法：用户修改了一个单元格，就通过 WebSocket 把变化广播给其他客户端，大家同步更新，不就实现了协同吗？

这种方式对于普通文本编辑没有问题，但 Excel 工作簿远比普通文本复杂，一次编辑可能不仅影响某个单元格，还会涉及公式计算、行列结构、筛选状态、工作表以及其他用户正在编辑的位置。如果这些变化不能完整同步，不同用户看到的工作簿状态就会逐渐偏离，最终出现"同一张表，每个人看到的内容却不一样"的情况。

举一个预算填报场景的例子：A 正在新增部门预算，B 修改汇总公式，C 审核数据，D 查看报表。如果系统只同步单元格内容，当 A 插入一行后，B 的公式引用可能发生偏移，C 审核的数据位置也会改变，而 D 看到的结果甚至可能已经不是其他人当前看到的版本。可以看到，在线表格协同真正需要同步的并不仅是某个单元格的数据，而是整个工作簿模型以及围绕工作簿产生的一系列操作。

这一点也是很多自研方案容易遇到的问题：开发阶段只验证了单元格修改，看起来能够正常运行；进入真实业务场景后，插入行列、撤销重做、公式联动、多用户同时编辑等情况接连出现，不同客户端的状态开始逐渐偏离，维护成本也随之增加。

图1 工作簿模型协同与普通同步方式区别

从这个对比可以看出，在线表格协同真正困难的地方，并不是同步某个单元格的数据，而是保证整个工作簿状态始终保持一致。

金融项目真正需要补上的，是“表格协同层”

金融系统本身通常已经具备完善的业务能力，例如流程审批、权限控制、数据存储、审计日志等，但真正容易被忽略的，是连接业务系统与在线表格之间的这一层能力。如果缺少这层能力，用户仍然会习惯把数据导出到 Excel 离线处理；而如果只有在线表格，没有业务系统支撑，表格又容易脱离流程和权限管理，重新变成一个共享文件。

因此，更合理的方式并不是简单地把 Excel 搬到浏览器，而是让在线表格真正融入业务系统。业务系统继续负责权限、审批、流程、审计等业务逻辑，在线表格负责提供接近 Excel 的交互体验，而协同能力则作为两者之间的一层基础设施，保证多人编辑时工作簿始终保持一致。

从目前成熟的在线表格方案来看，大多也是围绕这一思路设计。以 SpreadJS 协同插件为例，它同步的不是某个单元格发生了什么变化，而是监听整个 Workbook 的变化，将工作簿操作转换为 Operation，再封装成 ChangeSet 发送到协同服务，由服务端统一处理并广播给其他客户端。对于开发者来说，这意味着无需自己处理复杂的工作簿同步逻辑，而可以把更多精力放在业务规则和流程设计上。

图2 SpreadJS 协同框架工作原理

通过这张架构图可以更容易理解协同过程：客户端持续监听 Workbook 的变化，将用户操作转换为 Operation，并封装为 ChangeSet 发送到协同服务；服务端负责处理不同客户端同时提交的操作，并利用 OT（Operational Transformation）解决并发冲突，再将处理后的结果广播给其他客户端。整个过程中，同步的核心对象始终是工作簿模型，而不是某几个单元格的数据，这也是它能够支持插入行列、公式联动、撤销重做等复杂操作的重要原因。

协同能力要跟业务状态一起走

如果只是几个人一起改一张普通表，实时同步单元格内容也许就够了。但金融系统里的表格，往往不只是数据本身，还和权限、流程、版本、审计这些业务要求绑在一起。

例如：一张预算表，不能在审批后还随便改；一张指标表，不能让所有人都修改关键区域；一张报表，也不能只知道“现在是什么值”，还要能追溯这个值是怎么变成现在这样的。如果协同能力脱离了业务状态，仅仅实现“实时同步”，那么它仍然只是一个在线文档，而不是一个真正能够融入业务流程的企业应用。

因此，在金融系统中，协同能力应该随着业务状态一起变化。业务系统负责决定谁能够进入这张表、当前阶段是否允许编辑、哪些区域可以修改以及哪些数据能够正式提交；在线表格则负责保证多人协作过程中工作簿始终保持一致，并记录完整的变更轨迹。只有两者协同工作，才能既保留用户熟悉的 Excel 使用方式，又让整个修改过程重新回到业务系统的可管理范围内。

图3 业务系统与在线表格协同能力的职责划分

协同表格也不是海量数据平台

随着在线表格能力越来越完善，还有一个误区也比较常见：既然 Web 表格已经能够做到接近 Excel 的体验，是不是所有业务数据都可以直接放到在线表格里？答案通常是否定的。

协同表格适合多人围绕一份工作簿进行填报、修订、复核和分析，但不适合承载所有海量明细查询。

例如历史交易流水、高频行情数据、百万级持仓明细、复杂聚合分析，这些更适合由后端系统查询、分页、计算和汇总，再把需要人工编辑或确认的部分呈现在表格中。

明确这一点，对系统架构非常重要。让后端承担数据处理能力，让在线表格承担数据展示、编辑和协同能力，各自发挥优势，不仅可以获得更好的性能，也能避免把在线表格变成另一个没有边界的数据平台。

结语：好的表格协同，是把 Excel 的灵活性放进业务系统里

在线表格协同从来都不只是“多人一起编辑一张表”这么简单。真正有价值的，并不是把 Excel 搬到浏览器，而是把 Excel 的灵活体验保留下来，同时让权限、流程、版本和审计重新回到业务系统之中。

从这个角度来看，SpreadJS 协同插件更像是一层面向在线表格的协同基础设施。它负责解决工作簿同步、多人协作一致性以及复杂操作同步等问题，而业务系统仍然专注于权限控制、流程审批和业务规则，两者各司其职，共同构建完整的企业级在线表格解决方案。

相比完全从零自研一套复杂的在线协同能力，引入成熟的 Web 表格与协同方案，往往能够帮助项目更快落地，也能让团队将更多精力投入到真正体现业务价值的创新上。