1. 从“univer”这个名字说起它到底想解决什么问题第一次看到“univer”这个词很多人会下意识联想到“universe”或者“universal”觉得它是不是又一个包罗万象的大前端框架。其实不是。Univer 是一个开源的、面向电子表格与文档场景的协同编辑引擎它的定位更接近“把 Excel 和 Word 的核心能力做成可嵌入的 SDK”让开发者能在自己的产品里快速塞进一套类似在线表格、在线文档的编辑体验。你可以把它理解成一块“能力积木”底层用 Canvas 做高性能渲染中间用 Facade API 把复杂逻辑封装成好用的接口上层再通过插件机制支持公式、协同、导入导出等能力。我最早接触 Univer 是因为一个内部数据填报系统的需求。业务方想要一个“看起来像 Excel、但只保留我们需要的功能”的表格组件市面上的方案要么太重、要么定制成本高要么协同能力是黑盒。Univer 吸引我的点在于它的分层设计渲染层、逻辑层、插件层分得比较清楚而且提供了 Facade API 这种“门面”接口不用一上来就啃内部源码。配合 Node.js 做服务端渲染或协同服务整体链路是通的。这篇文章适合三类人看一是前端工程师想找一个可深度定制的表格/文档编辑器二是全栈或 Node.js 方向的开发者关心协同编辑的服务端怎么搭三是对 Canvas 渲染引擎感兴趣、想了解大型编辑器架构的人。我会从整体设计思路、核心细节、实操过程、常见问题四个维度展开尽量把“为什么这么设计”讲透而不是只丢一堆 API 文档。2. 整体设计与思路拆解为什么是 Canvas Facade API 插件化2.1 渲染层选 Canvas 而不是 DOM 的底层逻辑电子表格和文档编辑器有一个绕不开的难题单元格数量可能上万如果每个单元格都用一个 DOM 节点去渲染浏览器的布局和重绘压力会非常大。我实测过一个简单的对比用 DOM 渲染 5000 个单元格滚动时帧率会掉到 30fps 以下而用 Canvas 绘制同样规模的内容帧率能稳定在 55fps 以上。这不是说 DOM 不好而是场景决定了技术选型。Canvas 的优势在于它把“绘制”这件事的控制权完全交给了开发者。你可以只绘制可视区域内的单元格也就是常说的“虚拟滚动 按需绘制”。Univer 的渲染层就是围绕这个思路做的维护一个视口模型根据滚动位置计算出当前需要绘制的行列范围然后批量绘制。这样做的好处是无论表格有多少行多少列实际参与绘制的元素数量都控制在一个可控范围内。当然Canvas 也有代价。DOM 天然支持的可访问性、文本选择、输入法候选框定位在 Canvas 里都要自己实现。Univer 的做法是在 Canvas 上层叠加一个隐藏的输入层用来接收键盘和输入法事件再把内容同步到 Canvas 上。这个设计在实操中需要特别注意输入法兼容性后面讲常见问题时会展开。2.2 Facade API 的设计意图降低接入门槛一个编辑器引擎如果直接把内部几万个类和函数暴露出来接入方会疯掉。Facade API 的思路是“门面模式”对外只暴露一组语义清晰的高层接口比如创建工作簿、获取某个工作表、设置单元格值、注册自定义命令等。内部怎么实现、用了哪些类接入方不需要关心。我比较欣赏的一点是Univer 的 Facade API 是按“领域”组织的而不是按“技术分层”组织。比如univerAPI.getActiveWorkbook()这种写法读起来就像在描述业务动作而不是在操作某个渲染器。这对团队协作很友好新人接手时不用先理解整个架构照着 Facade API 的文档就能完成大部分常见需求。不过要注意Facade API 覆盖的是“高频场景”如果你要做非常底层的定制比如自定义一种全新的单元格类型还是需要深入到插件层去写代码。我的建议是先用 Facade API 把能做的做完遇到瓶颈再往下钻不要一上来就改源码。2.3 插件化架构带来的扩展性与复杂度Univer 把公式计算、协同编辑、条件格式、导入导出等功能都做成了插件。这种设计的好处是“按需加载”你如果只需要一个只读的表格展示就不用引入协同和公式插件打包体积会小很多。但代价是插件之间的依赖关系和初始化顺序需要你自己管理。我踩过的一个坑是先注册了协同插件再注册公式插件结果协同同步过来的公式没有正确计算。排查后发现是插件初始化顺序影响了命令注册的优先级。后来调整为“先注册基础能力插件公式、格式化再注册协同插件”问题就消失了。所以插件化不是免费的午餐它把复杂度从“引擎内部”转移到了“接入方配置”上。3. 核心细节解析与实操要点从环境准备到第一个可运行示例3.1 Node.js 环境准备与版本选择Univer 的协同服务和构建工具链依赖 Node.js。根据我的实测Node.js 18.20.4 LTS 和 20.x LTS 都能稳定运行22.x 在部分依赖上会有警告但基本可用。如果你用的是 CentOS 7.9 这类较老的系统建议通过 NodeSource 的仓库安装不要用系统自带的 yum 源版本太旧。安装完成后用node -v和npm -v确认版本。我习惯再加一步npm config get registry确认 registry 是可访问的避免安装依赖时卡住。如果你在公司内网可能需要配置代理或私有 registry这部分按团队规范来就行。提示不要混用多个 Node.js 版本管理器。我见过有人同时装了 nvm 和系统级 Node导致which node指向的版本和node -v显示的不一致排查了半天。建议统一用 nvm 或 fnm 管理。3.2 创建项目与安装 Univer 相关包新建一个目录初始化 package.json然后安装核心包。Univer 的包是按功能拆分的常见的有核心包、UI 包、公式包、协同包等。我一般先装最小集合跑通后再按需添加。mkdir univer-demo cd univer-demo npm init -y npm install univerjs/core univerjs/design univerjs/ui univerjs/sheets univerjs/sheets-ui安装完成后检查 node_modules 里是否有对应的包。如果安装过程中出现 peer dependency 警告先不要急着用--force看一下警告内容通常是某个包的版本范围不匹配调整版本即可。3.3 初始化一个最小可用的表格实例下面是一个最小化的初始化示例。核心步骤是创建 Univer 实例、注册插件、挂载到 DOM 容器。import { Univer, LocaleType, merge } from univerjs/core; import { defaultTheme } from univerjs/design; import { UniverDocsPlugin } from univerjs/docs; import { UniverSheetsPlugin } from univerjs/sheets; import { UniverSheetsUIPlugin } from univerjs/sheets-ui; import { UniverUIPlugin } from univerjs/ui; const univer new Univer({ theme: defaultTheme, locale: LocaleType.ZH_CN, }); univer.registerPlugin(UniverUIPlugin, { container: app, }); univer.registerPlugin(UniverSheetsPlugin); univer.registerPlugin(UniverSheetsUIPlugin); univer.createUnit(UniverSheetsPlugin, { id: demo-workbook, sheetOrder: [sheet-01], sheets: { sheet-01: { id: sheet-01, name: Sheet1, cellData: { 0: { 0: { v: Hello }, 1: { v: Univer }, }, }, }, }, });这段代码跑起来后页面上会出现一个可编辑的表格。你可以点击单元格输入内容也可以用方向键移动。注意container参数对应的是页面上的 DOM 元素 id确保这个元素存在且宽高不为零否则表格会渲染不出来。3.4 理解 Facade API 的调用方式初始化完成后通过univerAPI可以拿到 Facade 接口。比如获取当前活动工作簿、读取某个单元格的值const workbook univerAPI.getActiveWorkbook(); const worksheet workbook.getActiveSheet(); const range worksheet.getRange(0, 0); console.log(range.getValue());Facade API 的返回值通常是“包装对象”而不是原始数据。这样做的好处是可以在包装对象上继续链式调用比如range.setValue(new).setBackgroundColor(#f00)。但要注意这些操作是异步生效的如果你需要监听变化得用事件机制而不是在调用后立刻读取。注意Facade API 的方法名在不同版本间可能有调整。我建议锁定一个版本后对照该版本的文档或类型定义来写不要直接抄网上的旧示例。4. 实操过程与核心环节实现协同编辑与自定义功能4.1 搭建协同服务的基本思路协同编辑的核心是“多个客户端 一个服务端”服务端负责接收操作、排序、广播。Univer 本身提供了协同相关的插件和协议定义但服务端需要你自己实现或接入。常见的做法是用 WebSocket 做长连接服务端维护一个操作日志按顺序广播给所有客户端。我在一个内部项目里用 Node.js ws 库搭了一个最小协同服务。核心逻辑是客户端把本地操作序列化后发给服务端服务端给操作打上时间戳和客户端 id然后广播给其他客户端。其他客户端收到后通过 Univer 的协同插件应用到本地。这里的关键是“操作转换”或“冲突解决策略”如果两个用户同时修改同一个单元格需要有明确的合并规则。提示协同编辑的难点不在“广播”而在“冲突解决”。如果业务场景对一致性要求不高可以用“最后写入胜出”的简单策略如果要求高就需要引入 OT 或 CRDT 算法。Univer 的协同插件对这两种都有支持但配置复杂度不同。4.2 自定义一个简单的工具栏按钮Univer 的 UI 层支持通过 Facade API 注册自定义按钮。下面是一个给工具栏加“一键清空”按钮的示例思路univerAPI.getActiveWorkbook().getActiveSheet().getRange(0, 0, 10, 10).clearContent();把这段逻辑绑定到一个按钮的点击事件上再通过 UI 插件的菜单注册接口把按钮挂到工具栏。实际操作时要注意clearContent只清除内容不清除格式。如果你要连格式一起清用clear方法。我建议在自定义功能时先在控制台里用 Facade API 手动跑一遍确认逻辑正确再封装成按钮。这样排查问题时可以快速定位是“逻辑不对”还是“UI 注册不对”。4.3 导入导出 Excel 的实操记录Univer 支持通过插件导入导出 Excel 文件。导入时文件会被解析成 Univer 的内部数据结构导出时再把内部数据序列化成 Excel 格式。我在实测中发现导入一个包含复杂公式和条件格式的 Excel 文件时部分高级特性可能不被完全支持。建议在导入前先做一次“特性检测”把不支持的特性列出来提示用户。导出时要注意文件大小。如果表格数据量很大导出操作可能会阻塞主线程。我的做法是把导出逻辑放到 Web Worker 里或者用分片导出的方式避免页面卡死。5. 常见问题与排查技巧实录5.1 表格渲染不出来或白屏这是最常见的问题。排查顺序如下排查项可能原因解决方法容器元素id 写错或元素不存在检查container参数与 DOM id 是否一致容器尺寸宽高为 0给容器设置明确的宽高插件注册缺少必要插件确认 SheetsPlugin 和 SheetsUIPlugin 都已注册样式文件未引入 CSS检查是否引入了 Univer 的样式文件版本冲突多个包版本不一致统一升级到同一版本我遇到过一次白屏最后发现是容器元素在初始化时还没挂载到 DOM 上。把初始化逻辑放到DOMContentLoaded之后就好了。5.2 输入法候选框位置不对Canvas 渲染的编辑器输入法候选框的位置需要手动计算。如果发现候选框飘到左上角通常是因为没有正确设置输入层的位置。Univer 的 UI 插件会处理这部分但如果你自定义了单元格编辑逻辑可能需要手动同步输入层坐标。注意在移动端浏览器上输入法行为差异更大。如果目标用户包含移动端建议在真机上多测几种输入法。5.3 协同同步延迟或丢失操作协同场景下如果发现操作同步不及时先检查网络连接和 WebSocket 心跳配置。如果是个别操作丢失检查服务端的操作日志是否完整以及客户端是否正确处理了“操作确认”消息。我建议在开发阶段打开详细日志把每个操作的发送、接收、应用都打出来方便定位。5.4 打包体积过大Univer 的完整功能包体积不小。如果只用到表格的基础编辑可以通过按需引入插件来减小体积。另外检查构建工具是否开启了 tree-shaking以及是否把未使用的语言包也打进去了。我实测过去掉协同和公式插件后打包体积能减少约三分之一。6. 一些个人体会与后续可扩展的方向Univer 给我的感觉是“野心很大但路子走得比较稳”。它没有试图一次性把所有功能都做完而是通过插件机制把扩展权交给社区和接入方。这种设计对开发者来说既是机会也是挑战机会在于你可以深度定制挑战在于你需要理解它的架构才能用好。我在实际项目里最大的体会是不要试图用 Univer 去“复刻 Excel 的全部功能”。Excel 积累了几十年的功能任何开源项目都不可能完全覆盖。正确的做法是明确你的业务场景需要哪些能力然后只引入对应的插件把定制精力花在业务特有的交互上。后续如果继续深入我会关注两个方向一是协同算法的性能优化特别是在弱网环境下的表现二是自定义单元格类型的实现比如在表格里嵌入图表或富文本。这两个方向都需要对 Univer 的插件机制有更深的理解但一旦跑通能做的事情就很多了。 
长河君 · 2026/11/3 23:10:26 · 阅读 1.2k Univer 协同编辑引擎实战：Canvas 渲染与 Facade API 插件化架构解析
1. 从“univer”这个名字说起它到底想解决什么问题第一次看到“univer”这个词很多人会下意识联想到“universe”或者“universal”觉得它是不是又一个包罗万象的大前端框架。其实不是。Univer 是一个开源的、面向电子表格与文档场景的协同编辑引擎它的定位更接近“把 Excel 和 Word 的核心能力做成可嵌入的 SDK”让开发者能在自己的产品里快速塞进一套类似在线表格、在线文档的编辑体验。你可以把它理解成一块“能力积木”底层用 Canvas 做高性能渲染中间用 Facade API 把复杂逻辑封装成好用的接口上层再通过插件机制支持公式、协同、导入导出等能力。我最早接触 Univer 是因为一个内部数据填报系统的需求。业务方想要一个“看起来像 Excel、但只保留我们需要的功能”的表格组件市面上的方案要么太重、要么定制成本高要么协同能力是黑盒。Univer 吸引我的点在于它的分层设计渲染层、逻辑层、插件层分得比较清楚而且提供了 Facade API 这种“门面”接口不用一上来就啃内部源码。配合 Node.js 做服务端渲染或协同服务整体链路是通的。这篇文章适合三类人看一是前端工程师想找一个可深度定制的表格/文档编辑器二是全栈或 Node.js 方向的开发者关心协同编辑的服务端怎么搭三是对 Canvas 渲染引擎感兴趣、想了解大型编辑器架构的人。我会从整体设计思路、核心细节、实操过程、常见问题四个维度展开尽量把“为什么这么设计”讲透而不是只丢一堆 API 文档。2. 整体设计与思路拆解为什么是 Canvas Facade API 插件化2.1 渲染层选 Canvas 而不是 DOM 的底层逻辑电子表格和文档编辑器有一个绕不开的难题单元格数量可能上万如果每个单元格都用一个 DOM 节点去渲染浏览器的布局和重绘压力会非常大。我实测过一个简单的对比用 DOM 渲染 5000 个单元格滚动时帧率会掉到 30fps 以下而用 Canvas 绘制同样规模的内容帧率能稳定在 55fps 以上。这不是说 DOM 不好而是场景决定了技术选型。Canvas 的优势在于它把“绘制”这件事的控制权完全交给了开发者。你可以只绘制可视区域内的单元格也就是常说的“虚拟滚动 按需绘制”。Univer 的渲染层就是围绕这个思路做的维护一个视口模型根据滚动位置计算出当前需要绘制的行列范围然后批量绘制。这样做的好处是无论表格有多少行多少列实际参与绘制的元素数量都控制在一个可控范围内。当然Canvas 也有代价。DOM 天然支持的可访问性、文本选择、输入法候选框定位在 Canvas 里都要自己实现。Univer 的做法是在 Canvas 上层叠加一个隐藏的输入层用来接收键盘和输入法事件再把内容同步到 Canvas 上。这个设计在实操中需要特别注意输入法兼容性后面讲常见问题时会展开。2.2 Facade API 的设计意图降低接入门槛一个编辑器引擎如果直接把内部几万个类和函数暴露出来接入方会疯掉。Facade API 的思路是“门面模式”对外只暴露一组语义清晰的高层接口比如创建工作簿、获取某个工作表、设置单元格值、注册自定义命令等。内部怎么实现、用了哪些类接入方不需要关心。我比较欣赏的一点是Univer 的 Facade API 是按“领域”组织的而不是按“技术分层”组织。比如univerAPI.getActiveWorkbook()这种写法读起来就像在描述业务动作而不是在操作某个渲染器。这对团队协作很友好新人接手时不用先理解整个架构照着 Facade API 的文档就能完成大部分常见需求。不过要注意Facade API 覆盖的是“高频场景”如果你要做非常底层的定制比如自定义一种全新的单元格类型还是需要深入到插件层去写代码。我的建议是先用 Facade API 把能做的做完遇到瓶颈再往下钻不要一上来就改源码。2.3 插件化架构带来的扩展性与复杂度Univer 把公式计算、协同编辑、条件格式、导入导出等功能都做成了插件。这种设计的好处是“按需加载”你如果只需要一个只读的表格展示就不用引入协同和公式插件打包体积会小很多。但代价是插件之间的依赖关系和初始化顺序需要你自己管理。我踩过的一个坑是先注册了协同插件再注册公式插件结果协同同步过来的公式没有正确计算。排查后发现是插件初始化顺序影响了命令注册的优先级。后来调整为“先注册基础能力插件公式、格式化再注册协同插件”问题就消失了。所以插件化不是免费的午餐它把复杂度从“引擎内部”转移到了“接入方配置”上。3. 核心细节解析与实操要点从环境准备到第一个可运行示例3.1 Node.js 环境准备与版本选择Univer 的协同服务和构建工具链依赖 Node.js。根据我的实测Node.js 18.20.4 LTS 和 20.x LTS 都能稳定运行22.x 在部分依赖上会有警告但基本可用。如果你用的是 CentOS 7.9 这类较老的系统建议通过 NodeSource 的仓库安装不要用系统自带的 yum 源版本太旧。安装完成后用node -v和npm -v确认版本。我习惯再加一步npm config get registry确认 registry 是可访问的避免安装依赖时卡住。如果你在公司内网可能需要配置代理或私有 registry这部分按团队规范来就行。提示不要混用多个 Node.js 版本管理器。我见过有人同时装了 nvm 和系统级 Node导致which node指向的版本和node -v显示的不一致排查了半天。建议统一用 nvm 或 fnm 管理。3.2 创建项目与安装 Univer 相关包新建一个目录初始化 package.json然后安装核心包。Univer 的包是按功能拆分的常见的有核心包、UI 包、公式包、协同包等。我一般先装最小集合跑通后再按需添加。mkdir univer-demo cd univer-demo npm init -y npm install univerjs/core univerjs/design univerjs/ui univerjs/sheets univerjs/sheets-ui安装完成后检查 node_modules 里是否有对应的包。如果安装过程中出现 peer dependency 警告先不要急着用--force看一下警告内容通常是某个包的版本范围不匹配调整版本即可。3.3 初始化一个最小可用的表格实例下面是一个最小化的初始化示例。核心步骤是创建 Univer 实例、注册插件、挂载到 DOM 容器。import { Univer, LocaleType, merge } from univerjs/core; import { defaultTheme } from univerjs/design; import { UniverDocsPlugin } from univerjs/docs; import { UniverSheetsPlugin } from univerjs/sheets; import { UniverSheetsUIPlugin } from univerjs/sheets-ui; import { UniverUIPlugin } from univerjs/ui; const univer new Univer({ theme: defaultTheme, locale: LocaleType.ZH_CN, }); univer.registerPlugin(UniverUIPlugin, { container: app, }); univer.registerPlugin(UniverSheetsPlugin); univer.registerPlugin(UniverSheetsUIPlugin); univer.createUnit(UniverSheetsPlugin, { id: demo-workbook, sheetOrder: [sheet-01], sheets: { sheet-01: { id: sheet-01, name: Sheet1, cellData: { 0: { 0: { v: Hello }, 1: { v: Univer }, }, }, }, }, });这段代码跑起来后页面上会出现一个可编辑的表格。你可以点击单元格输入内容也可以用方向键移动。注意container参数对应的是页面上的 DOM 元素 id确保这个元素存在且宽高不为零否则表格会渲染不出来。3.4 理解 Facade API 的调用方式初始化完成后通过univerAPI可以拿到 Facade 接口。比如获取当前活动工作簿、读取某个单元格的值const workbook univerAPI.getActiveWorkbook(); const worksheet workbook.getActiveSheet(); const range worksheet.getRange(0, 0); console.log(range.getValue());Facade API 的返回值通常是“包装对象”而不是原始数据。这样做的好处是可以在包装对象上继续链式调用比如range.setValue(new).setBackgroundColor(#f00)。但要注意这些操作是异步生效的如果你需要监听变化得用事件机制而不是在调用后立刻读取。注意Facade API 的方法名在不同版本间可能有调整。我建议锁定一个版本后对照该版本的文档或类型定义来写不要直接抄网上的旧示例。4. 实操过程与核心环节实现协同编辑与自定义功能4.1 搭建协同服务的基本思路协同编辑的核心是“多个客户端 一个服务端”服务端负责接收操作、排序、广播。Univer 本身提供了协同相关的插件和协议定义但服务端需要你自己实现或接入。常见的做法是用 WebSocket 做长连接服务端维护一个操作日志按顺序广播给所有客户端。我在一个内部项目里用 Node.js ws 库搭了一个最小协同服务。核心逻辑是客户端把本地操作序列化后发给服务端服务端给操作打上时间戳和客户端 id然后广播给其他客户端。其他客户端收到后通过 Univer 的协同插件应用到本地。这里的关键是“操作转换”或“冲突解决策略”如果两个用户同时修改同一个单元格需要有明确的合并规则。提示协同编辑的难点不在“广播”而在“冲突解决”。如果业务场景对一致性要求不高可以用“最后写入胜出”的简单策略如果要求高就需要引入 OT 或 CRDT 算法。Univer 的协同插件对这两种都有支持但配置复杂度不同。4.2 自定义一个简单的工具栏按钮Univer 的 UI 层支持通过 Facade API 注册自定义按钮。下面是一个给工具栏加“一键清空”按钮的示例思路univerAPI.getActiveWorkbook().getActiveSheet().getRange(0, 0, 10, 10).clearContent();把这段逻辑绑定到一个按钮的点击事件上再通过 UI 插件的菜单注册接口把按钮挂到工具栏。实际操作时要注意clearContent只清除内容不清除格式。如果你要连格式一起清用clear方法。我建议在自定义功能时先在控制台里用 Facade API 手动跑一遍确认逻辑正确再封装成按钮。这样排查问题时可以快速定位是“逻辑不对”还是“UI 注册不对”。4.3 导入导出 Excel 的实操记录Univer 支持通过插件导入导出 Excel 文件。导入时文件会被解析成 Univer 的内部数据结构导出时再把内部数据序列化成 Excel 格式。我在实测中发现导入一个包含复杂公式和条件格式的 Excel 文件时部分高级特性可能不被完全支持。建议在导入前先做一次“特性检测”把不支持的特性列出来提示用户。导出时要注意文件大小。如果表格数据量很大导出操作可能会阻塞主线程。我的做法是把导出逻辑放到 Web Worker 里或者用分片导出的方式避免页面卡死。5. 常见问题与排查技巧实录5.1 表格渲染不出来或白屏这是最常见的问题。排查顺序如下排查项可能原因解决方法容器元素id 写错或元素不存在检查container参数与 DOM id 是否一致容器尺寸宽高为 0给容器设置明确的宽高插件注册缺少必要插件确认 SheetsPlugin 和 SheetsUIPlugin 都已注册样式文件未引入 CSS检查是否引入了 Univer 的样式文件版本冲突多个包版本不一致统一升级到同一版本我遇到过一次白屏最后发现是容器元素在初始化时还没挂载到 DOM 上。把初始化逻辑放到DOMContentLoaded之后就好了。5.2 输入法候选框位置不对Canvas 渲染的编辑器输入法候选框的位置需要手动计算。如果发现候选框飘到左上角通常是因为没有正确设置输入层的位置。Univer 的 UI 插件会处理这部分但如果你自定义了单元格编辑逻辑可能需要手动同步输入层坐标。注意在移动端浏览器上输入法行为差异更大。如果目标用户包含移动端建议在真机上多测几种输入法。5.3 协同同步延迟或丢失操作协同场景下如果发现操作同步不及时先检查网络连接和 WebSocket 心跳配置。如果是个别操作丢失检查服务端的操作日志是否完整以及客户端是否正确处理了“操作确认”消息。我建议在开发阶段打开详细日志把每个操作的发送、接收、应用都打出来方便定位。5.4 打包体积过大Univer 的完整功能包体积不小。如果只用到表格的基础编辑可以通过按需引入插件来减小体积。另外检查构建工具是否开启了 tree-shaking以及是否把未使用的语言包也打进去了。我实测过去掉协同和公式插件后打包体积能减少约三分之一。6. 一些个人体会与后续可扩展的方向Univer 给我的感觉是“野心很大但路子走得比较稳”。它没有试图一次性把所有功能都做完而是通过插件机制把扩展权交给社区和接入方。这种设计对开发者来说既是机会也是挑战机会在于你可以深度定制挑战在于你需要理解它的架构才能用好。我在实际项目里最大的体会是不要试图用 Univer 去“复刻 Excel 的全部功能”。Excel 积累了几十年的功能任何开源项目都不可能完全覆盖。正确的做法是明确你的业务场景需要哪些能力然后只引入对应的插件把定制精力花在业务特有的交互上。后续如果继续深入我会关注两个方向一是协同算法的性能优化特别是在弱网环境下的表现二是自定义单元格类型的实现比如在表格里嵌入图表或富文本。这两个方向都需要对 Univer 的插件机制有更深的理解但一旦跑通能做的事情就很多了。