一、一张巡检记录表里藏着什么
2026 年 7 月，GB/T 47856-2026《水电厂发电设备智能巡检技术导则》正式发布。标准本身在谈巡检流程、智能分析和辅助决策，但落到系统实现层，第一个动作不是调 AI 模型，是把巡检记录这张表做对。
拿一张 10kV 高压开关柜的巡检记录表做拆解。整张表可以切成三个区域：
固定参数区 —— 设备编码、开关柜型号、额定电压、额定电流、出厂日期。这些字段数量和类型固定，不同开关柜之间只是值不同，结构不变化。
巡检明细区 —— 巡检点位逐行展开：断路器触头温度、隔离开关触头温度、柜内湿度、SF6 气压、局部放电量……每个柜子的巡检点位数量取决于其结构，双母线柜比单母线柜多一倍触头；如果巡检途中发现一个异常点，还要额外追加一行"临时复核项"。这个区域的行数完全不可预判。
决策判定区 —— 综合明细区的数据，巡检员给出整体判定（"正常 / 注意 / 异常"）和建议。判定规则是一组跨多行的聚合条件：任意一个触头温度超过 65℃ → 等级提升为"注意"；任意一个气压低于报警阈值 → 判"异常"。
这三个区域对表单引擎的要求截然不同：固定区是静态表单、明细区是数组驱动的动态表单且需要支持运行时扩展、判定区是跨单元格的公式计算。传统"一个页面一组 v-model"的做法在这一张表面前已经行不通了，因为明细区的数据根本不是一个固定长度的数组。
二、如果自己写，要解决什么问题
先不急于选型。按照工程师的思维习惯，先把"如果自研这个能力"的问题清单列出来：
行列的索引管理。 一个动态行区域不是画一个 table 然后 v-for 循环那么简单。新增行、删除行后，整张表的字段索引会偏移，所有依赖行索引的校验规则都需要重新绑定。删除中间一行后，后面所有行的"上一行引用"公式都要整体前移。这块的逻辑如果手写，需要单独维护一份行索引映射表。
校验的注入与销毁。 巡检记录中，动态行的每个字段（温度、湿度、气压）都有自己的校验规则——温度不能为负、气压必须高于阈值。当后台数据传来 N 条巡检记录时，引擎要替这 N 行各生成 N 组校验规则实例；当用户手动新增一行时，新行要自动继承该动态区的整套校验规则。写在一张静态表里没问题，写在动态表里就是从零开始的规则生命周期管理。
回填的定位。 假设"上次巡检值"需要从历史数据库接口取回来填到每一行的"上次读数"列。这需要三个步骤：知道该调用哪个接口 → 知道接口返回的 JSON 里取哪个字段 → 知道这个字段要落到哪一行的哪一个单元格。第一步还算简单，第二步和第三步加起来等于在表中实现了一个完整的"外部数据 → 单元格"的寻址系统。
公式的跨行引用。 判定区需要引用明细区多行的聚合结果（"任意一个触头温度超过 65℃"），这意味着公式引擎不能只看当前单元格，要能跨行、跨字段、跨数据源做条件表达式。
如果严格算下来，自研一个完整的动态表单引擎，仅行列管理、校验注入、回填定位和跨行公式这四个模块，就需要投入多个工程师持续数月，而且每个模块各自有一组边界情况需要踩坑。在做技术选型之前，先把这个推演过程跑一遍是有意义的——它定义了"我们到底需要一个什么样的东西"。
三、找到一个合适的技术底座
梳理完自研成本后，技术选型的方向就清晰了：不自己造轮子，找一款已经把这四个模块做好的表单渲染引擎集成进来。
研发团队在表单渲染层引入了 FlashTable 作为核心渲染引擎组件。这类基于 JSON 字段路径映射（fieldName 的 . 和 # 规则）的方案，在数据建模阶段就把巡检记录表的结构表达清楚了。
以刚才的开关柜巡检记录为例，JSON 数据模型是这样的：
{
"device": {
"code": "SWG-A01", "model": "KYN28A-12", "ratedVoltage": "12kV" },
"inspection": {
"date": "2026-08-07",
"items": [
{
"point": "断路器触头A相", "temp": 38.2, "alarm": false },
{
"point": "断路器触头B相", "temp": 41.5, "alarm": false },
{
"point": "隔离开关触头A相", "temp": 35.8, "alarm": false }
],
"verdict": "正常"
}
}
device.model、device.ratedVoltage 是静态字段，对应固定参数区的单元格。inspection.items 标记为数组，它的长度就是巡检明细区的行数——三个触头点位就渲染三行，扩建后变成五个点位就渲染五行。inspection.items#point、inspection.items#temp 则是数组中每个对象下的子字段，直接对到每行的"巡检点位"和"实测温度"列。
这里面有一个重要的设计思想：表单模板只声明一次布局和绑定规则，不关心运行时到底有多少行数据。 同一套模板今天挂到 A01 开关柜（三个点位），明天挂到 B03 开关柜（五个点位，还多了 SF6 气压列），不需要任何模板变更。设计器通过数据源推送接口对接字段定义，字段增减只是 JSON 配置层面的一次修改。
四、动态渲染里那些容易翻车的地方
动态行的核心逻辑是"数据定义行数"。后台传多少条巡检点位数据，表单就渲染多少行。代码层面只有一行调用：
rpc.LOAD_DATA({
id: 'inspectionTask-B03-001' });
// 引擎读取 inspection.items 数组长度，为每个元素生成一行单元格
但这只是表层。真正容易翻车的地方藏在下面。
第一个容易翻车的是异常点位的处理。假设巡检中开关柜 B03 的第三个点位（隔离开关触头 B 相）温度达到 68℃，触发了"异常"判定。巡检员需要在这个点位下追加一行"复核记录"，包含复核时间、复核人、复核温度、处理措施四个字段。这行是临时手加的，不是后台传来的原始数据，但必须和原始行绑定在同一个逻辑分组里。引擎的设计是：手动新增的行自动继承该动态区的校验规则（复核温度不能为负、复核人必填），同时不改变数组原始长度——手动行以增量方式叠加在数据驱动行之上，提交时两者合并但标记来源。
第二个容易翻车的是单行字段的变动波及整个动态区。比如 SF6 气压的报警阈值从 0.5MPa 降到 0.45MPa——如果这个阈值是写死在前端代码里的常量，改一个字就要改代码、走发版。在字段路径映射的方案里，报警阈值是设计器中的一个参数属性，修改后所有引用该字段的校验规则自动更新。这不是一个"配置化"的口号，而是字段级别元数据驱动的必然结果：校验规则作为字段元数据的一部分存储，字段不被硬编码，校验自然也不被硬编码。
五、回填不是简单的 HTTP GET
巡检记录中有一类数据天然不该由人工录入：设备铭牌参数、上次巡检值、在线监测实时读数。它们分散在资产台账系统、历史巡检库和 SCADA 数据中台里，需要表单在加载时自动拉取并在正确的位置展示。
这听起来像是一个"配几个接口地址"就能解决的事，但实际写起来有两层复杂度。第一层是寻址——接口返回的 JSON 在哪个路径下取目标值，取出来之后放进表单的哪一行哪一列。第二层是动态行内的逐行寻址——N 行巡检点位对应 N 次回填，每次回填要知道自己落在第几行。
方案采用了"URL 映射 + Result Path"的回填配置模式，同时封装了一个提取函数来屏蔽 JSON 路径解析的细节：
function extractValue(response, resultPath) {
return resultPath.split('.').reduce((obj, key) => {
const idx = key.match(/^(\w+)\[(\d+)\]$/);
return idx ? obj[idx[1]][+idx[2]] : obj[key];
}, response);
}
// 调用示例
rpc.SET_DATA({
'device.ratedCurrent': extractValue(ticketRes, 'data.rating.current') });
注意这个提取函数处理的不仅是简单的点号路径 data.rating.current，还要兼顾数组下标路径 data[0].value——后者在回填历史巡检值这类"取最近一条记录"的场景中很常见。每一行的回填规则独立触发、互不阻塞，巡检员切换点位时引擎携带对应点位的参数重新请求接口，结果精确落到该行单元格。
六、从 iframe 到数据库，数据的完整旅程
表单引擎与巡检主系统的集成方式是 iframe 嵌入 + postMessage 通信。选 iframe 而非页面内嵌组件的原因很简单：巡检系统和表单引擎部署在两套隔离的 Docker 环境里，前端不能共享运行时。postMessage 是没有任何框架依赖的跨域通信基础能力。
通信协议极简：{ command: "LOAD_DATA", data: { id: "xxx" } }。整个生命周期的事件流大致是：
- 主系统打开巡检任务 → 创建 iframe 并加载表单页面
- 表单引擎发出
TEMPLATE_LOADED→ 主系统调用LOAD_DATA注入巡检数据 - 引擎收到数据后自动渲染动态行、执行回填规则 → 完成后发出
DATA_LOADED - 巡检员填报过程中字段值变化 → 引擎持续发出
TEMPLATE_VALUE_CHANGED，主系统可选择监听做实时校验 - 巡检员点击提交 → 引擎触发
SUBMIT_DATA→ 返回数据 ID → 主系统将 ID 与巡检任务绑定保存
整个过程主系统只负责两件事：LOAD_DATA 注入数据，SUBMIT_DATA 拿回 ID。中间所有的渲染、回填、校验、行扩展都由引擎内部完成，主系统的巡检业务逻辑不受影响。
七、私有化交付：数据主权不是可选项
电网场景下，"数据不出域"不是性能优化建议，是合规底线。因此表单引擎的交付不是挂一个 SaaS 地址，而是把整个服务打成离线 Docker 镜像包，在巡检系统所在的内网服务器中独立部署。镜像内置了表单渲染的全部依赖和第三方组件，支持 OpenEuler 和 OpenKylin 等国产操作系统。部署流程只有三步：上传离线包、解压、运行一键部署脚本。服务启动后通过标准 API 与巡检系统交互，表单模板和填报数据落盘在本地目录，从产生到存储到销毁，全链条数据都在内网闭环。
八、推演复盘
回看最初的"自研清单"——行列索引管理、校验注入与销毁、回填定位、跨行公式——每一个都可以独立成为一个小型技术项目。做技术选型的价值在于判断哪些值得自己攻克、哪些应该交给现成的引擎。本文选择的路线是：数据结构用 JSON 字段路径映射表达，渲染用数组驱动动态行，回填用 URL 映射 + Result Path 构建外部数据寻址系统，集成用 iframe + postMessage 轻量 RPC 解耦，部署用 Docker 离线包实现完全私有化。五个环节各自承担独立职责，组合起来就是巡检记录数字化的完整技术方案。
对于面临类似决策的同行来说，关键不在于选哪个具体产品，而在于先搞清楚自己到底要解决哪几个底层问题、每个问题的自研成本有多高，然后带着这张清单去做技术选型。
