这两年做中后台系统凡是跟数据沾边的业务我几乎都被问过同一个问题能不能在网页里直接像 Excel 一样编辑数据而不是每次都在输入框里敲完再上传表格做过内部报表、资产管理、运营后台的人应该都懂——要不要接一个在线表格最后基本都会落到选型上。Univer 就是我在这个语境下研究最久、也实际集成过的一个开源项目。它是一套基于 Web 的办公套件主推在线电子表格Univer Sheet同时把文档、幻灯片也放进同一套架构里。跟传统的 DOM 表格组件不同Univer 用 Canvas 自研渲染引擎来绘制表格内容核心能力包括单元格编辑、公式计算、样式设置、数据透视、XLSX 导入导出以及面向团队的协同编辑。这篇文章不打算抄一遍官方文档而是从一个实施者的角度聊聊 Univer 到底适合什么场景、内部是怎么设计的、接入业务系统时有哪些坑以及如果你正在做在线表格选型该怎么判断它适不适合你。1. 为什么是 Univer在线电子表格的开源之选1.1 它到底在解决什么问题我见过很多团队把表格这个词理解得过于宽泛。中后台页面里的表格绝大多数是展示型表格比如 antd Table、Element Table负责把数据列出来顶多支持排序、筛选、分页。但业务发展到一定阶段一定会冒出一个新需求运营希望直接在页面上改数财务希望临时拉一个透视表算账产品希望用户能在网页里粘贴一段 Excel 数据进来。这个时候你需要的不是展示型表格而是一个具备电子表格能力的编辑器。Univer 解决的就是这个编辑器问题。它不是一个写死的业务表格而是一个可以嵌入到现有系统里的在线办公组件。你把它当成一个独立模块引进来它就给你一张完整的电子表格能点选、能输入、能拖拽填充、能跨单元格引用、能设置样式、能执行公式甚至能多人同时编辑。对企业内部系统来说这意味着你可以把 Excel 里的操作习惯直接搬到网页上用户不用重新学一套交互。还有一个容易被忽视的点Univer 把表格、文档、幻灯片统一到了同一套架构之下。虽然目前大部分人在用的是它的 Sheet 能力但一个核心多种文档类型的设计意味着如果后续你想做在线文档编辑、在线演示不需要再从零找另外一套方案。我在做技术选型时很看重这一点因为它决定了这个项目未来能不能跟着业务一起长大而不是半年后又要推倒重来。1.2 和同类方案横向对比在线电子表格这个领域开源和商业方案都有不少。我在选型时重点调研过 Luckysheet、Handsontable、SpreadJS以及 Univer最后才定了方向。这里不是要给谁做广告而是把当时的对比逻辑记录下来方便你少走弯路。Luckysheet 出现得比较早社区口碑一度很好交互也贴近 Excel。但它的开发节奏在近几年明显慢了下来GitHub 上的 Issue 堆积不少社区维护状态让很多企业不敢赌。再看它底层的实现方式本质上还是大量操作 DOM虽然配合虚拟滚动能撑住一定数据量但当单元格数量到几十万、公式复杂起来之后性能会遇到明显瓶颈。Handsontable 是一个成熟商业产品功能完整文档也规范但授权费用不低而且它的定位更偏向数据网格不是完整的电子表格编辑器很多 Excel 特性需要自己实现。SpreadJS 在纯前端表格领域做得相当深功能丰富、稳定性好但同样是商业授权模式价格通常需要走采购流程这对预算敏感的中小团队并不友好。Univer 的差异化在于三个点。第一开源且技术栈现代化基于 TypeScript 开发代码可读性和扩展性都不错。第二用 Canvas 自研渲染引擎而不是依赖 DOM 逐格渲染这给大数据量场景留出了更多优化空间。第三插件体系设计得比较干净核心、渲染、UI、公式引擎彼此解耦你可以只保留需要的部分。当然它也并非没有缺点。项目迭代速度很快API 变动频繁文档有时候跟不上代码这需要团队有一定的源码阅读能力。如果你完全不想折腾只想要一个开箱即用、出了问题有厂商兜底的方案商业产品会更合适。2. 核心架构与渲染原理拆解2.1 Canvas 渲染引擎把 10 万行数据画出来第一次看到 Univer 的渲染方式时我特意去翻了它的渲染引擎源码因为用 Canvas 画表格这件事听起来简单做起来有不少门道。传统表格组件每增加一行至少会产生一组 TD 节点每个单元格里的样式、边框、文字都会占一块 DOM 内存。我在实际项目里验证过单纯渲染两万行、每行二十列的数据DOM 节点数就能上万滚动时浏览器布局和重绘压力非常大。Univer 不这么做。它把整张表当成一幅画通过一个自研的渲染引擎在 Canvas 上把单元格背景、边框、文字内容、选区高亮逐层绘制出来。你滚动的时候它不会真的创建新 DOM而是调整视口重新绘制当前可见区域内的内容。这就好比 DOM 方案是给每个座位安排一个真人Canvas 方案是请一位画家在幕布上把观众画出来——前排观众站起来走了画家只需要擦掉再补画而不需要让整个剧院的人都动一遍。这里面的关键机制是视口裁剪。Univer 渲染引擎只绘制当前视口能看到的行和列上下左右滚动时它会实时计算新的可视范围只对进入视口的部分做绘制离开视口的区域直接丢弃。配合分块绘制和脏区重绘能把单次绘制成本控制在很小的范围。我在集成时还注意到Univer 渲染时会读取设备的 devicePixelRatio 来调整画布缩放避免高分屏下文字发虚。这个细节如果忘了处理用户在 Retina 屏幕上看到的表格会非常糊看起来像没做过适配的老年软件。2.2 命令系统与插件机制Univer 的架构设计里最让我觉得这项目有工程底子的是它的命令系统。用户在界面上做的任何操作——输入一个值、插入一行、改个背景色、执行一次公式计算——都会被包装成一个命令。命令不会直接去改 UI而是先提交给核心的命令管理器由它调用对应的执行逻辑更新数据模型再触发界面刷新。这有点像你在餐厅点菜你告诉服务员要一盘宫保鸡丁服务员不会直接冲进厨房抓鸡而是把订单交给后厨调度后厨按流程做菜最后才端到你面前。这样做的好处非常多撤销和重做变得很简单因为每一步操作都有记录可以回退协同编辑也能复用同一套机制因为每个操作都变成了可序列化、可传输的结构化数据而不是一堆离散的 UI 事件。插件机制是另一个让我下决心的点。Univer 把核心功能分层拆开渲染引擎、UI 外壳、公式引擎、底部状态栏、右上角工具栏都是可以独立启用或替换的。举个例子如果你的业务根本不需要写公式那你可以不注册公式引擎减少不必要的打包体积和计算开销。如果你不想用官方那套默认工具栏也可以只把核心和渲染引擎接进来自己写一套完全贴合业务的操作面板。这种可裁剪性在企业内部系统集成时非常宝贵。3. 把 Univer 接入到业务系统实操记录3.1 最小可运行示例先把最基础的部分跑通。Univer 的 API 迭代速度比较快不同版本之间差异不小下面的示例是我当时整理的最小可运行骨架以 npm 包方式接入适合先感受整体流程。你在实际操作时版本对应的准确 API 要以官方文档和仓库里的 examples 为准。npm install univerjs/core univerjs/sheets univerjs/ui univerjs/engine-render这是最基础的一组包分别负责核心数据模型、表格功能、UI 外壳、渲染引擎。接下去是一个简化的初始化逻辑import { Univer } from univerjs/core; import { UniverSheetsPlugin } from univerjs/sheets; import { UniverRenderEnginePlugin } from univerjs/engine-render; import { UniverUIPlugin } from univerjs/ui; const univer new Univer({ theme: { primaryColor: #409eff, }, plugins: [ UniverSheetsPlugin(), UniverRenderEnginePlugin(), UniverUIPlugin({ container: app }), ], }); univer.createUnit(UniverSheetsPlugin.Sheet, { name: 示例工作表, sheetList: [ { id: sheet-01, name: 数据明细, rowCount: 200, columnCount: 30, }, ], });跑起来之后你会发现页面上出现了一个完整的电子表格外壳包括顶部菜单栏、公式栏、行号列号、底部 Sheet 标签。这里我要提醒两句第一容器元素必须有明确高度也就是#app不能是 0 高度否则 Canvas 画布会初始化成一条线第二初始化脚本要在容器渲染之后执行如果放在 DOM 挂载前Univer 会找不到容器直接报错。我当时第一次跑就栽在这两个问题上排查了半天才发现是 Vite 开发服务器下脚本执行顺序的问题。3.2 数据接入与常见配置最小示例跑通之后最重要的事情就是把业务数据填进表格。Univer 里的核心概念是 Workbook也就是工作簿。你可以在创建时直接传入完整的簿数据包括多个 Sheet、每张表的行列数量、单元格值、样式、合并信息也可以在运行时通过 API 动态修改。我们实际项目里最常用的数据接入方式是先从后端拉一个 JSON 结构的工作簿数据再把它传给createUnit让表格一次性渲染出来。这个 JSON 结构不需要太复杂核心字段就是 sheet 列表和单元格数据。如果你是第一次接我建议先别急着做完整的数据往返而是用下面的方式验证一条链路后端返回一批业务明细前端按行列重新组织成二维数组再用 API 写入 Univer 实例。这样你能较快看到真实数据进入表格的效果然后逐步加上样式、公式、合并单元格这些高级内容。还有两个高频需求值得提前了解。第一个是 XLSX 导入导出。Univer 官方提供了导入导出相关能力的插件可以把本地的.xlsx文件解析成工作簿数据加载进来也可以把当前表格内容导出成.xlsx文件。但要注意官方生态对复杂样式的兼容还在持续完善比如透视表、图表、复杂的条件格式在不同版本上表现不稳定。如果业务场景里这些能力是核心一定要先做一轮真实文件兼容性测试再上线。第二个是数据变更监听。你需要在用户编辑后把最新数据回传后端这时候不要在 UI 层监听一堆零散事件而是尽量在命令系统层面处理等用户停止操作一段时间后再批量提取数据能明显降低请求频次。3.3 工具栏与菜单定制Univer 自带一套完整的工具栏但说实话企业集成场景里很少会原样保留。原因很简单内部业务的用户不需要也不应该看到不相干的功能比如你做一个数据核对工具就不该让用户随便插入图表或者改主题色。这种场景下Univer 的插件式架构优势就体现出来了。官方 UI 插件支持对菜单项做拆分和定制你可以只保留自己需要的按钮比如撤销、重做、字体加粗、合并单元格、冻结行。再激进一点你完全可以在初始化时不启用官方 UI 外壳只挂载核心和渲染引擎然后自己写一个操作面板通过在命令系统里提交命令来控制表格行为。这样做的好处是界面和业务风格完全统一坏处是你要自己处理选中态、隐藏高亮这些底层 UI 状态开发量会上去。我的建议是第一个版本先用官方 UI把功能跑通再逐步裁剪菜单不要一开始就自研工具栏否则你会在调试表格选区和 UI 状态同步上消耗大量时间。定制按钮时要注意Univer 的命令名和参数在不同版本间可能会拆分成更细的命令测试时最好把调试日志打开观察命令层的输出确认你调的确实是正在生效的那条命令。4. 公式引擎与协同编辑真正拉开差距的地方4.1 公式引擎与自定义函数如果说 Canvas 渲染是 Univer 的骨架那公式引擎就是它的大脑。在线表格如果没有公式计算能力本质上就是一个好看的 HTML 表格价值大打折扣。Univer 的公式引擎在架构上是独立模块它维护了单元格之间的依赖关系和计算时序单元格内容变化时会自动找到需要重算的依赖区间而不是全表重新跑一遍。我在集成时被问到最多的一个问题是Univer 能跑 Excel 里那些复杂函数吗从实际使用来看常见的 SUM、IF、VLOOKUP、TEXT、COUNTIF 这些基础函数官方支持得很全。但如果你要用非常冷门、只在 Excel 特定版本里才有的函数最好提前查一下支持列表别等上线了才发现计算结果是 #NAME?。还有一个更常见的坑是循环引用。业务人员做表时经常会不小心写一个自己引用自己或者A 引用 B、B 又引用 A的公式Univer 会给出循环依赖提示但不同版本的表现形式不一样体验上还达不到 Excel 那么顺滑。更值钱的能力是自定义函数。企业内部有很多计算公式是业务特有的比如运费计算、绩效折算、年假天数这些在标准函数里找不到。Univer 的插件机制允许你注册自己的公式函数注册之后用户就能在单元格里像用内置函数一样调用它。比如我做过一个场景需要一个函数根据入职时间和职级自动算年假注册完成后用户在单元格里输入ANNUAL_LEAVE(2020-03-15, P6)就能直接得到结果。这个能力非常实用因为它让业务规则长在了表格里而不是散落在后端代码里。4.2 协同编辑的实现路径协同编辑是每个考虑在线表格的团队都绕不开的课题。单机版表格跑得再好也只是把 Excel 搬到了浏览器里真正的在线协作指的是两个用户同时打开一张表一个人改 A1 单元格另一个人改 B1 单元格双方都能实时看到对方的变化而且数据不会互相覆盖。Univer 在这块的设计很巧妙。前面提到用户的所有操作都会变成结构化命令这天然为协同提供了素材。协同服务端要做的事情本质上是把不同客户端产生的命令收集起来按照一定的顺序分发给所有参与的客户端然后在各自本地执行。实现方案可以分成两条路线。第一条是使用官方提供的协同服务方案适合不想自己从零写冲突处理逻辑的团队稳定性和一致性更有保障。第二条是自研一套基于 WebSocket 的转发服务客户端把命令广播给服务端服务端按时间排序后再发给其他人。这里我必须要泼一盆冷水不要小看协同的复杂度。如果只是做打字聊天式的文字同步相对简单但电子表格有选区、有冻结、有滚动位置、有公式重算、有合并单元格两个用户同时操作同一个区域时冲突策略如果没设计好用户的数据就会被悄悄覆盖。我见过有团队用一个共享 JSON 文件加上前后端全量传输的方式实现伪协同结果两个人同时输数据时互相覆盖最后只能在数据库里做乐观锁体验非常糟糕。如果你不想踩同样的坑建议先想清楚产品对实时的要求有多高。有时候手动保存加锁比不成熟的实时协同更可靠。5. 常见问题与排查技巧实录5.1 高频问题速查表把我在接入和试运行时遇到的高频问题整理成一张表先给结论再逐条解释。问题现象常见原因解决思路页面白屏或画布高度为 0容器没有高度或初始化时机太早给容器设置明确高度确保 DOM 挂载后再初始化高分屏下文字发虚Canvas 未适配 devicePixelRatio检查渲染引擎的 DPR 设置必要时手动传入大文件导入后滚动卡顿数据量过大未使用分页加载限制单次渲染行数分批次加载数据公式不计算或结果不变依赖关系未刷新或注册了同名自定义函数查看公式引擎日志刷新计算链自定义函数返回 #NAME?函数插件未注册或注册时机不对在创建 Univer 实例前完成函数注册导入 xlsx 后样式丢失官方对复杂样式兼容有限提前做文件兼容性测试评估导出兜底方案两个用户同时编辑互相覆盖缺少完整的协同服务端引入版本控制或升级为真正的协同方案这里面最值得展开的是自定义函数不生效的问题。Univer 的公式引擎里函数是通过注册表管理的如果注册的时机晚于工作簿初始化公式计算时查不到这个函数就会直接报错。我当时第一次写自定义函数把它放在初始化之后才注册结果表格里所有调用这个函数的单元格都显示 #NAME?。解决方式是把注册逻辑提前确保公式引擎在解析单元格时已经认识这个函数。还有一个类似的问题是不同插件里定义了同名函数后者覆盖前者导致计算结果完全对不上。排查这类问题最好的办法是在公式引擎的调试日志里看函数解析过程。另一个要提醒的是数据回传的边界。Univer 作为一个前端组件它本身不关心你的数据是存在 MySQL 还是 MongoDB。用户改完单元格之后你需要自己决定在什么时候、以什么粒度把数据提交给后端。我见过一些团队监听每个单元格事件然后每个事件发一次请求数据库压力巨大而且容易出现后发请求覆盖先发请求的问题。更稳妥的做法是采用操作日志思路本地积累一段时间的变更命令统一打包提交后端校验版本号通过后才真正落库。这样既减少了请求量也降低了并发冲突的概率。5.2 值得注意的体验优化接入 Univer 时除了功能和稳定性体验上的细节也会直接影响用户接受度。不要只在技术群里讨论渲染性能真正每天对着表格敲数据的业务用户对卡顿和交互异常是非常敏感的。第一个优化点是初始化速度。如果你的表格数据量大比如单表几万行一次全部塞给 Univer 会让首屏加载非常慢。我建议做分层加载策略后端接口先返回前几百行让用户看到表格已经打开后续的数据通过滚动懒加载异步补上。Univer 的数据模型更新是动态的你可以在用户滚动到接近底部时再请求下一批数据体验上非常接近本地 Excel 的顺滑感。第二个优化点是主题和语言。Univer 默认的界面风格偏国际化英文菜单占多数但企业内部基本都是中文用户。官方提供了语言包可以在初始化时设置成中文。如果你发现某些菜单还是英文大概率是语言包没完全覆盖当前版本需要手动补充。主题定制方面我建议跟公司设计规范对齐开一个专门的样式配置把主题色、字体统一起来不要让默认蓝色块出现在内部系统里显得格格不入。第三个优化点是权限控制。业务系统里不是所有用户都应该能编辑所有单元格。Univer 提供单元格级别的锁定配置你可以结合登录用户的角色决定哪些区域只读、哪些区域可编辑。但这种前端约束只能解决体验问题真正的安全边界一定要在后端校验。我在项目里见过只靠前端设只读的案例用户用控制台改一下配置就能绕过限制这种风险要提前规避。最后想分享一个调试技巧集成 Univer 时建议把命令系统日志打开让控制台输出用户每次操作对应的命令名和参数。你不需要理解每一条命令的底层含义但配合官方文档几乎能定位所有操作不生效的问题。这比在 UI 层盲猜要高效得多。尤其当你开始做插件和自定义工具栏后这套日志几乎是必备的调试工具。从我个人的实际体会来说Univer 给我的最大印象是这项目不是为了做演示而生的。它的架构设计、命令系统、插件机制都是奔着长期演进去的。但它也确实不是那种装上就能完美贴合业务的组件API 的快速迭代、文档的相对滞后、复杂样式兼容的不稳定都是你在做技术选型时要掂量的成本。如果你团队里有一个愿意啃源码的工程师Univer 能给你带来的自由度是很多商业产品给不了的。而如果你的业务只需要简单展示和编辑也不追求协同和二次开发那一个成熟稳定、有厂商持续维护的商业表格组件可能是更省心的选择。
