一份"谁也说不清改没改"的检测报告

某特检院出过一件事。一份电梯定期检验报告，实验员老张刚录完原始数据，分析员小陈的 Excel 就已经打开了——小陈的计算公式引用的正是老张刚填的那些单元格。两人各自在自己的窗口里操作、各自点保存。后保存的覆盖了先保存的，原始数据莫名"变"了几个值。

三个月后设备年检复查，对不上账。追责时各执一词：老张说"我录完就是那个数"，小陈说"我打开的时候它就是这样的"。系统日志里只有一条冷冰冰的"文件已保存"，谁改了哪个格子、什么时候改的，无从查证。

这件事的根源不在人，而在工具——整张报告是一个 Excel 文件，所有人都能改任何一个格子，改完还不留痕。这不是个例，而是检测行业用 Excel 协作时的通病。

---

检测报告的"多角色协作"本质

要理解权限管理为什么重要，得先看清楚一份检测报告是怎么"长"出来的。

在典型的 LIMS 流程中，一份报告至少要经过三个角色的手：

• 实验员：在实验室现场操作仪器，把原始读数（温度、压力、扭矩、尺寸……）录入报告的"原始数据"区域。

• 分析员：拿到原始数据后，做修约计算、判定合格与否，填写"计算结果"和"结论"区域。

• 审核员：复核全部内容，确认无误后签字签发。

关键在于：每个角色只能动自己负责的那一部分。实验员不该碰结论栏，分析员不该改原始读数，审核员谁的数据都不能改。这不是"不信任"，而是合规的基本要求——数据可追溯的前提，是职责可分离。

如果这套边界守不住，后续的审计追踪、电子签名、CNAS/CMA 认证，全都建立在沙地上。

---

Excel 的权限粒度，卡在"全锁还是全开"

上述边界，Excel 守起来非常吃力。问题出在权限粒度上。

整表保护：要么全锁，要么全开。 Excel 的"保护工作表"是全局开关，一旦启用，所有单元格默认锁定。想让某个角色编辑某些区域，得提前逐个单元格设置"锁定=否"。实际业务中没人这么做，结果就是要么密码一给全表开放、要么锁死让所有人只读。

工作表级隔离：无法满足"同一张表多角色"。 一个变通办法是给每个角色单独建一个 Sheet。但检测报告是一个整体，原始数据、计算结果、结论签发在同一张表上才有上下文关联。拆成三张表，数据对照和公式引用全乱套。

单元格级配置：繁琐且无法保存为"角色规则"。 退一步说，就算逐格设置锁定状态，Excel 也没有"角色"的概念。你没法说"B2:B10 允许实验员编辑、D2:D10 允许分析员编辑"——它只认密码，不认人。每来一个新人，就得手动重配一遍。更别提一份电梯检验报告动辄上百个填报单元格，手工逐个点开属性面板去设"锁定"，工作量让人望而却步。

密码共享：权限形同虚设。 最尴尬的现实是，很多机构为了方便，保护密码全科室共享。所谓的"保护"，最后变成了"谁都知道密码、谁都能改、改完互相不知道"。权限管理沦为一纸空文。

---

SpreadJS 方案：模板态 + 填报态的双场景设计

SpreadJS 的思路是：把权限当成模板的一部分，和单元格一起设计、一起存储、一起流转。 它通过"模板设计态"和"填报运行态"两个场景，把权限这件事彻底系统化。

模板设计态：右键设权限，Tag 持久化

在模板设计器里，管理员选中一片区域，右键菜单点开"权限管理"弹窗，勾选哪些角色可以编辑这片区域，确认即可。底层做的事情很轻量——系统把角色列表序列化成 JSON，通过 sheet 的 tag 方法写进单元格。Tag 是 SpreadJS 原生支持的单元格元数据，跟值、样式、公式一样，会随 .sjs 模板文件一起持久化。不需要额外建数据库表，也不需要改文件格式。

这意味着权限规则和模板是"一体的"。模板存到服务器、下载到本地、分发给分支机构，权限规则都在里面，不会丢失。下次打开模板，右键同一个区域，弹窗会自动回显之前配置的角色——因为 Tag 还在。

有人会问：把权限写在 Tag 里，安全吗？需要说明的是，Tag 存的是"权限元数据"（哪些角色可编辑），不是安全凭证。真正的拦截发生在填报态——工作表保护（isProtected）是 SpreadJS 引擎层面的硬约束，用户无法绕过前端直接改锁定的单元格。至于服务端校验，那是另一道防线，和前端权限互为补充，而非互相替代。

填报运行态：按角色解锁 + 浅蓝底视觉标记

到了填报环节，用户先选择自己的身份（实验员/分析员），系统加载模板后，自动遍历所有带 Tag 的单元格：凡 Tag 里包含当前角色的，就解锁并打上浅蓝色底（#EBF5FF），其余全部锁定（开启工作表保护 isProtected，单元格默认 locked）。

这个浅蓝底不是装饰，而是关键的视觉契约：用户一眼就知道哪些格子归自己管，不用记、不用猜。对于检测行业来说，这一点尤为重要——一份报告可能密密麻麻几十上百个填报项，如果没有任何标记，实验员得对照 SOP 文档一项项找"我该填哪格"，出错率极高。有了浅蓝底，所见即所填，认知负担直接归零。

再配 Ribbon 工具栏的动态启用机制——选中锁定区域时，字体、颜色、边框等编辑按钮自动灰掉——从 UI 层就把"越界操作"挡在门外。这套机制依赖 SpreadJS 设计器的 enableContext 能力：监听 SelectionChanged 事件，实时判断当前选中区域是否全部解锁，据此联动工具栏按钮的可用状态。

---

真实案例：投诉归零，返工率降六成

某特检院在引入这套方案之前，"数据被误改"是长期痛点。原因前面说过：Excel 整表共享，谁都能改，改完不认。

部署基于 SpreadJS 的角色化填报后，变化是立竿见影的：

• "数据被误改"投诉归零。 实验员看不到分析员的格子（锁着），分析员改不了原始读数（锁着），职责边界从"靠自觉"变成了"靠系统"。

• 审核返工率下降 60%。 审核员不再需要反复确认"这个数到底是谁写的、中间有没有被改过"，因为每个人只在自己有权限的区域操作。

• 新人上手成本骤降。 浅蓝底就是操作指引，不用培训"你只能填哪几列"。

更深层的好处是，这套权限规则跟着模板走。新建一份报告，加载模板，权限自动生效——零配置、零遗漏。分院拿到总部下发的模板，权限结构完全一致，不必重复维护。这在多分支机构的大型检测集团里，价值尤其突出。

---

权限的本质，不是限制，是让对的人做对的事

回到开头那个故事。如果当时用的是角色化填报，老张登录时看到的是浅蓝底的原始数据区，小陈登录时看到的是浅蓝底的计算结果区——两人各自在自己的区域操作，系统只允许各自保存各自的部分，"后保存覆盖先保存"的混乱根本不会发生。

很多人把权限管理理解成"防范"——防着员工乱来。但在 LIMS 这种强合规场景里，权限的真正价值是让协作变得有序。实验员不用担心"我是不是误改了不该改的"，分析员不用担心"原始数据对不对得上"，审核员不用担心"中间有没有人偷偷动手"。每个人都只需要、也只能够对自己那部分负责。

这就是"精确到单元格"的意义：不是把权限切得更细来为难人，而是把职责划得更清来成全人。技术做到位了，合规就不再是额外负担，而是自然而然的结果。