1. 先说结论Univer 是什么为什么我推荐你关注它Univer 这个开源在线表格项目最近在技术圈的热度上升得挺快。如果你还没接触过简单说它是一套用 TypeScript 写的办公套件核心是 Canvas 渲染的在线电子表格能做到自托管、插件化、多人协同还内置了完整的公式引擎。它的定位在体验上很像 Google Sheets 和飞书表格但数据、服务、渲染全都可以放到自己手里这对很多要处理敏感数据的公司来说是最关键的一点。标题里那个热词场景——“支持用户定义表格然后让用户去填写一些单元格其他的单元格用户无法修改”说得直白一点就是管理端定模板、填报端填格子。这在 OA 系统、审批流、数据收集、考试系统、内部工具的工单录入里太常见了。Univer 正好能覆盖这个场景而且它不要求你放弃自己熟悉的开发栈前端项目里直接以 SDK 的方式接入后端可以自己做权限和存储整体可控性非常高。这篇文章适合三类人看一是正在做内部数据系统、需要在线表格式录入界面的前端开发者二是做技术选型的架构师想弄清楚 Univer 和 Luckysheet、Handsontable 到底差在哪三是产品负责人想评估“模板表格 指定单元格可编辑”这种交互能不能低成本实现。我会把从零到能跑通一个“数据收集表”的过程拆开讲包括权限控制怎么做在线协同怎么配合以及我在真实项目里踩过的几个坑。读完你至少能判断出 Univer 是不是你想要的以及如果要用第一步该干什么。2. 为什么是 Univer选型背后的核心逻辑2.1 先横向对比一下主流方案把 Univer 放在整个开源在线表格的生态里看才能理解它为什么会出现在热词里。我整理了一张对比表按真实选型时的关注点来列方案开源情况渲染方式协同能力二次开发成本典型场景Google Sheets / Excel Online闭源自研非常强基本不可控个人或团队直接使用数据不出网不可接受时就出局Luckysheet开源曾很火维护节奏放缓DOM 渲染一般需自行接后端中等报表展示、轻量编辑Handsontable核心功能非完全开源商用收费DOM有插件方案但整体是组件思路较高专业表格组件嵌入后台Univer开源社区活跃Canvas 渲染有提供协同配套思路中等架构清爽自托管、权限控制、前后端分离的完整场景这张表背后有一个很实际的问题很多团队一开始觉得 Luckysheet 也挺好但做着做着就会发现一旦要做单元格级权限、多人实时协同、自定义命令撤销DOM 渲染和不够清晰的命令层就会成为瓶颈。Univer 从一开始就把渲染和业务拆开设计所有操作都走命令机制这让权限控制和协同冲突处理有了统一的切入点。2.2 命令机制权限控制的关键支点为什么“所有操作都走命令”对你做权限这么重要你可以把它想象成银行柜台所有存取款都必须经过柜员这条流程你不能绕过柜台直接从金库拿钱。Univer 里的每一次赋值、合并单元格、修改样式本质都是一个命令对象先经过命令管线再落到数据模型上。这意味着你要判断“这个用户能不能改这个格子”只需要在命令执行前加一道拦截逻辑而不用监听各种 DOM 事件、不用到处 patch 内置行为。这是很多前端团队最容易忽略但最能影响后续开发效率的点。我见过有团队把 Univer 当成一个普通表格组件在 onCellChange 里做校验结果遇到协同编辑时发现“校验过了但是数据没被采纳”或者“几个用户同时改一个格子状态乱了”。从命令层去做权限而不是从 UI 事件层去做是 Univer 逼着你学会的第一课。2.3 插件化与自托管不只是“换个皮肤”Univer 的插件设计也不是摆设。工具栏按钮、菜单项、单元格渲染器、编辑器的协作行为都可以通过插件注册进去。我这里讲的插件不是“界面上的一个小挂件”而是贯穿渲染、交互、命令三层的能力扩展方式。很多业务需求比如在某个只读单元格旁边悬浮显示审核状态、在填报时对输入做实时校验、给不同角色显示不同的列用插件机制写起来比直接在项目里到处加 if else 干净得多。自托管这一点也值得展开说。Google Sheets 体验确实好但“数据不出企业网络”这条红线在很多公司是绕不过去的。Univer 可以作为前端资源直接托管在自己的服务器上后端协同服务和数据存储都可以自己控制等于你用开源成本换到了私有化部署的自主权。当然天下没有免费的午餐自托管意味着你要自己解决认证、数据库、文件存储、协同服务部署我会在第四节讲到一套最小可跑的方案。3. 核心场景拆解怎么让“用户可填指定单元格其他单元格改不了”3.1 先理解 Excel 的“锁定单元格 保护工作表”很多人第一次听到“用户可填单元格、其他单元格只读”的需求第一反应是“这功能好像有点复杂”。其实这就是 Excel 里很老的机制先把整张工作表的所有单元格默认设为“锁定”然后只把你想要用户填写的 B2、C3 这些格子取消锁定最后打开“保护工作表”开关。锁定属性 保护开关两个条件叠加才决定了某个单元格最终是否可编辑。只看锁定属性没用因为默认所有单元格都是锁定状态只用保护开关也没用因为保护只针对“锁定单元格”生效。这个逻辑放到在线表格的语境里依然适用只是实现方式从“Excel 菜单”变成了“接口调用”。你在方案设计阶段最好就直接沿用这个概念不要自己发明一套“只读字段”之类的黑话否则后续和技术、产品沟通都会多一层转译成本。3.2 Univer 中的三级权限控制在实际项目里我通常把权限分成三个层级。第一是工作簿级整个表格文件是否能被打开、能否新增工作表这通常对接后端文件权限。第二是工作表级某个 Sheet 是否可编辑适用于“汇总页只读录入页可编辑”这种结构。第三是区域级在同一个 Sheet 内哪些 range 可以被编辑哪些 range 被锁定。标题里那个热词场景就是典型的区域级控制。这三个层级不是三选一而是叠加使用。最简单的做法是工作簿级靠后端鉴权拦截请求工作表级和区域级在前端命令管线里做拦截和配置。Univer 官方 SDK 里关于工作簿保护和工作表保护的接口在各个版本有调整但核心逻辑一致先给某个 range 设置保护规则再决定哪些操作者能绕过保护。由于版本差异比较明显我建议你在接入时以官方文档的 workbook protection / range protection 相关章节为准下面给的是概念性示意代码核心思路是通用的。// 概念性示意具体 API 以你使用的 Univer 版本为准 // 1. 获取当前激活的工作簿和工作表 const workbook univerAPI.getActiveWorkbook(); const sheet workbook.getActiveSheet(); // 2. 把整个工作表设置为保护状态 // 默认所有单元格都不可编辑 sheet.getProtection().set(true, { allowSelectLockedCells: true, allowSelectUnlockedCells: true, allowEditObjects: false }); // 3. 把需要用户填写的区域解锁 // 比如只允许填写 A2:B10 sheet.unlockRange(A2:B10);这段代码的意思很清楚先开保护再解禁可写区。值得注意的一条经验是不要先解锁后开保护因为开保护时如果你指定了全表保护某些版本会在保护生效的瞬间把未锁定单元格的锁定状态一并重置导致你前面辛苦解锁的区域依然被锁死。这是一个看起来不太可能、实际很容易踩的坑。3.3 只靠保护还不够配合数据验证和输入拦截如果你只是做“模板表 指定区域可填”保护机制已经够用。但真实业务里往往还要求“可填区域里也只能输入特定格式”比如只能输入数字、只能选下拉值、不能填负数。这时候要用数据验证能力。Univer 提供了数据验证机制可以对指定范围设置规则。但记住数据验证和数据保护是两个独立能力自定义数据验证规则的回调函数里也可以做“这个单元格是否允许被编辑”的二次判断这样就算保护环节被绕过数据入口仍然有校验。另外编辑事件拦截也是一种兜底。即便你通过保护机制挡掉了正常 UI 的编辑操作仍然建议在命令管线里再做一道“写操作白名单”校验。因为协同场景下有些操作可能来自远端用户有些操作可能来自程序化调用保护规则不一定会拦截所有入口。把命令层校验当成最后一道保险能避免很多诡异 bug。4. 一个完整实操从零搭建“数据收集表”4.1 明确需求和最终效果先假设一个具体场景人力资源部的“月度绩效自评收集表”。HR 管理员定义模板模板里包含员工姓名、部门、自评得分、自评说明这几列。员工打开链接后只能填写自己那一行的“自评得分”和“自评说明”姓名和部门由系统自动带入且不可改其他区域完全锁定。这个例子特别能反映热词里的需求因为“用户定义表格 部分单元格可填写 其他单元格不允许修改”就是这里的核心。我把它拆成四步走初始化项目、嵌入 Univer、设置模板和保护、联调在线协同。4.2 第一步初始化项目并嵌入 Univer如果你已经有前端项目直接按照官方文档把 Univer 的包安装上就行。我用 npm 做示例npm install univerjs/preset-sheets npm install univerjs/core初始化一个 sheet 容器也不复杂核心代码大致是这样的import { Univer } from univerjs/core; import { UniverSheetsPlugin } from univerjs/sheets; import { UniverPresetSheet } from univerjs/preset-sheets; const univer new Univer({ // 这个配置项按官方 preset 示例来 // 具体参数看版本文档重点是 UI、Sheet、公式等插件都要注册进来 ...UniverPresetSheet });我不会在这里贴整个配置文件因为版本不同差异很大但有一个核心思路要强调Univer 的接入不是一个组件套到底而是通过插件注册机制把 core、sheets、ui、公式引擎、协同等能力分别加载。你越早点理解这一点后面排查问题时思路越清晰。4.3 第二步生成模板并设置保护区域模板数据我用一个简单的 JSON 来表达const template [ [员工姓名, 部门, 自评得分, 自评说明], [张三, 产品部, , ], [李四, 研发部, , ], [王五, 运营部, , ] ];把模板写入工作表后关键一步是设置保护。我在这里用概念性代码表达const sheet workbook.getActiveSheet(); // 保护整张工作表 sheet.getProtection().set(true); // 只解锁 C2:D4也就是“自评得分”和“自评说明”这两列的数据行 sheet.unlockRange(C2:D4);这里有一点值得注意实际权限控制里员工姓名和部门的取值不一定来自表格里的静态文本更合理的做法是由后端接口按登录人身份传值前端负责渲染并且把这些列也设置为不可写。这样即使有人打开浏览器的开发者工具也无法轻易模拟出修改这些列的写命令因为命令层已经拦掉了。4.4 第三步对接在线协同的最小化方案“univer 在线”这个热词背后包含的能力比表面看起来多多人打开同一个表格、实时看到对方改动、网络抖动时还能继续编辑、冲突后能合并结果。Univer 官方提供了协同能力和配套实现思路但自托管时你需要自己部署协同服务、准备数据库、做数据存储。我的建议是第一次跑通时先不要追求“生产级协同”。你可以在本地起一个 Univer 前端再起一个简单的协同后端服务先用两个浏览器窗口验证“一个人改了 C2另一个人是否马上看到”。验证的重点不是花哨的光标颜色而是数据一致性两个人同时改同一个单元格时最终结果是确定的不会出现一个覆盖另一个但 UI 上毫无感知的情况。协同这一块能把多少功能跑通取决于你用的 Univer 版本和官方配套服务不同版本的 API 差异很大。我的实操体会是先只接“文档绑定 状态同步”的最小闭环把权限命令层和协同命令层在代码上先分开等真的做产品级方案时再加冲突策略、版本回滚、操作日志这些重量级能力。5. 在线协同与权限控制如何配合5.1 协同的底层逻辑不是“推送一个最终结果”很多团队负责人觉得“在线协同”就是把一个人的操作广播给所有人。真不是这样。如果只是广播最终结果那么用户 A 修改 C2 时用户 B 正好也在改 C2两个人会互相覆盖。规范的做法是把每个编辑动作拆成带时序的操作单元通过协同协议让所有客户端按照相同顺序执行这组操作保证最终状态一致。这也是我强调命令机制重要的原因Univer 的操作天然是命令对象协同同步的也是命令而不是“改完后的整张表”。这个区别直接影响到权限控制。如果你在协同里同步的是“最终结果”那么权限校验只能发生在生成结果的瞬间一旦结果进入同步通道就不再可控。如果你同步的是命令那每一个命令在进入通道前后都能被校验这就给了你做安全边界的机会。所以在方案设计阶段权限和协同就不是两件事而是同一条命令链路的前后两段。5.2 权限校验不能只在“发命令”时做在协同场景下权限控制通常要过两关。第一关客户端命令发起时用户在 UI 上按下编辑键Univer 会尝试执行命令你的保护规则在这里拦截非法编辑给用户即时反馈提示“这个格子受保护”。第二关协同服务器接收到远端命令时服务器侧必须再校验一次该用户是否有权执行这条命令。因为客户端永远可以被篡改前端保护只是体验层面真正的安全边界在服务端。我在实际项目中踩过一个坑只在前端做了保护忽略了协同服务侧的命令鉴权。结果用户用脚本直接调客户端接口发命令绕过了 UI保护形同虚设。后来我们把“写操作命令校验”做成协同服务里的一个中间件每个命令在落库前都要校验操作者身份和操作范围这才把安全边界补上。5.3 受保护区域的交互反馈还有一个很细节、很影响体验的问题受保护单元格在鼠标点击时应该给什么反馈直接禁用单元格会让用户觉得表格坏了只读但可以选中又会让用户困惑为什么不能输入。我的建议是受保护区域保留“可选中、可复制、可查看”的交互但在用户尝试输入时给出明确提示比如状态栏显示“该单元格受保护不可编辑”或者通过 toast 提示。这样既不影响查看也不会让用户以为浏览器卡了。另外对于可填区也应该有视觉引导。可以在模板加载完成时给可编辑区域加一个浅色底纹或者加一个输入框样式的边框。很多表单式录入场景之所以体验好是因为用户一眼就能看出来哪些地方能填。这在在线表格里是很容易实现的一个小优化却经常被忽略。6. 常见问题与排查技巧实录6.1 为什么我设置了保护单元格还是能被编辑这个问题的原因通常是保护规则虽然设置了但命令管线里还有一条编辑命令没有被标记为受保护范围拦截。检查思路就一条在发起编辑命令之前先打印命令链路上保护判断的结果。常见错误有三种一是把保护设置放在 sheet 渲染完成之前导致保护配置没挂到正确实例上二是解锁区域使用了错误的 range 地址比如把 A2:B10 写成了 A2:B9三是协同模式下远端命令走了白名单没走保护校验。我给你的排查工具建议是别只靠鼠标去点单元格测试直接在代码里调用命令执行接口逐步跟踪每一步的保护判断结果。这样你能在最短时间内确认是“保护没生效”还是“编辑命令没被拦截”减少盲猜时间。6.2 协同多人打开后保护配置会互相覆盖吗会有这种情况。假设 A、B 两个用户同时打开同一个模板A 在负责改保护配置B 正在表单里填写如果 A 的保存操作把整张表的保护配置整体覆盖了B 的修改就会撞上新的保护规则。我的建议是保护配置只由后台服务端统一生成前端只负责读取和渲染别让前端用户直接用工具栏去改保护设置。如果你确实需要管理员在线调整保护范围至少要把“编辑保护配置”的权限做成一个单独角色并且使用事务化保存避免并发写覆盖。6.3 大表格操作卡顿怎么办Univer 的 Canvas 渲染在多数场景下性能不错但如果你把一张数据量很大的表全部挂进数据验证、条件格式、保护区域里初始化时间会明显变长。我踩过的坑是为了省事给整个数据列都加了数据验证规则结果用户输入一个字符都要解析一堆规则。排查后改成只对实际有数据的行设置规则并且保护区域按真实业务范围收紧卡顿立刻缓解。性能优化的经验就一句话规则的范围要克制永远不要用“整列”去表达“本列大部分行”。6.4 数据校验提示不出现怎么办数据验证触发失败最常见的原因是触发时机设置成了“提交时”而用户只是在填写过程中测试其次是数据类型选择与单元格已有数据格式冲突。实际排查时先把单元格格式统一再检查校验规则的触发模式基本都能定位。为了让你以后排查更快我把这些常见问题整理成一个速查表现象常见原因处理建议保护区域仍可编辑保护配置未挂载 / 命令绕过在命令管线打印拦截结果检查 range 地址协同时权限互相覆盖前端并发写保护配置保护配置由服务端统一下发大表格卡顿规则范围过大收紧数据验证和保护范围校验提示不出现触发时机或格式冲突统一单元格格式检查触发模式这个表里的每一条我都亲手在处理客户问题或者内部项目时碰到过。尤其是“保护区域仍可编辑”那一类最容易让人怀疑是不是框架 bug实际上十次里有八次是自己配置时序不对。7. 最后的个人体会我在实际把 Univer 集成进一个内部填报系统之后最大的感受就是这个项目给了你很多高级能力但它不是一个点开即用的 SaaS 工具你需要为它设计好权限模型、协同边界和错误处理。第一周你可能都在解决环境问题和 API 版本差异但一旦把命令层、保护层、协同层的逻辑理顺后续加功能会非常快。最后再分享一个小技巧调试保护规则时不要每次都用鼠标去点单元格测试直接在命令行工具里调用命令执行接口逐步跟踪每一步的保护判断结果。这样你能在最短时间内确认是“保护没生效”还是“编辑命令没被拦截”省下来的时间足够你多写两个自定义插件了。如果你正准备在内部系统里引入“用户填指定格子、其他格子只读”的在线表格能力我建议你完全可以用 Univer 先跑一个最小原型时间不会白花。