

## 一、检测原始记录的三段式结构

检验检测机构的核心产出，不是报告本身，而是报告背后的"原始记录"。检测人员每完成一次试验，都要把样品信息、试验条件、检测数据、计算结果如实记录下来，这份原始记录是检测结论的原始凭证，也是 CNAS、CMA 认可评审中重点核查的对象。

把一份典型的检测原始记录摊开来看，它同样由三个结构完全不同的区域构成：

- **固定信息区**：样品编号、样品名称、规格型号、委托单位、检测依据（标准号）、环境条件（温度/湿度）、检测设备（设备名称/编号/检定有效期）、检测日期。这些字段数量固定，不同样品之间只是取值不同。
- **检测明细区**：逐项展开的检测项目记录——检测项目名称、检测方法、原始测量值、计算值、单项判定。这个区域的行数随样品和检测标准变化，一个样品要测多少项、每项记多少数据，由标准决定，同一张模板要能容纳不同项目数。
- **计算判定区**：跨明细项的汇总计算与最终结论。

这三个区域对表单渲染层的要求截然不同：固定区是静态表单，明细区是长度可变的动态表单，计算判定区是跨行公式。传统的"一个页面一套 v-model"做法，在检测项目数量不可预知时，会直接失效。

## 二、把原始记录拆成数据结构

表单渲染的前提，是把界面上的单元格映射到业务数据上。一份金属材料拉伸试验原始记录，对应的业务数据可以组织成一棵 JSON 树：

```json
{
  "sample": {
    "no": "JC-20260825-017",
    "name": "热轧带肋钢筋",
    "spec": "HRB400 Φ20",
    "standard": "GB/T 1499.2",
    "temperature": 23,
    "humidity": 50,
    "device": "WAW-1000 万能试验机",
    "date": "2026-08-25"
  },
  "items": [
    {
      "seq": 1,
      "itemName": "抗拉强度",
      "s0": 314.2,
      "fm": 172.5,
      "rm": 549.0,
      "judge": "合格"
    },
    {
      "seq": 2,
      "itemName": "断后伸长率",
      "l0": 100,
      "lu": 121.5,
      "a": 21.5,
      "judge": "合格"
    }
  ],
  "conclusion": {
    "result": "合格",
    "remark": ""
  }
}
```

这里的关键，是定义界面单元格与业务数据之间的路径映射。映射规则用两种连接符表达字段在数据中的位置：`.` 表示对象属性访问，`#` 表示数组元素访问。例如 `sample.name` 对应样品名称，`sample.standard` 对应检测依据，`items#itemName` 对应明细数组中每一个元素的检测项目名称，`items#rm` 对应抗拉强度计算值。

这样一来，一张原始记录就不再是"一张画死的界面"，而是一组"单元格路径 → 数据字段"的绑定关系。界面长什么样由模板决定，数据往哪放由路径决定。

## 三、检测明细的数组驱动渲染

检测明细区是整张表最"活"的部分。同一个检测标准下，不同样品、不同委托要求，需要检测的项目数量并不相同——有的样品测 3 项，有的测 8 项。设计者只知道"一个项目一行"，至于要渲染几行，要等拿到检测任务才知道。

解决的思路是"数组驱动"：把明细区绑定到一个数组字段（`items`），渲染时数组有多少个元素，就渲染多少行。当系统向表单推送一份包含 N 个检测项目的数据时，明细区就自动展开成 N 行。

这个机制在数据设置上体现为：动态行绑定的数据源在业务数据中的取值必须是一个数组（或可解释为数量的正整数），渲染层以 `items.length` 作为行数依据，数组元素通过 `#` 连接符逐项映射到每一行的单元格上。

```json
// 推送的检测数据：items 数组长度 = 明细行数
{
  "sample": { "no": "JC-20260825-017", "standard": "GB/T 1499.2" },
  "items": [
    { "itemName": "抗拉强度", "rm": 549.0 },
    { "itemName": "屈服强度", "rel": 412.0 },
    { "itemName": "断后伸长率", "a": 21.5 }
  ]
}
```

除了由数据驱动，明细区也保留手动扩展的能力：检测人员如果临时增加复测项目，可以手动新增一行，新增行继承该区域的字段结构和计算规则。数组驱动解决"行数随项目变"，手动扩展解决"行数随现场变"。

## 四、公式计算的还原

检测原始记录里最容易被"走样"的，不是布局，而是公式。检测人员手里的线下表格，抗拉强度、伸长率、屈服强度这些计算值，是靠 Excel 公式算出来的；一旦线上化时公式丢失或逻辑不一致，计算值就错了，原始记录也失去了凭证意义。

公式计算的还原，关键是两点：一是把线下表格里的公式语义识别出来，二是让计算逻辑在线上按同样的规则作用于动态明细区的每一行。

以拉伸试验为例，各计算值遵循固定的物理公式：

```text
抗拉强度   Rm = Fm / S0                     （最大力 ÷ 原始横截面积）
断后伸长率 A  = (Lu - L0) / L0 × 100%       （断后标距与原始标距之差 ÷ 原始标距）
```

在字段路径映射下，这些公式通过路径引用单元格——比如某一行的抗拉强度 `items#rm` 由该行的 `items#fm` 与 `items#s0` 计算得出，伸长率 `items#a` 由该行的 `items#lu` 与 `items#l0` 计算得出。公式的作用范围跟着明细区走，而不是写死某几个单元格：无论明细区展开成 3 行还是 8 行，每一行的计算都自动成立。

## 五、数据回填：样品信息不用重复录入

原始记录上的很多字段，其实已经在实验室信息管理系统（LIMS）里存在了。样品编号、样品名称、委托单位、检测依据、检测设备，在 LIMS 的委托登记和设备台账里都有权威数据。如果这些字段还要检测人员手填，既慢又容易错。

数据回填解决的就是这件事：填报时，把这些已知字段自动带入表单。落地方式有两种：主系统在表单加载后主动推送（通过 SET_DATA / LOAD_DATA 这类数据写入命令，按字段路径把值写入对应单元格）；以及外部数据源绑定（在设计阶段把某个单元格绑定到外部数据接口，运行时取回目标字段填入）。

```javascript
// 主系统侧：加载表单后回填样品信息（伪代码）
rpc.SET_DATA({
  sample: {
    no: 'JC-20260825-017',
    name: '热轧带肋钢筋',
    standard: 'GB/T 1499.2',
    device: 'WAW-1000 万能试验机'
  }
});
```

回填落地之后，检测人员真正要手填的，只剩"这一次试验实际测出来的数据"——原始测量值，其余的从系统里带过来。

## 六、技术选型

在检测原始记录这一类"固定区 + 动态明细区 + 计算判定区"的场景里，研发团队在表单开发环节引入了 FlashTable 作为表单开发工具。它的特点可以概括为几个层面：

（1）以 JSON Schema 驱动表单结构，支持对 Word/Excel 模板的 1:1 还原渲染，原始记录的既有格式可原样保留；

（2）原生支持数组驱动的动态行渲染，检测明细区行数由 `items` 数组长度决定，同时支持手动加行并继承字段结构与计算规则；

（3）内置公式计算能力，公式通过字段路径引用单元格、随明细区逐行生效，支持从线下表格还原计算逻辑；

（4）提供 Docker 离线镜像包，支持在国产操作系统上私有化部署，检测数据落本地目录。

## 七、私有化部署与数据合规

检测原始记录属于检测机构的核心数据，受 CNAS、CMA 对记录可追溯、原始性的要求约束，通常要求数据不出域。这套工具以 Docker 离线镜像包交付，通过一键部署脚本拉起服务，数据落在本机目录，整套链路在内网完成，与主系统的通信只发生在内网 iframe 与 postMessage 之间。

## 八、总结

检测机构的原始记录表单，本质是"静态模板 + 动态明细 + 跨行计算"三类结构的组合。动态明细区用数组驱动渲染解决检测项目数量可变的问题，公式计算用字段路径引用解决计算逻辑还原的问题，数据回填用主系统推送与外部数据源绑定解决重复录入的问题，私有化部署解决数据不出域与合规的问题。这四件事拆开来看都是常规技术，难的是把它们收敛到一个低代码配置、可私有化交付的表单开发工具里。

检测原始记录、校准证书、质检报告这类场景的表单，交给 FlashTable 这类表单开发工具去承接——模板原样还原、明细按数据展开、公式逐行计算、数据落在本地——比从零搭一套渲染逻辑要务实得多。


检验检测机构的核心产出，不是报告本身，而是报告背后的"原始记录"。检测人员每完成一次试验，都要把样品信息、试验条件、检测数据、计算结果如实记录下来，这份原始记录是检测结论的原始凭证，也是 CNAS、CMA 认可评审中重点核查的对象。

检测原始记录表单的动态行渲染与公式计算设计

检测原始记录是检验检测机构数据链路的起点，也是 LIMS 里结构最复杂的一类表单：固定区承载样品与依据，明细区随检测项目动态增减，计算区依赖跨行公式。项目数量由标准与样品决定，行数运行时才可知；公式要逐行生效、按字段路径引用；样品信息还得从委托登记回填。三者叠加，静态模板加固定表单难以支撑，需要一套同时处理动态渲染、公式还原与跨系统回填的方案。

开发者

低代码

开发工具

架构设计

检测原始记录表单需解决固定区、动态明细区、计算判定区的混合渲染难题。采用JSON路径映射与数组驱动渲染实现明细区行数自动适配，通过字段路径还原Excel公式计算逻辑，并结合主系统数据回填与私有化部署确保合规高效。

数据接口

数据结构

代码解释

数据合规

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

检测原始记录表单的动态行渲染与公式计算设计-腾讯云开发者社区-腾讯云

检测原始记录表单的动态行渲染与公式计算设计

检测原始记录表单的动态行渲染与公式计算设计

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐