不设主标题直接从二级标题开始。内容围绕univer在线表格自定义填报场景展开融合技术拆解和实操经验确保干货密度和阅读节奏。1. 项目全景与场景拆解第一次看到“univer”这个词可能很多人会把它和“universal”或者某个音乐节品牌搞混。但在前端表格场景里Univer是一个非常值得关注的开源方案它要做的是把电子表格、文档和幻灯片从微软Office和Google套件的手里“解放”出来以TypeScript SDK的形式嵌入你自己的Web应用让你拥有一个可以完全掌控的在线表格内核。我之所以想写Univer是因为最近在做的一个内部数据收集平台正好撞上了这类需求的典型痛点运营同学需要每周下发一张表让各业务线填写本周的业绩进度、风险事项和资源申请但又不能让他们随便改标题、动公式、删列。传统做法要么是发Excel下去再收回来人工合并要么是套个低代码表单但完全失去表格的灵活性。Univer的出现给了我一个很舒服的中间态保留表格的操作体验同时通过权限区域控制做到“你只能填我允许你填的格子”。这篇内容围绕Univer展开重点拆解三件事Univer的核心能力边界在哪里、如何快速把它接入现有前端工程、以及如何精准实现“用户只能填写指定单元格、其他单元格锁定不可修改”这个高频业务需求。适合正在做在线表格、数据填报、权限管控类产品的开发者也适合技术选型阶段想评估Univer是否能扛住业务的团队Leader或架构师。1.1 Univer到底是什么先给Univer一个定位它是一个开源的、基于Canvas渲染的电子表格SDK核心语言是TypeScript支持通过npm引入可以无缝嵌入Vue、React、甚至原生JS项目。它不只是“画一个表格”而是自己实现了公式引擎、单元格样式、筛选排序、数据透视、协同编辑等一系列原本依赖桌面办公软件的能力。在我实际体验中Univer最让人惊喜的是它的架构思路。它把表格拆成了几个独立模块核心表格引擎UniverSheet、文档模块UniverDoc、幻灯片模块UniverSlide同时支持插件式扩展。这意味着你不需要把所有功能全部加载可以按需引入。比如只做填报表单那就只引入Sheet核心和少量交互插件产物体积完全可以控制在合理范围内。另一个关键点是Univer采用了Canvas渲染方案。做过表格类产品的同学应该清楚DOM渲染在单元格数量超过几千行以后会卡到怀疑人生而Canvas渲染大幅降低了DOM节点数量让大数据量的滚动和编辑保持流畅。Univer在这一块的处理很成熟实测下来万级单元格的滚动和公式计算都还在可用范围。1.2 为什么会有“用户填写部分单元格其他单元格不可改”这类需求先说一个业务背景在企业内部表格从来不只是“记录数据的工具”更多的是“流程载体”。比如人事部门收集员工绩效自评表格中既有固定列姓名、部门、岗位、绩效周期这些需要系统预填又有开放列自我评价、关键成果、下季度目标这些需要员工填写。如果整个表格完全开放员工随手改掉固定列的信息轻则数据汇总乱七八糟重则影响后续的评审批次。再比如供应链场景采购计划表下发到各门店时总部维护的SKU编码、单价、安全库存是强管控数据门店只需要填入“建议订货量”。如果不做锁定总部的定价策略就形同虚设。所以在Univer里实现单元格级只读/可编辑控制本质上是把“表单的逻辑”和“表格的体验”结合起来既保证数据质量又减少填写抵触感。这类需求在过去往往通过Excel的区域保护实现但桌面Excel有两个问题一是分发给非技术同事后对方本地版本可能不支持或者一不小心取消保护把结构弄乱二是数据回收和汇总的工作量巨大完全是重复劳动。Univer这类在线表格方案把权限和保护机制内置到Web端用户打开浏览器就能填填写完成数据直接入库彻底绕开了线下文件流转的那一整套冗余流程。1.3 技术选型思路为什么值得评估Univer市面上的在线表格方案其实不少严格来说可以分为三类第一类是纯前端展示型组件比如一些只读表格库能渲染但编辑能力很弱第二类是完整业务系统功能全但定制门槛高比如套用某些低代码平台第三类就是Univer这类可嵌入的表格引擎它给了你最高灵活度。选择Univer的另一个理由在于它的扩展性。你不用接受“表格引擎只能做表格”的局限它内置了命令机制和插件机制单元格的右键菜单、快捷键、按钮交互都可以自己定义。也就是说你在“Univer表格”之上完全可以再叠加一层业务语义比如把某一列做成选择器、把某个按钮绑定你的提交接口、在用户修改某个单元格后实时触发后端存储。这种可编程性让你不是在使用一个成品软件而是在搭建一个自己的表格基础设施。当然Univer不是银弹。它目前的生态成熟度相比一些二三十年的桌面老牌办公软件仍有差距复杂打印模板、高级图表类型等还在完善中。但如果你的核心诉求是“在线表格 业务定制 数据收集”Univer是一个值得花时间押注的方向。2. 环境准备与基础初始化在开始写代码之前我强烈建议先花五分钟把Univer的官方Demo跑起来先感受一下它的交互节奏和样式风格再决定要不要迁移到自己项目里。Univer的文档站提供了在线Playground也有对应的npm包发布周期基本是每个月都会有版本更新不同版本之间的API可能存在一定差异。下面按照我最近一次实战的版本为准做说明如果遇到接口对不上的情况优先以你安装版本的类型定义为准。2.1 初始化一个前端工程我这次使用的是Vite Vue 3的组合这也是Univer官方示例中覆盖较全的组合之一。如果你习惯React官方同样提供了对应的示例核心逻辑大同小异只是挂载方式略有差别。初始化命令很简单npm create vitelatest univer-demo -- --template vue-ts cd univer-demo npm install npm run dev如果这一步你已经很熟悉可以跳过。但这里想提醒一个细节Univer对构建工具链有一定要求尽量使用较新版本的Vite和TypeScript避免因为ESM模块兼容性问题导致启动报错。我个人曾经在一个老的Webpack 4工程里尝试接入Univer折腾了半天的loader配置才跑起来后来换到Vite环境三四分钟就走完了整个流程。2.2 安装Univer核心依赖Univer的包结构比较复杂初次接触容易装错。拿我这次用到的版本来说核心依赖有四个方向基础核心、Sheet引擎、UI框架和公式引擎。你需要把它们一起安装缺一不可。npm install univerjs/core univerjs/sheets univerjs/sheets-ui univerjs/ui univerjs/sheets-formula如果还需要数据透视、查找替换、条件格式等高级能力可以继续安装对应的插件包比如univerjs/sheets-pivot。但是基础版本不要贪多装太多插件可能会增加打包体积也会让初始化流程变得复杂。按需加载是Univer设计哲学里非常重要的一点实际项目中务必遵守。2.3 创建Univer实例并渲染表格当你完成依赖安装后最小可用示例大概是这样。创建src/univer.ts文件单独把Univer的初始化逻辑抽出来方便后续在Vue组件里调用。import { LocaleType, LogLevel, Univer } from univerjs/core; import { defaultTheme } from univerjs/design; import { UniverFormulaPlugin } from univerjs/sheets-formula; import { UniverSheetsPlugin } from univerjs/sheets; import { UniverSheetsUIPlugin } from univerjs/sheets-ui; import { UniverUIPlugin } from univerjs/ui; export function createUniver(container: HTMLElement) { const univer new Univer({ theme: defaultTheme, locale: LocaleType.ZH_CN, logLevel: LogLevel.WARN, locales: { [LocaleType.ZH_CN]: { ui: {}, sheets: {}, sheetsUI: {}, }, }, }); univer.registerPlugin(UniverSheetsPlugin, { // 空配置即可后续通过API操作表格 }); univer.registerPlugin(UniverFormulaPlugin); univer.registerPlugin(UniverUIPlugin, { container, }); univer.registerPlugin(UniverSheetsUIPlugin, { container, }); return univer; }然后在Vue组件里挂载一个div调用createUniver并创建Workbook。这里有一个容易踩坑的点初始化Univer实例时传入的container必须是已经挂载到DOM上的元素否则Canvas无法正确计算尺寸。我一开始在onMounted之前就去调用初始化函数结果表格渲染出来一片空白后来调整了生命周期才解决。创建Workbook的代码和初始化Univer是分开的通过univer.createUniverSheet()方法来创建import { FUniver } from univerjs/core; // 在createUniver返回后调用 const univerAPI FUniver.newAPI(univer); // 创建一个默认工作簿带一个工作表 univerAPI.createUniverSheet({ name: 业务填报, sheetOrder: [sheet1], sheets: { sheet1: { name: sheet1, rowCount: 50, columnCount: 20, cellData: {}, }, }, });到这里一个可交互的在线表格就已经嵌入到页面中了。用户可以自由编辑任意单元格也可以调整行列宽度、应用基础样式。接下来要做的就是把它从“通用表格”改造成“带权限控制的填报表格”。2.4 初始化配置中的关键参数说明第一次接触Univer的配置项时可能会被locales和theme这些字段绕晕。这里简单说明一下theme控制UI组件的整体外观包括颜色、圆角、间距等官方提供了默认主题但业务中建议根据自己系统的设计规范做定制locale控制右键菜单、工具栏提示等文案语言国内业务直接使用LocaleType.ZH_CN即可logLevel建议在开发阶段保持WARN因为Univer的INFO日志比较冗长会干扰调试。还有一个常被忽视的点Univer启动时会读取容器尺寸来渲染画布因此如果容器宽度变化比如侧边栏折叠、窗口缩放需要调用univerAPI.getSheetApp()?.refreshCanvas()之类的刷新方法否则会出现渲染残影或白边。这些边界情况在真实产品里很容易被测试忽略但在用户那边体验就是“表格卡了”。3. 核心需求实现单元格填写权限控制前面提到了业务场景用户需要填写某些单元格但绝对不能碰其他单元格。Univer原生提供了一套工作表保护机制概念上和Excel的“保护工作表”很接近但它做得更细可以指定在保护范围内依然允许编辑某些区域。3.1 理解Univer的保护机制保护机制分为两个层级工作表级保护和区域级例外。当你对某个工作表开启保护后默认所有单元格变为只读用户点击后无法进入编辑态单元格也不响应输入。然后你可以添加若干“例外区域”也就是几个选区的配置这些选区内的单元格在保护状态下依然允许编辑。用权限模型的视角来看这个设计非常优雅保护是“默认拒绝”例外是“白名单”。比起默认开放再手动锁一堆单元格白名单模式明显更安全也更符合真实业务场景。因为业务上固定列通常远多于可填写列你只需要为可填写区域建立白名单其他结构数据自动受到保护。Univer的API把这种逻辑封装在getSheetCommandBar()或getSheetApp()等接口中。不同版本接口名称可能略有不同但核心操作一致先开启工作表的保护开关再设置一个或多个允许编辑的选区。3.2 实现步骤设置可编辑区域下面是基于FUniver API实现的完整示例。假设sheet1中需要让用户填写B2:C10和F2:F20两个区域其他区域全部锁定import { FUniver } from univerjs/core; // 获取当前激活的工作表 const worksheet univerAPI.getActiveWorkbook()?.getActiveSheet(); // 开启工作表保护 worksheet?.getSheetConfig()?.protection?.unlock?.(); // 如果保护对象本身不存在可以通过命令直接设置 univerAPI.getCommandServer().executeCommand({ id: sheet.command.set-worksheet-protection, params: { unitId: workbookId, subUnitId: sheetId, protection: { locked: true, password: null, }, }, });如果你觉得命令ID太底层也可以用更简便的univerAPI.getSheetApp()来操作。我这里引用一种较为直观的写法实际以官方类型定义为准// 另一种更直观的写法 const sheetApp univerAPI.getSheetApp(); sheetApp.getActiveSheet()?.protect({ password: , // 设置白名单选区 ranges: [ { startRow: 1, startColumn: 1, endRow: 9, endColumn: 2 }, // B2:C10索引从0开始 { startRow: 5, startColumn: 5, endRow: 19, endColumn: 5 }, // F2:F20 ], });这里需要注意选区索引是从0开始的也就是说Excel视角里的第2行对应索引1第2列对应索引1。第一次写的时候很容易把行列坐标错位一格导致用户打开后发现应该可编辑的格子被锁死。解决方法是配置完后在页面里多点击测试几个边界单元格确保每个白名单选区覆盖正确。另外如果你希望在用户填写完单元格后自动锁定防止二次修改可以通过监听编辑完成事件在该单元格写入内容后动态将其移除出白名单。这种动态权限控制场景Univer也是支持的只需要重新设置保护选区即可。3.3 按行按列整行整列保护有些业务更简单粗暴某一整列固定不可修改其他列开放。这种情况不需要精确到单元格选区可以在保护范围上配置整列选区。把startColumn和endColumn设成同一列号startRow从0到总行数-1就能覆盖整列。举个例子在20行15列的表格中锁定A列索引0和B列索引1其余列开放sheetApp.getActiveSheet()?.protect({ password: , ranges: [ { startRow: 0, startColumn: 0, endRow: 19, endColumn: 0 }, { startRow: 0, startColumn: 1, endRow: 19, endColumn: 1 }, ], });反过来说如果希望整张表格都开放填写只是锁掉表头和汇总行则把startRow和endRow设置在表头区和汇总区即可。我实际做配置时发现Univer在设置多选区保护时的性能表现相当不错十几个区域同时存在也没有出现明显的交互卡顿说明它在底层对选区做了高效管理。关于密码保护参数必须重点提醒一句Univer的password字段在纯前端场景下只能防君子不能防小人。因为前端代码本质上暴露在浏览器里任何密码都能被调试工具轻易获取。如果你有强管控需求比如防止用户通过控制台篡改表格结构正确的做法是后端校验用户提交数据时后端重新校验哪些字段允许修改以服务端数据为准。Univer前端的锁更多是为了“引导用户不误操作”和“维持界面结构稳定”而不是真正的安全边界。3.4 前端交互与可编辑区域视觉提示设置完保护之后还有一个产品体验问题用户怎么知道哪些格子可以填哪些格子不能碰如果在UI上没有明显区分用户会在锁定区域反复点击然后困惑地发现自己什么都输入不了。我做了两件事来解决这个问题。第一通过Univer的样式接口给可编辑区域添加浅黄色背景模拟Excel中“输入区”的习惯视觉第二在页面顶部加一段提示文案“仅黄色区域可填写其余区域已锁定”。样式设置通过单元格样式API完成可以批量应用const styles { backgroundColor: #FFF3CD, border: { b: { s: 1, cl: { rgb: #D8D8D8 }, }, }, }; univerAPI.getSheetApp() ?.getActiveSheet() ?.setRangeStyle({ startRow: 1, startColumn: 1, endRow: 9, endColumn: 2, }, styles);这里用到的颜色是柔和的淡黄色用户视觉上不会觉得刺眼又能明显感知“这块区域和其他格子不一样”。如果你的设计系统里对可填写区域有既定的交互色直接替换即可。重要提示千万不要把可编辑区域的底色设置成和锁定区域完全一样否则用户体验会非常割裂。实在没有设计资源时选用低饱和度的暖色系是最安全的选择。4. 需求进阶数据校验、事件监听与提交当用户填写完表格之后数据的收集和校验才是真正体现工程能力的地方。Univer提供了一套事件系统可以捕获单元格内容变更也支持内置数据校验规则。两者结合可以让你的填报表单变成一个完整的数据采集应用。4.1 单元格数据校验Univer目前支持多种数据校验规则包括整数、小数、日期、文本长度、下拉列表等。跳转到校验设置的方式不同版本略有差异但核心思路都是给选区绑定校验规则。比如我要限制C列索引2只能填写1-100之间的整数代码大概长这样univerAPI.getSheetApp() ?.getActiveSheet() ?.addDataValidation({ ranges: [{ startRow: 1, startColumn: 2, endRow: 10, endColumn: 2 }], rule: { type: whole, operator: between, formula1: 1, formula2: 100, allowBlank: true, showErrorMessage: true, errorMessage: 请输入1到100之间的整数, }, });校验规则配置成功后用户输入非法值时会看到红色的提示气泡输入值也不会被写入到单元格中。这种即时反馈比后端校验的体验好很多能有效降低数据录入的错误率。需要注意的是不同版本对dataValidation的类型定义可能不一样有些用字符串type有些用枚举对象。配置时多翻一下自己项目里node_modules/univerjs/sheets下的类型定义文件比在网上搜答案更高效。4.2 监听用户填写事件事件监听是Univer接入业务后端的重要桥梁。当用户修改某个单元格时你需要实时感知可能用于自动保存、联动计算或者防丢失。Univer底层基于命令模式单元格内容变化一般会触发command执行。网上很多帖子提到监听onCellChange之类的事件但实际不同版本差异较大我这里提供一种比较通用且稳定的方式监听命令执行完成事件。import { ICommandService } from univerjs/core; const commandService univerAPI.getCommandServer(); const subscription commandService.onCommandExecuted((command) { if (command.id sheet.command.set-range-values || command.id?.includes(set-range-values)) { // 这里能拿到更新的范围和数据 const params command.params; // 触发你自己的保存逻辑 saveToBackend(params); } });这种方式的好处是不需要关心具体UI操作路径无论是用户敲键盘、粘贴、拖拽填充最终都会经过命令层你都能捕捉到。在测试中我发现粘贴大批量数据时会触发一次包含完整范围更新的命令因此保存接口要做一下节流或者批量提交避免被高频触发打爆。另外Univer还暴露了onCellEdit之类的基础交互事件如果你的需求仅仅是“用户正在编辑时给个状态提示”用基础交互事件就够了。但如果要精确拿到变更后的单元格数据强烈建议走命令监听。4.3 用户填写完成后如何提交数据填报表单的最终目标是拿到结构化数据。这里有一个高效的做法不采用“监听每次变更 实时提交”策略而是让用户填完后点击页面上的“提交”按钮然后统一读取整个表格的数据区域一次性传给后端。读取数据可以用getRangeValues之类的API。举个例子读取A1:F20的全部数据const range univerAPI.getSheetApp() ?.getActiveSheet() ?.getRange({ startRow: 0, startColumn: 0, endRow: 19, endColumn: 5, }); const values range?.getValues(); // values是二维数组按行列组织拿到二维数组后可以把它映射成你业务需要的JSON结构。比如每行代表一条数据行内字段按固定列索引取值然后批量上传到你的服务端接口。这种设计的好处是用户填写过程完全是轻量的本地交互只在提交时才产生网络请求服务端压力很小而且数据一致性更好。我个人的建议是把表格区域的读取逻辑封装成一个工具函数接收起止行列参数返回结构化数据。这样无论是导出Excel、打印还是提交后端你都能复用同一套数据获取逻辑。4.4 扩展把Univer接入你自己的数据存储如果只是做一个纯前端DemoUniver的本地数据已经够用。但真实业务中数据需要持久化。常见的做法有两种。第一种将Univer的Workbook数据整体序列化存储。Univer提供了getSnapshot()方法可以导出当前工作簿的完整快照包括样式、数据、甚至公式。后端只需要把这份JSON存到数据库或对象存储下次打开时用createUniverSheet(snapshot)恢复即可。这种方式适合“整个表格都是业务流程”的场景比如合同模板、项目计划表。第二种按业务字段提取后存入关系型数据库。就像上一小节说的把二维数组映射成结构化记录每条记录对应数据库中的一行。这种方式适合“表格只是录入界面、数据需要参与统计”的业务比如员工绩效填报、门店订货单。两种方案各有利弊。整体快照简单、恢复快但是不方便做细粒度的数据统计和查询结构化提取方便后端做数据分析但需要你维护字段映射关系。如果业务比较灵活也可以两者结合先存快照再异步解析出结构化数据。这块根据你团队的能力和资源来决定没有绝对的标准答案。5. 常见问题与排查实录接入Univer快一个月我踩了不少坑这里整理几个高频问题和对应的排查思路希望能帮后来者省点时间。5.1 问题速查表现象可能原因排查思路表格渲染空白容器未挂载或高度为0检查初始化时机确认容器尺寸非空保护设置不生效API版本差异或选区配置错误打印工作表配置确认锁定状态选区行列错位索引从0开始业务概念从1开始对比边界单元格逐一验证黏贴数据频繁触发保存命令监听未节流给保存逻辑加防抖或批量合并本地保护密码被绕过前端密码本身不安全后端重新校验权限前端只做交互限制大数据量表头闪烁Canvas刷新问题调用刷新API或检查容器尺寸变化公式计算结果不显示公式插件未注册检查UniverFormulaPlugin是否安装这张表是我实际开发中最常遇到的情况如果你碰到了其他怪问题大概率可以从Univer的GitHub issues里找到答案。这里想特别强调Univer的版本更新很快很多老文章里的API已经过时排查问题时优先看当前版本的类型定义和Changelog比盲目搜索更靠谱。5.2 几个典型的坑逐个拆解第一个坑是容器尺寸为0导致的空白画布。Vue项目里常见于使用v-if控制表格区域的显隐v-if刚变为true时DOM元素尚未渲染完毕此时初始化Univer会拿到0x0的尺寸。解决办法是把初始化逻辑放在$nextTick里或者在容器稳定显示后的回调中调用。第二个坑是保护状态的选区坐标写错。前面提到过索引从0开始但更隐蔽的问题是很多人在配置表格时设置了固定表头或者在选区里包含了冻结行列的区域导致实际可视坐标和表格数据坐标不一致。我的经验是在配置保护之前先在控制台打印一下目标选区的实际数据内容确认数据落在预期坐标再进行保护设置。第三个坑是单元格样式覆盖。如果你设置了背景色之后用户在某次操作中通过工具栏修改了单元格样式那么样式会被覆盖你的“可编辑区域黄色提示”可能丢失。解决方案有几种要么在保护设置的同时通过样式接口锁定样式要么在合适的时机重新应用样式要么干脆不用颜色做提示而用边框或备注做引导。第四個坑是数据校验规则和自然输入之间的冲突。如果给某列设置了日期校验用户输入格式不符合时Univer会阻止写入但有些时候用户输入的日期确实在业务上是合法的比如“2024.5.1”排除了但用户就是习惯了这种写法。考虑到国内用户输入习惯的多样性我建议对日期这类校验放宽格式兼容或者在填写说明里明确格式示例而不是让用户猜测。5.3 性能与加载优化心得Univer的按需加载机制做得不错但如果你把一堆插件全部注册进去打包体积还是会明显增大。我这里有两个实测有效的优化手段。第一个手段是路由级懒加载。如果你的Univer表格只在某个特定页面使用就不要在全局入口注册而是把Univer的初始化放进该路由的页面对应代码块里配合Vite的异步组件功能让表格相关代码在进入页面时才加载。第二个手段是分页加载或虚拟数据。Univer本身渲染性能不算差但如果你一次性塞入超大表格初始化的序列化解析时间还是会有感知。对于填报表单这种场景通常几十行上百行就足够了把行数和列数控制在合理范围不仅加载快而且用户操作起来也不会觉得“空荡荡的”。另外如果你有数据量很大的表格需要展示建议多关注Univer的虚拟滚动配置。在初始化工作表时可以设置合适的可视区域和数据缓存策略避免一次性渲染所有行。这一点在真实业务里影响很大因为用户并不会真的滚动到第50000行但表格引擎如果一次性准备所有数据内存占用和渲染压力都会偏高。5.4 版本差异注意事项Univer目前还处于快速迭代期版本之间的API变动比较频繁。最明显的例子是我之前参考的文档里还在用UniverSheet和UniverUI的注册方式但新版本中核心入口变成了Univer实例加插件的模式。如果你在接入旧版示例代码时报错不要怀疑自己的代码先确认一下安装的版本号。我的建议是接项目的时候先固定某个版本比如package.json里写死版本号不要随手用^范围自动升级否则某天依赖更新后整个API全部变脸排查成本非常高。等业务稳定后再单独评估是否需要升级同时查阅官方迁移指南。这种“版本保守”策略对于还在快速演进的开源库来说是保护自己项目稳定的重要习惯。6. 实操经验小结与后续扩展思路写到这里Univer的核心使用链路已经完整走通从环境搭建、初始化实例到设置单元格权限、校验、数据提交再到问题排查和性能优化。这里再分享几点我在实际项目中特别受用的体会。第一点Univer的上手成本并没有想象中低它有一套自己的领域模型和命令体系你得花一点时间去理解它的“插件注册”“命令流”“快照数据”这些概念。但一旦理解了它的开放性能让你做出非常多定制化功能而不用去逆向别人封装好的黑盒。这种“先难后易”的曲线适合有足够时间投入的团队不太适合明天就要上线的应急项目。第二点配合后端表单能力会更强大。Univer本身是前端表格引擎它不关心数据的最终归宿在哪里。你可以把Univer当作一个数据录入前端后面接审批流、权限系统、BI数据仓库都是水到渠成的事情。关键在于设计好前后端的数据契约表格的坐标映射要和你后端的数据模型对齐这个需要提前规划。后续如果有精力我可能会继续拓展这几个方向Univer和协同编辑的结合、自定义渲染器实现业务专属单元格比如在单元格内嵌入员工选择器、以及Univer在移动端Web上的适配方案。这些方向目前网上成体系的资料不算多但都是真实业务中很常见的能力需求。如果你也在用Univer探索这些场景欢迎一起交流实践经验。
