做在线表格最头疼的事不是把Excel搬到网页上而是怎么让一张表既能让用户填又不能让用户改坏。我见过太多项目在“只读”和“可编辑”之间二选一要么整张表只读需求方说“那我怎么填数据”要么全表可编辑运营同事一个误操作就把生产数据覆盖了。univer这个开源项目是我最近测下来比较能同时解决这两件事的方案。它本质上是一个基于TypeScript的在线表格引擎但它在“工作表保护、单元格锁定、数据验证”这套机制上做得相当完整特别适合做成“管理员定义表格模板、指定单元格让用户填写、其余单元格不可修改”这类业务场景。如果你正在做数据填报、任务派发、审批台账、客户信息采集这类系统大概率会遇到这张“用户能写但写不乱”的表格这篇就从需求拆解、设计思路、实操落地到踩坑经验完整聊聊我个人的做法。1. 需求拆解为什么“填表格”和“改表格”必须分开1.1 一张“限填表”背后到底藏着什么诉求拿我实际做过的客户信息登记来举例。业务方最初提的需求很简单给我一个表格让销售自己填客户资料。听起来很容易但真把一张Excel文件丢到群里问题立刻就来了。有人顺手改了表头把“客户名称”改成了“公司名称”有人误删了“客户编号”列后面所有人的编号对不上了有人把带公式的“登记日期”单元格直接粘贴成了静态文本还有人在“意向等级”里自由发挥填了“A”“很有意向”这类枚举之外的脏数据。于是需求就变成了“这张表的结构必须保留销售员只能改姓名、电话、备注这几个格子其他区域一律不能动。”这就是“用户定义表格 限填单元格”的真实诉求。它不只是权限控制而是把一张表按角色划分成了多个区块表头、说明、公式计算区属于模板所有者数据录入区属于填报者审核修正区又可能属于另一拨人。univer在这条线上做得比较顺手因为它的数据模型里原生就有“工作表保护protection”“单元格锁定locked”“数据验证data validation”这些概念不用像普通前端表格库那样自己拿代码去拦截编辑事件、再手动回滚值。1.2 传统方案的三个痒点先说说为什么不能直接用现成的表单工具或通用在线文档。表单工具在“字段模型”上很强大但做不了“一张二维表格里既有模板又有明细”的灵活度。通用的在线文档协作平台虽然支持多人编辑但权限是整表级的最多做到“可查看”或“可编辑”没法在同一个工作表里精确到某列可写、某列只读、某列必须通过公式算出结果。再退一步自己用div加input去渲染表格数据量到几千行就开始卡更别谈公式联动、撤销重做、数据校验这些Excel级基础能力。所以当我把univer放进候选项时最看重的就是它保留了Excel的语义层单元格有锁定状态工作表有保护开关区间可以挂数据校验公式可以自动重算。这让“限填”这件事不用绕到业务层硬编码而是在表格引擎内部就完成了约束。系统里其他地方只需要关心“数据从哪里来、填完后送到哪里去”。1.3 和同类开源方案放在一起看做在线表格选型目前常见的路线还有SheetJS、Luckysheet、Handsontable、Grist、OnlyOffice这些。SheetJS偏文件解析和导出Luckysheet的计算能力相对弱Grist把表格做成了类数据库后台适合重度管理系统OnlyOffice功能全但集成起来非常重。univer给我的感觉更接近一个“现代前端组件”模块化、TypeScript生态、UI层可替换数据、渲染、协作三个层面分离。对做业务系统的人来说最实在的一点是它定位是“引擎”而不是“应用”你可以把填报模板直接嵌进自己的系统里而不是去适配一套完整的办公套件。方案定位单元格级锁定的支持程度集成难度univer在线表格引擎原生支持保护与锁定中等前端工程化友好SheetJS表格解析/生成不支持交互编辑低但需要自己渲染Luckysheet在线表格有保护但社区维护情况一般中等Handsontable表格组件支持单元格属性控制低数据网格偏轻量Grist数据表应用通过列权限控制较高偏向重后台OnlyOffice完整办公套件服务端文档权限高部署组件多2. 设计思路如何做到“可填写但不可修改”2.1 从Excel继承来的“锁定保护”机制Univer在权限约束上沿袭了Excel的思路每个单元格默认是“锁定”状态但工作表保护默认是关闭的。锁定属性就像一把把锁工作表保护才是决定“锁是否上到柜门上”的总闸。两者要同时生效才能达到“指定区域不可编辑”的效果。所以实现“指定单元格可填”本质上只需要三步。第一步把允许用户编辑的单元格标记为“未锁定locked: false”第二步其余单元格保持默认锁定第三步打开工作表保护。这样用户点进表格时可编辑单元格能正常输入锁定区域则无法进入编辑状态。这个设计与Excel用户的心智模型完全一致业务方理解起来零成本而且一个额外的好处是“保护”结果天然可迁移——如果用univer打开一份Excel文件Excel里设置过的保护状态和锁定状态在拿到Univer里后也能继续复用对存量业务导入很友好。2.2 三种“填写区”设计模式我在实际项目里总结下来受限表格通常跑不出三种模式。第一种是模板表模式。表头、说明行、公式列锁定数据行开放。这是最常见的场景像报价单、问卷登记、采购明细。操作上就是在模板初始化后把整个填写数据区统一设置成未锁定然后打开保护即可。第二种是台账模式。历史数据锁定新增行开放。这个适用于“老数据不能改新数据随便加”的场景比如工时记录、库存台账。难点在于需要动态维护锁定范围每当用户新增行新行默认是可编辑状态而老数据区行要随着状态流转比如“已提交”“已审批”锁定。实现思路不复杂根据业务状态把对应range重新设为locked之后刷新保护即可。第三种是角色分区模式。同一张表里划出A列到C列给销售填D列到F列给财务填每列对应用户或角色组开放。这个在Univer里可以通过给不同range设置不同的锁定属性来实现但要做得严谨通常需要后端在初始化表格时根据当前登录用户返回“哪些单元格可编辑”的配置前端再按配置去设置锁定状态。锁定本身是表格层的“物理约束”角色权限分配是业务层的“逻辑约束”两者配合才能安全落地。2.3 “软约束”同样重要数据验证与条件格式锁定解决的是“用户改不了”但解决不了“用户填错”。这时候要靠数据验证给填写区挂一个下拉枚举、限定数字范围、限制日期格式、控制最大长度。Univer支持数据验证能力我通常会在姓名、电话、状态这类字段上都挂上校验避免脏数据进入后端。有一点必须提醒数据验证只是软约束复制粘贴和外部导入是有可能绕过它的所以关键字段在服务端必须再做一次兜底校验前端表格里的数据验证更多是提升填写体验、降低人工出错率。2.4 为什么Univer用Canvas绘图第一次接触Univer的人都会好奇为什么不直接用DOM表格。答案很简单性能。Univer的表格主体是用Canvas绘制的交互层用DOM来做框选、编辑框、滚动条这些附属物。Canvas在滚动和重绘时性能优势明显实测几十万行数据拖动依然顺滑而纯DOM表格到这个量级基本已经卡得没法用。代价也很直接不能像改普通HTML那样直接DevTools里查DOM改样式调试成本会高一些。如果你只是拿来做简单的在线编辑体感不明显一旦要深度定制主题、做自定义组件就需要切换成“数据模型驱动渲染”的思维。3. 实操落地用Univer搭建一张“可填写但受限”的表格3.1 工程准备与依赖安装下面按一个最精简的Vite TypeScript项目来演示。Node环境建议Node 18以上包管理器用npm即可。需要的核心依赖如下npm install univerjs/core univerjs/sheets univerjs/sheets-ui univerjs/sheets-formula univerjs/ui需要注意Univer迭代速度比较快不同版本的插件注册方式和API名称有差异安装时以官方npm包的最新版本为准。下面代码里的用法是我当前使用的版本的写法核心概念是一致的版本升级时对着官方示例仓库微调即可。3.2 初始化Univer实例并渲染容器初始化Univer实例其实是一个“组装模块”的过程Univer负责调度所有模块Sheet模块负责表格的数据模型和渲染UI模块负责工具栏、右键菜单、Formula Bar这些外围控件。代码如下import { Univer } from univerjs/core; import { createSheetsModule } from univerjs/sheets; import { createSheetsUIModule } from univerjs/sheets-ui; const univer new Univer({ locale: zhCN, container: document.getElementById(app), plugins: [ createSheetsModule(), createSheetsUIModule() ] });如果不需要公式功能也可以不注册formula相关模块按需加载本身就是Univer的设计目标之一。启动后页面里就会出现一个完整的工作表。3.3 创建工作簿与表格模板内容有了实例接下来创建一张工作簿和工作表。我习惯把模板初始化做成一个配置驱动的方法而不是在代码里一行行写死单元格内容这样不同业务只需要换一套配置对象就能生成不同的表。先看手动方式的写法const workbook univer.createBook({ name: 客户信息登记表 }); const sheet workbook.createSheet(登记表, { rowCount: 30, colCount: 8 }); // 第一行写入表头 sheet.getRange(0, 0, 1, 8).setValue([ [编号, 客户名称, 联系人, 联系电话, 所在城市, 意向等级, 登记日期, 备注] ]); // 给表头行设置加粗和背景色 sheet.getRange(0, 0, 1, 8).setStyle({ fontWeight: bold, backgroundColor: #F2F2F2 }); // 给编号列预置一组序列也可以由后端数据写入 sheet.getRange(1, 0, 10, 1).setValue([ [C001], [C002], [C003], [C004], [C005], [C006], [C007], [C008], [C009], [C010] ]);批量写入时要尽量用“范围接口”而不是逐单元格写入后者会频繁触发渲染层的重绘影响初始化速度。这也是Univer使用中一个比较重要的习惯能做批量操作就做批量操作。3.4 锁定模板区、开放填写区这是核心一步模板内容写完后钥匙就在这里了。先把可编辑区域标记为未锁定然后打开工作表保护。完整代码大概是这样的// 第2行到第11行中C到G列联系人、联系电话、所在城市、意向等级、备注开放填写 const editableRange sheet.getRange(1, 2, 10, 5); editableRange.setStyle({ protection: { locked: false } }); // 注册日期列用公式自动生成也应该防止被改动 sheet.getRange(1, 6, 10, 1).setFormula(TODAY()); // 打开工作表保护只有未锁定单元格能被编辑 sheet.protect({ password: });这里有两个细节值得展开。第一单元格的locked属性是默认存在的Excel和Univer里默认值都是true所以“锁定”并不是一个需要手动开启的开关而是需要在开放区手动关掉的默认项。很多初学者的误区是把所有区域手动设置一遍locked其实完全没必要。第二protect调用后锁定状态立刻生效。就算用户通过按键Delete、粘贴、拖拽填充等方式操作它也会被表格引擎拦截。对于更精细的区域保护Univer还有区域级保护能力可以针对某个子区间加权限说明、设置密码适合模板表中“不同区域归属不同负责人”的场景。3.5 给填写区添加数据验证与条件格式锁定之后再加上数据验证。我通常会做两个动作给“意向等级”设置下拉枚举给“联系电话”限制长度和格式。// 意向等级下拉高/中/低不允许为空 sheet.getRange(1, 5, 10, 1).setDataValidation({ type: list, formula1: 高,中,低, allowBlank: false }); // 联系电话文本长度等于11位示例规则按业务调整 sheet.getRange(1, 3, 10, 1).setDataValidation({ type: textLength, operator: equal, formula1: 11, allowBlank: true });条件格式的作用更多是“可视反馈”。比如意向等级为“高”的时候整行高亮这样业务人员一眼就能看到重点客户。Univer也支持条件格式但需要注意它的配置项在版本间变动较大用的时候查一下当版本文档最稳妥。我自己的习惯是条件格式在需要强视觉引导时才用不要堆太多规则否则表格编辑时的重绘压力会变大。3.6 与后端交互取数、回写、导出表格装好后最终还是要回到业务闭环里。填报者在前端填完数据我们需要把数据取出来交给后端保存。Univer的整个表格数据在内存里是一套对象模型从模型里把指定范围的值读取成二维数组并不复杂然后再通过业务接口提交。导出Excel这一步可以用Univer自己的导出能力也可以配合SheetJS做“读Univer数据、写xlsx文件”的组合两种方式我都试过后者对样式细节的还原度会更可控一些。等后端再次下发数据时按模板重新初始化表格再把数据库里的值set进对应区域即可。关键是模板初始化逻辑和业务数据回填逻辑要分开写不然每次打开表格都把用户销毁重建体验会很差。4. 常见问题与排查技巧实录4.1 “单元格还是能改”十有八九是保护没开这是我在社群里被问得最多的问题也是新手最容易踩的坑。许多人设置了锁定区域但忘了调用protect()或者保护代码写在数据初始化之前后续数据变化导致保护状态被覆盖。排查思路很简单先用代码打印一下工作表的保护状态确认保护是开启的再确认目标单元格的locked属性到底是不是false。Univer的实际机制和Excel一致锁定属性只有在保护开启时才生效两者缺一不可。如果都正确但还能改就检查是不是有别的代码在后面重新设置了整行整列的样式覆盖了锁定属性。4.2 开放区域出现“奇怪”的不可编辑状态有时候明明设置了某个区域未锁定打开保护后却发现它还是不能编辑。原因通常是锁定的设置方式和expectation不一致比如你先对整个工作表范围设置了lockedfalse然后把整个工作簿设置为 lockedtrue这种大范围覆盖会把你之前开放的区域重新锁住。还有一种情况是在同一个范围内使用了两种设置接口后执行的覆盖了先执行的。建议在每个range的锁定配置上只走一条路径要么全部用setStyle要么全部用保护配置API不要混用。4.3 填写完后公式不重算Univer支持公式但公式重算的触发条件有时和我们直觉不太一样。尤其是当你通过API直接写入单元格值时有些版本不会主动触发整表重算需要手动调用计算服务刷新。这个问题往往只在“外部数据写入”时出现用户手填触发的重算通常没问题。排查方法是打开公式栏看公式是否还在确认引用范围是否正确。遇到过最多的情况是公式写在锁定区但用户新增行后公式引用范围没有扩展新行里的公式列显示为空。解决思路是在初始化模板时给公式列预留足够的空行范围或者监听新增行事件后重新写入公式。4.4 大数据量表格卡顿的排查思路前面说了Univer用Canvas渲染性能不错但当表格本身数据量很大的时候仍可能出现卡顿。我从实践中总结的排查顺序是这样先看是否启动了不必要的模块比如表格中根本用不到图表和透视表就不要注册对应插件再看是否在滚动或编辑的高频事件里做了复杂逻辑比如scroll监听里发请求、做格式判断这些都会拖慢第三看是否使用了过多的条件格式规则每个条件格式在重绘时都是成本规则超过几十条就要考虑精简。最后还可以在初始化sheet时就把行数列数控制在合理范围不要给一个1000行乘500列的画布只为了展示前20行的数据。4.5 多人协同编辑时的冲突与并发Univer支持协同编辑能力但它的协同能力是需要额外部署协作后端模块的并不是本地轻量应用默认带的功能。如果系统真的需要多人同时填写必须把协同后端纳入架构设计。我在实际使用中感受比较明显的一点是单元格锁定在协同场景下会变成“软竞争”如果两个用户同时编辑同一个未锁定单元格最终以操作序列合并的结果为准而且锁定区域仍然不能被修改。在协同模式下限制单元格权限依然可行但并发冲突的处理和网络延迟对锁状态的同步需要服务端做统一管理。这个部分复杂度会明显上一个台阶建议先拿单机模板验证业务流程再逐步引入协同架构。4.6 一张速查表帮你快速定位问题现象可能原因排查重点锁定区域仍然可以编辑工作表保护未开启检查protect()是否生效可填写区域无法点击设置顺序被覆盖检查是否有其他setStyle覆盖locked填完数据公式不更新写入API未触发重算检查计算服务是否需要手动刷新整个表格加载慢注册了不必要模块或行列过多按需注册插件、控制sheet行列量下拉校验不生效数据验证作用区域偏移核对range行列参数是否写反协同场景下隔三差五冲突缺少协作后端或锁状态同步失败确认协同服务已接入并做并发测试我个人在这几轮选型和实测里最强烈的感受是Univer不是那种“装上就能一键交付”的库它需要你像打磨业务组件一样去管理模板、锁定、校验、公式这些状态。但这也正是它值钱的地方——一旦你把“可填写区域”和“只读区域”的边界通过这套数据模型固化下来整个填报流程就变得非常可控需求方再也不会因为一张表被改得乱七八糟而半夜找你。最后再分享一个小技巧。我在项目里会把“模板定义”抽成一个配置对象里面记录表头、行数、可写区域、校验规则、需要预置的公式。每来一个新业务只需要改配置不需要动代码。这个习惯让你在接后续同类需求时基本可以做到当天开发、当天联调。Univer的上手曲线不算平缓但它的能力边界很宽值得投入时间把这套“模板配置化”的思路沉淀下来。