最近接了一个需求刚开始觉得不太“前端”网页里放一个在线表格用户只能往指定的几个单元格里填内容其他区域比如表头、合计行、审批列一律不允许改动。这种场景很常见比如激励申报、预算填报、台账录入、任务拆解用户要的其实是一张“像Excel的表”而不是一堆堆出来的input输入框。我最终选用了Univer这个开源在线表格内核配合自定义的编辑保护逻辑实现了“白名单单元格可编辑其他区域用户无法修改”的效果。这篇文章把完整思路、实现方案和踩过的坑都整理出来给正在做同类在线填报场景的团队一个参考。1. 为什么要把“在线表格”当表单用而不是堆一堆输入框1.1 用户要的不是“输入控件”而是“一张更像Excel的表”很多人会问既然只是填几个格子用HTML表单加几个输入框不就行了数据提交更简单后端也好处理。这个说法在非常轻量的问卷场景下没问题但一旦表格的规模、结构和业务含义上来差别就非常明显。我做的是一个内部激励申报单表格大概有十几列、四十多行包括申报人信息、成果描述、目标值、实际完成值、权重、得分、审批意见等。每个填报人只需要填写自己负责的若干行其他区域比如总分、排名、审批结论是别人的职责甚至只能由系统计算。这种情况下如果用HTML控件光是布局对齐、行列冻结、批量复制粘贴、单元格校验这些交互就要写大量代码而且用户拿到界面后的第一反应往往是“这不是Excel我不会用。”Univer这类真正的表格内核好处在于它天然支持行列操作、公式联动、单元格合并、条件格式、复制粘贴、拖拽填充这些能力不是我们为了某一个表单现做的而是整个表格引擎自带的。我们只需要在“允许用户编辑哪些区域”这一点上做文章就能得到一个体验上接近Excel、行为上完全受控的填报表单。1.2 Univer适合哪些场景哪些场景别硬上Univer是一个开源的全栈办公套件核心是UniverSheet底层基于TypeScript和Canvas渲染性能和交互都非常接近原生桌面表格。我选择它主要是看中三点一是开源可控遇到问题可以直接读源码二是支持在浏览器里嵌入并且可以按需扩展三是它本身提供了一套相对完整的文档数据模型和命令机制做编辑权限控制有抓手。不过我必须先把边界说清楚Univer并非万能场景类型推荐程度原因中后台系统里的数据填报、审批、台账推荐表格交互完整单元格级控制可行面向外部的复杂问卷或报名表较推荐表格样式有助于排版但要控制编辑范围超轻量的三两个字段地址表单不推荐杀鸡用牛刀HTML表单更轻需要多人高并发实时协同Excel谨慎协同编辑需要自己搭建协作服务成本明显上升纯展示型报表页部分推荐可以用Univer做渲染但也要关闭编辑能力如果你手头的需求只是“收集几个字段”用HTML反而更合适。但如果你发现需求里出现“行列结构固定、部分单元格有公式、部分区域只有特定角色能改、用户要复制粘贴多行数据”这些特征就不要用表单硬撑了直接上表格内核。1.3 我最终想要达到的效果定义在写代码之前需求必须被翻译成精确的表格行为。我对自己定的目标是加载一个预设模板表头、公式、样式都预先设置好用户打开页面只能编辑白名单区域内的一组单元格白名单区域之外的单元格鼠标点击选中可以但不能进入编辑状态如果用户尝试输入内容直接拦截并提示“该单元格为只读区域”白名单区域内的内容支持常规编辑、撤销、公式联动并且所有默认按键行为保持正常。这个目标拆开看实际只有两件事第一把Univer跑起来第二在Univer的编辑链路里做权限判断。难的不是“跑起来”难的是搞懂编辑链路里到底哪里拦最合适。2. 控制单元格编辑权限前先搞懂Univer的命令执行链路2.1 一切编辑动作都会经过命令层Univer的设计和很多现代编辑器一样不是那种“用户改了一个value就直接改页面状态”的老式写法。它内部把所有变更都定义成Command或Mutation统一经过一个命令分发中心。比如用户往单元格里输入“100”这个动作最终会变成一个类似“调整单元格值”的命令携带坐标、旧值、新值等参数派发到内部状态管理器状态变更后再触发视图重新渲染。这个设计对做权限控制来说就是天赐良机。所有编辑入口无论来自键盘输入、粘贴、拖拽填充、公式引擎自动重算最终都要落到命令层。只要在命令层增加一个“这个Range允许改吗”的校验就能拦截掉绝大多数越权操作。理论上还有更底层的做法比如直接改Univer的数据模型但那就太暴力了容易破坏内部一致性。我更推荐在命令链路和内部状态之间做“看门人”既不影响表格内核的正常工作又能把业务规则集中在一个地方。2.2 命令拦截的粒度从Workbook、Worksheet到RangeUniver的权限粒度是分层的Workbook级别整个工作簿只读或可编辑Worksheet级别单个工作表只读或可编辑Range级别某个工作表内的一定行列范围可编辑或只读。我们要做的“用户只能填白名单单元格”本质上属于第三种也就是Range级别的控制。但要注意Univer本身不是直接把“Range可编辑属性”暴露成JSON字段的它更多是靠“保护(Protection)”机制和命令拦截组合来实现。我的做法是把可编辑区域视为白名单集合在命令层校验时判断“目标Range是否落在白名单集合内”。2.3 官方能力与自定义拦截的关系Univer的工程里已经有部分编辑保护相关的能力尤其是一些Sheet级设置但不同版本差异很大。我在做的时候发现依赖全部官方保护能力不太现实因为需求里“某些区域可编辑、其余区域不可编辑”这种白名单模式用官方基础配置能拦一部分但用户交互体验还不够好——比如选中只读区域时仍然能弹出编辑光标只是改完才发现被拒绝。所以我走的是双保险路线使用Univer的保护相关能力从内核层面拒绝非白名单区域的变更在命令执行层额外做业务拦截非法操作发生时直接阻断并且给出明确的提示文案甚至可以触发气泡提醒。前一步确保数据不会被改坏后者确保用户感知清晰。3. 实操落地从Univer初始化到“只允许编辑指定单元格”3.1 快速跑起一个Univer编辑页先别急着写权限逻辑先把Univer本体集成起来。以我当时的工程为例前端项目用的是Vite TypeScript接入思路大致是这样的npm install univerjs/core univerjs/sheets univerjs/sheets-ui univerjs/ui初始化过程在官方仓库里有比较清晰的示例核心思路是创建一个Univer实例加载Sheet插件和UI插件再把Workbook配置传入。需要注意Univer版本更新非常快接口名可能变化我的建议是选定一个版本后固定依赖比如使用锁版本的写法避免构建时莫名其妙升级。一个最小化的启动逻辑可以这样理解import { Univer } from univerjs/core; import { UniverSheetsPlugin } from univerjs/sheets; import { UniverSheetsUIPlugin } from univerjs/sheets-ui; import { UniverUIPlugin } from univerjs/ui; const univer new Univer({ // 这里传入Univer核心配置比如当前环境、语言等 }); univer.registerPlugin(UniverSheetsPlugin); univer.registerPlugin(UniverUIPlugin, { container: app, }); univer.registerPlugin(UniverSheetsUIPlugin);后续要加载一个预设的Workbook数据通常会传入一份JSON格式的工作簿配置里面包含Sheet名称、行列分布、单元格初始值、样式、合并单元格等信息。因为Univer的数据模型是DocumentData模型你可以把模板标准化成这个结构。我这里不展开全部配置字段但你只要记住先在本地用官方Demo或者一个最小JSON跑通页面再往上叠加需求。千万不要上来就直接改内部数据模型否则排查问题会非常痛苦。3.2 定义单元格白名单的数据结构权限第一步把“可编辑区域”定义成一份干净的配置。我当时定义了一个独立的配置模块editable-config.ts方便运营人员在界面修改也方便后端按角色下发不同配置。export interface EditableRange { sheetId: string; startRow: number; startColumn: number; endRow: number; endColumn: number; } export const DEFAULT_EDITABLE_RANGES: EditableRange[] [ { sheetId: sheet-01, startRow: 2, startColumn: 1, endRow: 8, endColumn: 3, }, ];这个数据结构的含义是在sheet-01里第2行到第8行、第1列到第3列围成的矩形区域是用户可填写的。作为简化版我用了“矩形白名单”的概念。矩形虽然灵活度有限但它最容易理解和维护也最容易在后端做校验。如果你的业务里白名单比较碎比如只允许填A2、B2、C5这种分散单元格可以把多个矩形叠加本质还是一样的。实际运行时判断逻辑可以简化为用户要改的目标Range是否完全落在某个白名单矩形内。如果是放行否则拦截。3.3 两步实现“锁定其他单元格”第一步利用Univer的保护能力把非白名单区域标记为受保护。不同版本的Univer对保护能力的支持力度不同有的版本可以通过工作表配置里的protect字段设置或者在UI层操作。如果当前版本的保护能力不完全覆盖Range级就需要走第二步的Command拦截。第二步在Univer的命令分发层注册拦截逻辑。Univer的命令系统有一个比较理想的扩展点注册ResolveCommand或BeforeExecute类型的钩子。在每次命令真正执行前我们可以拿到命令名比如“设置单元格值”然后取出要操作的Range信息和目标Range做比对。伪代码大致如下const COMMANDS_TO_INTERCEPT [ sheet.command.set-range-values, sheet.command.paste, ]; registerCommandInterceptor((commandPayload) { if (!COMMANDS_TO_INTERCEPT.includes(commandPayload.type)) { return { shouldExecute: true }; } const targetRange extractTargetRange(commandPayload); const isAllowed editableRanges.some((range) isRangeInsideEditableRegion(targetRange, range) ); if (!isAllowed) { showToast(该单元格为只读区域不能修改); return { shouldExecute: false }; } return { shouldExecute: true }; });这个思路不依赖某个具体版本的精确API名称核心是理解Univer命令模式的工作原理。实际接入时你要根据你锁定的Univer版本来查看命令名和参数结构。这里有个关键点不仅要拦截“手工输入”还要拦截“粘贴、拖拽填充、导入”等行为。粘贴命令尤其重要因为用户经常从外部Excel复制一排数据往里贴如果只拦截普通输入粘贴会直接突破防线。3.4 组合后的行为表现这套组合做完之后用户的真实体验是点击白名单区域内的单元格光标正常出现可以输入、回车、Tab切格点击非白名单区域单元格可以被选中但不会进入编辑状态在只读区域尝试输入时命令被拦截页面出现提示单元格值不变复制白名单区域的内容、粘贴到只读区域时同样被拦截不会造成数据污染。这个表现已经非常接近Excel里的“保护工作表但允许选定锁定单元格”的效果同时比纯前端校验可靠得多。3.5 最小Demo的目录结构如果从零开始搭建我建议目录结构按下面这样组织src/ main.ts // 项目入口初始化Univer config/ editable-config.ts // 可编辑白名单配置 workbook-template.ts // 预设的Workbook JSON模板 services/ edit-guard.ts // 命令拦截逻辑可编辑区域校验 views/ App.ts // Univer容器和生命周期管理这样分成三层的好处是模板数据和权限配置可独立修改和Univer的接入层解耦EditGuard专注于校验逻辑方便单元测试App只负责挂载和销毁。4. 三种实现方案的实测对比与选型在真正落地过程中我试过三种方案各有优缺点。这里把实测情况完整说清楚帮你少走弯路。4.1 方案A纯官方保护能力如果Univer未来的版本提供了完善的Worksheet级或Range级保护机制那么最理想的方案是直接用官方保护API把指定区域标记为锁定即可。优点是不需要自定义命令拦截逻辑跟随表格内核一起走不容易出现数据不一致的问题。缺点是目前版本的覆盖能力有限某些场景比如“公式可以重算但不能手工改”这种细分需求纯保护方案不一定能完全支持。而且官方能力通常偏通用对业务提示文案这种交互需求无能为力。4.2 方案B命令层拦截快照回滚这是我最终用的核心方案。核心思想是不试图彻底阻止渲染层进入编辑状态而是在命令执行前拦截。拦截失败时还可以做一个兜底在执行完非法命令后立即用快照把对应Range恢复原值。这样做的好处是无论有多少种编辑入口包括未来新增的功能比如批注、数据验证、浮动图片都能在命令层统一兜底。缺点是要维护一份“合法区域”的判断逻辑并且要处理撤销栈。4.3 方案C每次操作后全量校验修复还有人在社区里提出过不如在每次表格变更之后遍历所有非白名单单元格如果发现值变了就改回去。这个方案实现很简单但性能和健壮性都差。因为表格数据量一上来全量校验的耗时直线上升而且它只是在“已发生的错误”上打补丁用户会看到数据闪变体验很差。我自己的测试里在几百行数据的表上做全量校验每操作一次都有明显卡顿。这个方案我只在紧急兜底时用不建议作为主方案。4.4 我的推荐组合结合以上三种方案的实测我的推荐是按优先级组合优先级能力作用第一层Univer官方保护配置内核层面阻止非法写入第二层命令层拦截提供用户提示阻断异常交互第三层快照恢复兜底处理绕过拦截的意外变更这个组合的关键是不要把命令层拦截当成唯一防线。因为Univer的命令名在不同版本可能调整有些第三方扩展或未来新增的编辑功能可能不经过你拦截的这几个命令。保住第三层快照恢复等于给数据一致性上了最后一道保险。5. 真实验证中的坑版本差异、协同并发、撤销重做与移动端5.1 Univer版本更新快API别写死我接入的时候Univer还在快速迭代官网示例和GitHub README里的代码可能与具体发布版本有出入。最直观的问题就是你查到的某个API在旧版本不存在新版本又改了名字。我的经验是固定依赖版本号不要用latest或者next项目里锁定一份Univer源码快照需要查阅实现时直接翻node_modules里的源码升级版本时把所有权限相关代码作为重点回归项测试特别是命令名是否变化。Univer底层设计确实有优秀的地方比如数据模型沉淀后没有频繁改动但UI层的命令注册机制相对活跃一旦升级命令拦截相关代码很可能要跟着调整。5.2 协同编辑下保护策略不能只写在前端如果你的项目不止一个人同时编辑同一张表那要格外注意Univer本身只是客户端编辑器多人协同需要你自建或接入协作服务。这个时候仅仅在前端做白名单拦截是不够的因为别人可能通过不同的客户端连接直接发出一个修改命令不经过你的前端拦截。正确做法是把可编辑白名单规则同步到协作服务端让服务端在执行命令时也做同样的权限检查。前端拦截更多是为了用户体验后端校验才是数据安全底线。如果你们暂时没有协同需求单机模式下前端拦截已经能用但一旦接协同权限规则必须能下沉到服务端。5.3 撤销重做会绕过你的“回填原值”吗这是我在测试时踩得比较深的坑。我的逻辑里有一个兜底快照当检测到非法命令执行后试图恢复Range的原值。不过一旦用户按了CtrlZ撤销栈会认为刚才的“恢复原值”也是一次变更可能产生奇怪的状态用户撤销时反而把只读区域里的旧值覆盖了或者撤销提示提示错误。解决办法是对由程序发起的“恢复回滚”操作进行特殊标记并且把这类操作排除在用户撤销链路之外。更稳妥的做法是尽量不要走“先执行非法命令再恢复”的路线而是尽量在命令执行前就拦截掉。如果确实存在那种绕过拦截的写入恢复原值时建议同时清除对应的撤销记录或者直接对目标Range加一层顶层保护禁止用户交互撤销。5.4 移动端适配和输入法问题线上填报场景里不少用户会拿手机或平板操作。Univer本身对移动端有基本支持但权限控制这块有几个细节容易翻车只读区域的点击判断在触屏上有延迟用户容易误触移动端键盘弹出后计算列的滚动位置可能被顶上去部分中文输入法在合成拼音过程中会触发多个中间态命令如果不针对输入法命令做处理会出现“输入一个字被拦截N次”的提示轰炸。我的建议是在移动端弱化“精确点击编辑”的交互把白名单区域用背景色明显标识出来甚至提供“点击区域自动聚焦下一格”的快捷操作。这需要你在编辑器和业务组件之间做一点桥接但实际效果很值得。5.5 公式单元格的特殊处理最后说一个最容易忽略的点表格里通常有公式列比如合计、比例、排名。用户大部分情况下不需要手填公式区域但公式结果会被其他单元格的修改触发重算。如果你的白名单判断过于激进把含有公式的单元格判定为只读可能导致公式无法更新结果整个表就失去联动性了。我的做法是允许公式内部重算写入值但不允许用户直接手工编辑公式区域。也就是说权限判断时要区分“命令来源”。如果一条命令是由公式引擎计算触发的放行如果命令来源于用户交互则按白名单规则拦截。这一点需要在命令拦截逻辑里拿到命令的来源标记不同版本实现方式不同但核心思路是一样的——权限判断不能只看最终写入的Range还要看触发的动作类型。如果你现在也要做类似的填报表格我的建议是先把需求拆成两层来看把Univer当作单元格编辑器和展示层把“可编辑白名单”当作业务权限模型。两者之间用命令拦截衔接先跑通最小闭环再加入模板下发、后端校验、移动端适配。不要一开始就追求和Excel完全一致的权限体验先把“该填的能填、不该填的改不了”这个基本盘守住后面再慢慢细化交互细节。
最近接了一个需求刚开始觉得不太“前端”网页里放一个在线表格用户只能往指定的几个单元格里填内容其他区域比如表头、合计行、审批列一律不允许改动。这种场景很常见比如激励申报、预算填报、台账录入、任务拆解用户要的其实是一张“像Excel的表”而不是一堆堆出来的input输入框。我最终选用了Univer这个开源在线表格内核配合自定义的编辑保护逻辑实现了“白名单单元格可编辑其他区域用户无法修改”的效果。这篇文章把完整思路、实现方案和踩过的坑都整理出来给正在做同类在线填报场景的团队一个参考。1. 为什么要把“在线表格”当表单用而不是堆一堆输入框1.1 用户要的不是“输入控件”而是“一张更像Excel的表”很多人会问既然只是填几个格子用HTML表单加几个输入框不就行了数据提交更简单后端也好处理。这个说法在非常轻量的问卷场景下没问题但一旦表格的规模、结构和业务含义上来差别就非常明显。我做的是一个内部激励申报单表格大概有十几列、四十多行包括申报人信息、成果描述、目标值、实际完成值、权重、得分、审批意见等。每个填报人只需要填写自己负责的若干行其他区域比如总分、排名、审批结论是别人的职责甚至只能由系统计算。这种情况下如果用HTML控件光是布局对齐、行列冻结、批量复制粘贴、单元格校验这些交互就要写大量代码而且用户拿到界面后的第一反应往往是“这不是Excel我不会用。”Univer这类真正的表格内核好处在于它天然支持行列操作、公式联动、单元格合并、条件格式、复制粘贴、拖拽填充这些能力不是我们为了某一个表单现做的而是整个表格引擎自带的。我们只需要在“允许用户编辑哪些区域”这一点上做文章就能得到一个体验上接近Excel、行为上完全受控的填报表单。1.2 Univer适合哪些场景哪些场景别硬上Univer是一个开源的全栈办公套件核心是UniverSheet底层基于TypeScript和Canvas渲染性能和交互都非常接近原生桌面表格。我选择它主要是看中三点一是开源可控遇到问题可以直接读源码二是支持在浏览器里嵌入并且可以按需扩展三是它本身提供了一套相对完整的文档数据模型和命令机制做编辑权限控制有抓手。不过我必须先把边界说清楚Univer并非万能场景类型推荐程度原因中后台系统里的数据填报、审批、台账推荐表格交互完整单元格级控制可行面向外部的复杂问卷或报名表较推荐表格样式有助于排版但要控制编辑范围超轻量的三两个字段地址表单不推荐杀鸡用牛刀HTML表单更轻需要多人高并发实时协同Excel谨慎协同编辑需要自己搭建协作服务成本明显上升纯展示型报表页部分推荐可以用Univer做渲染但也要关闭编辑能力如果你手头的需求只是“收集几个字段”用HTML反而更合适。但如果你发现需求里出现“行列结构固定、部分单元格有公式、部分区域只有特定角色能改、用户要复制粘贴多行数据”这些特征就不要用表单硬撑了直接上表格内核。1.3 我最终想要达到的效果定义在写代码之前需求必须被翻译成精确的表格行为。我对自己定的目标是加载一个预设模板表头、公式、样式都预先设置好用户打开页面只能编辑白名单区域内的一组单元格白名单区域之外的单元格鼠标点击选中可以但不能进入编辑状态如果用户尝试输入内容直接拦截并提示“该单元格为只读区域”白名单区域内的内容支持常规编辑、撤销、公式联动并且所有默认按键行为保持正常。这个目标拆开看实际只有两件事第一把Univer跑起来第二在Univer的编辑链路里做权限判断。难的不是“跑起来”难的是搞懂编辑链路里到底哪里拦最合适。2. 控制单元格编辑权限前先搞懂Univer的命令执行链路2.1 一切编辑动作都会经过命令层Univer的设计和很多现代编辑器一样不是那种“用户改了一个value就直接改页面状态”的老式写法。它内部把所有变更都定义成Command或Mutation统一经过一个命令分发中心。比如用户往单元格里输入“100”这个动作最终会变成一个类似“调整单元格值”的命令携带坐标、旧值、新值等参数派发到内部状态管理器状态变更后再触发视图重新渲染。这个设计对做权限控制来说就是天赐良机。所有编辑入口无论来自键盘输入、粘贴、拖拽填充、公式引擎自动重算最终都要落到命令层。只要在命令层增加一个“这个Range允许改吗”的校验就能拦截掉绝大多数越权操作。理论上还有更底层的做法比如直接改Univer的数据模型但那就太暴力了容易破坏内部一致性。我更推荐在命令链路和内部状态之间做“看门人”既不影响表格内核的正常工作又能把业务规则集中在一个地方。2.2 命令拦截的粒度从Workbook、Worksheet到RangeUniver的权限粒度是分层的Workbook级别整个工作簿只读或可编辑Worksheet级别单个工作表只读或可编辑Range级别某个工作表内的一定行列范围可编辑或只读。我们要做的“用户只能填白名单单元格”本质上属于第三种也就是Range级别的控制。但要注意Univer本身不是直接把“Range可编辑属性”暴露成JSON字段的它更多是靠“保护(Protection)”机制和命令拦截组合来实现。我的做法是把可编辑区域视为白名单集合在命令层校验时判断“目标Range是否落在白名单集合内”。2.3 官方能力与自定义拦截的关系Univer的工程里已经有部分编辑保护相关的能力尤其是一些Sheet级设置但不同版本差异很大。我在做的时候发现依赖全部官方保护能力不太现实因为需求里“某些区域可编辑、其余区域不可编辑”这种白名单模式用官方基础配置能拦一部分但用户交互体验还不够好——比如选中只读区域时仍然能弹出编辑光标只是改完才发现被拒绝。所以我走的是双保险路线使用Univer的保护相关能力从内核层面拒绝非白名单区域的变更在命令执行层额外做业务拦截非法操作发生时直接阻断并且给出明确的提示文案甚至可以触发气泡提醒。前一步确保数据不会被改坏后者确保用户感知清晰。3. 实操落地从Univer初始化到“只允许编辑指定单元格”3.1 快速跑起一个Univer编辑页先别急着写权限逻辑先把Univer本体集成起来。以我当时的工程为例前端项目用的是Vite TypeScript接入思路大致是这样的npm install univerjs/core univerjs/sheets univerjs/sheets-ui univerjs/ui初始化过程在官方仓库里有比较清晰的示例核心思路是创建一个Univer实例加载Sheet插件和UI插件再把Workbook配置传入。需要注意Univer版本更新非常快接口名可能变化我的建议是选定一个版本后固定依赖比如使用锁版本的写法避免构建时莫名其妙升级。一个最小化的启动逻辑可以这样理解import { Univer } from univerjs/core; import { UniverSheetsPlugin } from univerjs/sheets; import { UniverSheetsUIPlugin } from univerjs/sheets-ui; import { UniverUIPlugin } from univerjs/ui; const univer new Univer({ // 这里传入Univer核心配置比如当前环境、语言等 }); univer.registerPlugin(UniverSheetsPlugin); univer.registerPlugin(UniverUIPlugin, { container: app, }); univer.registerPlugin(UniverSheetsUIPlugin);后续要加载一个预设的Workbook数据通常会传入一份JSON格式的工作簿配置里面包含Sheet名称、行列分布、单元格初始值、样式、合并单元格等信息。因为Univer的数据模型是DocumentData模型你可以把模板标准化成这个结构。我这里不展开全部配置字段但你只要记住先在本地用官方Demo或者一个最小JSON跑通页面再往上叠加需求。千万不要上来就直接改内部数据模型否则排查问题会非常痛苦。3.2 定义单元格白名单的数据结构权限第一步把“可编辑区域”定义成一份干净的配置。我当时定义了一个独立的配置模块editable-config.ts方便运营人员在界面修改也方便后端按角色下发不同配置。export interface EditableRange { sheetId: string; startRow: number; startColumn: number; endRow: number; endColumn: number; } export const DEFAULT_EDITABLE_RANGES: EditableRange[] [ { sheetId: sheet-01, startRow: 2, startColumn: 1, endRow: 8, endColumn: 3, }, ];这个数据结构的含义是在sheet-01里第2行到第8行、第1列到第3列围成的矩形区域是用户可填写的。作为简化版我用了“矩形白名单”的概念。矩形虽然灵活度有限但它最容易理解和维护也最容易在后端做校验。如果你的业务里白名单比较碎比如只允许填A2、B2、C5这种分散单元格可以把多个矩形叠加本质还是一样的。实际运行时判断逻辑可以简化为用户要改的目标Range是否完全落在某个白名单矩形内。如果是放行否则拦截。3.3 两步实现“锁定其他单元格”第一步利用Univer的保护能力把非白名单区域标记为受保护。不同版本的Univer对保护能力的支持力度不同有的版本可以通过工作表配置里的protect字段设置或者在UI层操作。如果当前版本的保护能力不完全覆盖Range级就需要走第二步的Command拦截。第二步在Univer的命令分发层注册拦截逻辑。Univer的命令系统有一个比较理想的扩展点注册ResolveCommand或BeforeExecute类型的钩子。在每次命令真正执行前我们可以拿到命令名比如“设置单元格值”然后取出要操作的Range信息和目标Range做比对。伪代码大致如下const COMMANDS_TO_INTERCEPT [ sheet.command.set-range-values, sheet.command.paste, ]; registerCommandInterceptor((commandPayload) { if (!COMMANDS_TO_INTERCEPT.includes(commandPayload.type)) { return { shouldExecute: true }; } const targetRange extractTargetRange(commandPayload); const isAllowed editableRanges.some((range) isRangeInsideEditableRegion(targetRange, range) ); if (!isAllowed) { showToast(该单元格为只读区域不能修改); return { shouldExecute: false }; } return { shouldExecute: true }; });这个思路不依赖某个具体版本的精确API名称核心是理解Univer命令模式的工作原理。实际接入时你要根据你锁定的Univer版本来查看命令名和参数结构。这里有个关键点不仅要拦截“手工输入”还要拦截“粘贴、拖拽填充、导入”等行为。粘贴命令尤其重要因为用户经常从外部Excel复制一排数据往里贴如果只拦截普通输入粘贴会直接突破防线。3.4 组合后的行为表现这套组合做完之后用户的真实体验是点击白名单区域内的单元格光标正常出现可以输入、回车、Tab切格点击非白名单区域单元格可以被选中但不会进入编辑状态在只读区域尝试输入时命令被拦截页面出现提示单元格值不变复制白名单区域的内容、粘贴到只读区域时同样被拦截不会造成数据污染。这个表现已经非常接近Excel里的“保护工作表但允许选定锁定单元格”的效果同时比纯前端校验可靠得多。3.5 最小Demo的目录结构如果从零开始搭建我建议目录结构按下面这样组织src/ main.ts // 项目入口初始化Univer config/ editable-config.ts // 可编辑白名单配置 workbook-template.ts // 预设的Workbook JSON模板 services/ edit-guard.ts // 命令拦截逻辑可编辑区域校验 views/ App.ts // Univer容器和生命周期管理这样分成三层的好处是模板数据和权限配置可独立修改和Univer的接入层解耦EditGuard专注于校验逻辑方便单元测试App只负责挂载和销毁。4. 三种实现方案的实测对比与选型在真正落地过程中我试过三种方案各有优缺点。这里把实测情况完整说清楚帮你少走弯路。4.1 方案A纯官方保护能力如果Univer未来的版本提供了完善的Worksheet级或Range级保护机制那么最理想的方案是直接用官方保护API把指定区域标记为锁定即可。优点是不需要自定义命令拦截逻辑跟随表格内核一起走不容易出现数据不一致的问题。缺点是目前版本的覆盖能力有限某些场景比如“公式可以重算但不能手工改”这种细分需求纯保护方案不一定能完全支持。而且官方能力通常偏通用对业务提示文案这种交互需求无能为力。4.2 方案B命令层拦截快照回滚这是我最终用的核心方案。核心思想是不试图彻底阻止渲染层进入编辑状态而是在命令执行前拦截。拦截失败时还可以做一个兜底在执行完非法命令后立即用快照把对应Range恢复原值。这样做的好处是无论有多少种编辑入口包括未来新增的功能比如批注、数据验证、浮动图片都能在命令层统一兜底。缺点是要维护一份“合法区域”的判断逻辑并且要处理撤销栈。4.3 方案C每次操作后全量校验修复还有人在社区里提出过不如在每次表格变更之后遍历所有非白名单单元格如果发现值变了就改回去。这个方案实现很简单但性能和健壮性都差。因为表格数据量一上来全量校验的耗时直线上升而且它只是在“已发生的错误”上打补丁用户会看到数据闪变体验很差。我自己的测试里在几百行数据的表上做全量校验每操作一次都有明显卡顿。这个方案我只在紧急兜底时用不建议作为主方案。4.4 我的推荐组合结合以上三种方案的实测我的推荐是按优先级组合优先级能力作用第一层Univer官方保护配置内核层面阻止非法写入第二层命令层拦截提供用户提示阻断异常交互第三层快照恢复兜底处理绕过拦截的意外变更这个组合的关键是不要把命令层拦截当成唯一防线。因为Univer的命令名在不同版本可能调整有些第三方扩展或未来新增的编辑功能可能不经过你拦截的这几个命令。保住第三层快照恢复等于给数据一致性上了最后一道保险。5. 真实验证中的坑版本差异、协同并发、撤销重做与移动端5.1 Univer版本更新快API别写死我接入的时候Univer还在快速迭代官网示例和GitHub README里的代码可能与具体发布版本有出入。最直观的问题就是你查到的某个API在旧版本不存在新版本又改了名字。我的经验是固定依赖版本号不要用latest或者next项目里锁定一份Univer源码快照需要查阅实现时直接翻node_modules里的源码升级版本时把所有权限相关代码作为重点回归项测试特别是命令名是否变化。Univer底层设计确实有优秀的地方比如数据模型沉淀后没有频繁改动但UI层的命令注册机制相对活跃一旦升级命令拦截相关代码很可能要跟着调整。5.2 协同编辑下保护策略不能只写在前端如果你的项目不止一个人同时编辑同一张表那要格外注意Univer本身只是客户端编辑器多人协同需要你自建或接入协作服务。这个时候仅仅在前端做白名单拦截是不够的因为别人可能通过不同的客户端连接直接发出一个修改命令不经过你的前端拦截。正确做法是把可编辑白名单规则同步到协作服务端让服务端在执行命令时也做同样的权限检查。前端拦截更多是为了用户体验后端校验才是数据安全底线。如果你们暂时没有协同需求单机模式下前端拦截已经能用但一旦接协同权限规则必须能下沉到服务端。5.3 撤销重做会绕过你的“回填原值”吗这是我在测试时踩得比较深的坑。我的逻辑里有一个兜底快照当检测到非法命令执行后试图恢复Range的原值。不过一旦用户按了CtrlZ撤销栈会认为刚才的“恢复原值”也是一次变更可能产生奇怪的状态用户撤销时反而把只读区域里的旧值覆盖了或者撤销提示提示错误。解决办法是对由程序发起的“恢复回滚”操作进行特殊标记并且把这类操作排除在用户撤销链路之外。更稳妥的做法是尽量不要走“先执行非法命令再恢复”的路线而是尽量在命令执行前就拦截掉。如果确实存在那种绕过拦截的写入恢复原值时建议同时清除对应的撤销记录或者直接对目标Range加一层顶层保护禁止用户交互撤销。5.4 移动端适配和输入法问题线上填报场景里不少用户会拿手机或平板操作。Univer本身对移动端有基本支持但权限控制这块有几个细节容易翻车只读区域的点击判断在触屏上有延迟用户容易误触移动端键盘弹出后计算列的滚动位置可能被顶上去部分中文输入法在合成拼音过程中会触发多个中间态命令如果不针对输入法命令做处理会出现“输入一个字被拦截N次”的提示轰炸。我的建议是在移动端弱化“精确点击编辑”的交互把白名单区域用背景色明显标识出来甚至提供“点击区域自动聚焦下一格”的快捷操作。这需要你在编辑器和业务组件之间做一点桥接但实际效果很值得。5.5 公式单元格的特殊处理最后说一个最容易忽略的点表格里通常有公式列比如合计、比例、排名。用户大部分情况下不需要手填公式区域但公式结果会被其他单元格的修改触发重算。如果你的白名单判断过于激进把含有公式的单元格判定为只读可能导致公式无法更新结果整个表就失去联动性了。我的做法是允许公式内部重算写入值但不允许用户直接手工编辑公式区域。也就是说权限判断时要区分“命令来源”。如果一条命令是由公式引擎计算触发的放行如果命令来源于用户交互则按白名单规则拦截。这一点需要在命令拦截逻辑里拿到命令的来源标记不同版本实现方式不同但核心思路是一样的——权限判断不能只看最终写入的Range还要看触发的动作类型。如果你现在也要做类似的填报表格我的建议是先把需求拆成两层来看把Univer当作单元格编辑器和展示层把“可编辑白名单”当作业务权限模型。两者之间用命令拦截衔接先跑通最小闭环再加入模板下发、后端校验、移动端适配。不要一开始就追求和Excel完全一致的权限体验先把“该填的能填、不该填的改不了”这个基本盘守住后面再慢慢细化交互细节。
