

## 一、结构放在哪，决定了后面所有的麻烦

“表单开发”这个词很松。三个人说同一句话，指的经常不是一件事：一个想把纸质表格在浏览器里画出来，所见即所印；一个只想给业务表配套录入界面，字段对了就行；还有一个想让业务部门自己拼个问卷，明天就不管了。

用什么渲染库、上不上框架、写代码还是拖拉拽，这些差别都不重要。真正决定后面一切的是：表单的结构存放在哪里。

放在代码里，是控件路线。放在一份规则数据里，是 JSON 路线。放在文档本身，是模板路线。

写第一张表的时候，这三条路几乎看不出区别。代价从第三张、第五张单据开始显形。下面按“结构放在哪”把三条路拆开，每条先说清楚它是什么、为什么会出现，再看它具体怎么实现、在哪儿卡住。

## 二、控件：结构写进代码

控件路线是三条里资历最老的，也最贴近电子表格本身。页面上摆一个表格网格控件，它提供行列、单元格、样式、公式的读写 API，开发者在自己的页面里实例化，再把业务数据按坐标塞进去。控件负责把格子画对，你负责告诉它每个格子里放什么。

它的能力上限是三条路里最高的。合并单元格、冻结、缩放、公式计算、条件格式、大数据量下的虚拟滚动，控件层都已经做好了；渲染和数据完全解耦，喂什么画什么；性能也可控，脏区重绘、按需加载都有成熟做法；底层 API 开放，碰到边界情况还有得兜。

代价就埋在 `MAP` 里。模板里每个字段占哪个格子，必须在代码里重写一遍坐标。表一改版，比如业务部门把样品名称从第三列挪到第四列，或者把两个格子并了，代码跟着改，跟着发版。

一张单据能忍。五十张单据就是五十份坐标表。更麻烦的是这份映射不落在任何能被校验的地方：它是函数体里的常量，没有结构定义，没有版本，也没有校验。改错了不报错，只会在某张单子上把值写进错位的格子。线上表现是数据看着没丢，整张表对不上。

所以它适合“算”的活。预算编制、数据透视、计划排产、工程量计算，这类以单元格计算为中心的界面，控件路线是正解。只有三五张表、以后也不打算动的，也够用。

不适合的是单据形态多、业务方还在持续改版式的场景。这时候每来一个版本变更，都是一次开发任务。

## 三、JSON：结构序列化成规则

JSON 路线要解决的是控件路线里的坐标硬编码问题。既然坐标写在代码里难维护，那就把结构从代码里抽出来，变成可序列化的数据：一个字段数组，每个元素描述名字、类型、标签、校验、联动。控件路线里“这张表有哪些字段”，散落在无数个 `setValue` 调用里；换成 JSON 之后，这句话变成了一份文件。

```json
{
  "fields": [
    { "field": "inspectNo",  "label": "检验单号", "type": "text",   "required": true },
    { "field": "sampleName", "label": "样品名称", "type": "text" },
    { "field": "items", "label": "检测项", "type": "array",
      "children": [
        { "field": "name",   "label": "检测项目", "type": "text" },
        { "field": "result", "label": "实测结果", "type": "number" }
      ] }
  ]
}
```

渲染器读这份规则逐条生成输入控件，提交时按同一份规则收集和校验。结构从代码变成了数据。

这条路的工程性质是三条里最好的。结构可序列化，就能存库、能版本化、能 diff、能由程序生成。加字段不用改代码，改规则就行。动态性天然具备，数组类型的 children 本身就描述了明细行。前后端可以共用一份定义，校验规则不必写两遍。渲染器能做得很薄，它只需要解释规则，不需要懂业务。

问题出在维度上。规则模型是一维的，版式是二维的。

上面那份规则表达不了“检验单号在第 2 行第 1 格、样品名称在第 2 行第 3 格、中间隔着一个合并单元格”。要表达位置，只能往规则里塞 span、rowSpan：

```json
{ "field": "sampleName", "label": "样品名称", "type": "text", "span": 2 }
```

span 只能说“横着跨几格”。一个格子同时跨 2 行 3 列、邻居还是非矩形排布，这种关系在字段模型里没地方放，只能在渲染器里写特例。

更微妙的是：一旦为了还原版式把坐标引进来，你就在 JSON 里重新发明了一张表格，而且比控件路线那份常量表更难读。至少代码里的常量还能打断点，规则里的坐标只能靠眼睛核对。

打印是第二个坑。规则描述的是一棵有语义的 DOM 树，打印时浏览器还得算一次排版；业务单据要的是“纸上第 3 行第 4 格，误差按毫米算”。中间没有免费的桥。常见做法是给打印单独写一套样式，于是屏幕上和纸上变成两套东西。

它不是不好，是被用错了地方。问卷、调查、审批单、参数配置，字段平铺、以语义为主、版式无所谓，这正是 JSON 路线的主场，也是它被大量采用的原因。

## 四、模板：结构就是那份文档

控件和 JSON 这两条路线，都需要另外准备一份“字段放在哪”的说明。控件路线把这份说明写在代码里，就是那张坐标常量表；JSON 路线把这份说明写成配置，是字段定义和 span 值。表格一改，这份说明跟着改，改完还得保证它和实际表格对得上。

模板路线不需要这份说明。它直接拿一份 .docx 当模板，文件里的表格长什么样，程序读出来就是什么样：每个单元格在第几行第几列、跨几行跨几列，都从文件的表格标记里读。字段绑在单元格上，位置不用再写一遍。

区别就在数据的份数上：前两条是两份，表格和说明；模板路线是一份，就是那份文件。

在此之前需要解决一个问题：.docx 是给人排版的格式，不是给程序存结构的格式。拿它当结构来源，前面就得多一道解析，把表格标记还原成可用的单元格结构。通用库只做到读标签这一层，合并关系的还原、行列增删后的重算，还得自己写。

但好在这类路线已经有成型的产品，例如 FlashTable 就是其中之一：接 .docx / .xlsx，导入时把表格结构解析成单元格结构，字段按路径绑到单元格上，渲染、填写、打印用的是同一份数据。下面按解析、绑定、循环、渲染打印四步，看这条路具体怎么做。

### 解析：从 OOXML 表格到单元格结构

解析的是 OOXML 里的表格结构。三层标签，`w:tbl` 包 `w:tr` 包 `w:tc`；列宽定义在 `w:tblGrid` 里，每个 `w:gridCol` 给一列；合并关系藏在单元格自己的 `w:tcPr` 中，横向用 `w:gridSpan`，纵向用 `w:vMerge`（`restart` 是合并起点，不带值的那个是延续）。

拿两行三列举个例子，一个格横跨两列、一个格跨两行：

```xml
<w:tbl>
  <w:tblGrid>
    <w:gridCol w:w="1134"/><w:gridCol w:w="1134"/><w:gridCol w:w="1701"/>
  </w:tblGrid>
  <w:tr>
    <w:tc>
      <w:tcPr><w:vMerge w:val="restart"/></w:tcPr>
      <w:p>备注</w:p>
    </w:tc>
    <w:tc>
      <w:tcPr><w:gridSpan w:val="2"/></w:tcPr>
      <w:p>检验结论</w:p>
    </w:tc>
  </w:tr>
  <w:tr>
    <w:tc>
      <w:tcPr><w:vMerge/></w:tcPr>
      <w:p/>
    </w:tc>
    <w:tc><w:p>合格</w:p></w:tc>
    <w:tc><w:p>张三</w:p></w:tc>
  </w:tr>
</w:tbl>
```

三列，第一行只有两个 `w:tc`，第二行有三个。第一行第一个格子的 `vMerge` 标了起点，第二行开头那个空 `w:tc` 是它的延续格，内容为空，位置由上面决定。

解析器要把这些压平成一棵二维的树，每个叶子记住自己占哪几行、哪几列：

```text
(row 0, col 0) ~ (row 1, col 0)    备注
(row 0, col 1) ~ (row 0, col 2)    检验结论
(row 1, col 1)                     合格
(row 1, col 2)                     张三
```

五个 `w:tc`，四个实际单元格，覆盖六个格位。这棵树建好之后存进模板版本，渲染时直接读，不再回头碰 XML。

合并块的边框记在单元格自己的 `w:tcPr` 里，跟着单元格一起进结构。版式里的线不是渲染时按格子重画的，是从文件里读出来的，所以打印出来的边框和原文档一致。

### 绑定：字段路径怎么找到单元格

字段往哪绑，用路径说。`.` 走对象属性，`#` 走数组元素。

```json
{
  "classroom": {
    "teacher": "李老师",
    "students": [{ "name": "张三", "grade": 90 }]
  }
}
```

```text
classroom.teacher         → 单个单元格
classroom.students        → 声明动态区（数组元素个数决定渲染行数）
classroom.students#name   → 动态区某列的取值路径
classroom.students#grade
```

`classroom.students` 这一行同时干了三件事：声明这里是一个动态区、告诉渲染器行数从哪来、给下面的列路径定前缀。

控件路线的绑定是 `MAP` 那张常量表，位置写在函数体里，没有名字也没有类型。JSON 路线的绑定是字段名对字段名，前提是两端都是字段。模板路线绑的是格子，路径只负责找到格子，格子本身是树里的一个节点，带着边框、合并跨度和行高。

### 循环：哪些区域要按数据重复

明细行不是给字段加个 isArray 属性实现的，而是在模板设计时圈一块区域、声明成循环区：行循环、列循环、行内列循环、块循环。渲染时数组有几条展开几行，样式、校验、公式按首行继承。

对照一下就清楚差别在哪。JSON 路线用 children 数组描述明细，语义是清楚的，但真渲染成行的时候仍然要按版式重排一次：表头行在哪、合计行在哪、每列多宽，规则里没有。控件路线用 `forEach` 展开，行高和样式得在代码里跟着算。模板路线圈的那块区域自带样式，数据有几条展开几行，展开出来的行按首行继承。

### 渲染和打印：为什么不用再排一次版

单元格尺寸来自 `w:gridCol` 的 twips 值（1 twip 等于 1/1440 英寸），页面尺寸和页边距写在 `w:sectPr` 里。渲染时按这套坐标落位，不依赖浏览器自动布局。

打印不用再排一次版，原因就在这儿：它是按同一套坐标再画一次，没有第二次布局决策。JSON 路线渲染出来的是 DOM，打印时浏览器要再排一次版，分页落在哪一行由浏览器决定，`break-inside: avoid` 只能保证一行不被拆开，跨页处的 `rowspan` 各浏览器表现还不一致；为了塞进 A4，常见做法是整体缩放，纸上的字号跟着一起变。控件路线如果走 canvas 渲染，DOM 那条路不通，得自己做打印：按行高算分页、把画布切成几段，或者导出图片和 PDF，代价是文字不可选、放大之后发虚。

版本跟模板文件一起存，`templateId` 加 `version` 决定取哪一版。六个月后模板改过、签字栏挪了位置，旧单据按当时的版本渲染，打出来的和当年签的是同一张纸。控件的坐标表没有版本；JSON 的规则能版本化，但版本里没有版式。

四步走完，这条路线的特点清楚了：解析、绑定、循环、打印用的是同一份数据。解析读出来的单元格位置，就是绑定用的位置，也是循环展开时复制的位置，还是打印时落位的位置。前两条路线里这四个环节不是同一份数据：控件是控件自己的网格加代码里的常量，JSON 是字段配置加渲染器里的排版逻辑，每换一个环节就要转换一次。

### 门槛在解析器，投入只需要一次

这条路线的工程量集中在解析器，而且集中在建模板之前的那一次。

上面那个例子只有两行三列，真实单据是四十行十几列，`gridSpan` 和 `vMerge` 交叉嵌套，区间树要记录每个格位属于哪个单元格。行列增删是区间重算：删掉一行，跨这行的纵向合并要收缩；删的是起点行，得把起点转移到下一行并接管文本；横向合并本身不受影响，但后面所有列的偏移要重算。非矩形合并也要处理，编辑器的合并操作能做出 L 形（先横并、再纵并、再接一格），矩形树表达不了它，只能拆成两个矩形或者识别出来拒绝。

动态区要在设计时圈出来。这份信息模板里没有，得另外存：区域坐标、循环类型、绑定路径，跟着模板版本一起走。圈错一格的后果很具体：多圈一行，多出来的行继承首行样式，首行是表头的话，明细末尾会拖出一条表头底色；少圈一行，第八条数据起被静默截断，不报错，等对账时才发现。圈定区域里如果有跨过边界的合并格，展开时没法按行复制，在设计时就拦下来。

模板本身也要过一道结构校验。手工拼出来的表常见两种毛病：拿空格对齐，拿边框线画出“合并”的效果。前者会在 `tblGrid` 里留下一堆极窄的列，看着六列的表，`gridCol` 可能有十四个；后者是一堆独立格子加手工边框，语义上从来没合并过。后果是视觉列和结构列对不上：绑 `items#result` 时按第三个视觉列算，实际落在第九个 `gridCol` 上，值填进去了，位置是错的。导入时校验每行 `gridSpan` 之和是否等于 `gridCol` 数、有没有宽度趋近零的列、有没有只有起点没有延续的孤立 `vMerge`，不合格的表退回重排。

这三件事都发生在建模板之前，做完就不再重复。控件和 JSON 的活是另一头：每来一张新单据、每改一次版式都要重做一遍，第一批单据上看不出差别，到第二十张会很分明。

也正因为解析器这部分是一次性的、通用的、跟具体单据无关的工程，它不需要每家公司自己做。成熟的表单开发工具已经把这层做完了，直接引入比自己从零写一个区间树划算得多——这也是这条路线上已经出现成型产品的原因。

### 适合场景

适合单据形态稳定、版式有约束、要归档打印的场景：检测原始记录、检验报告、审批单、出入库单、对外的交付表格。共同点是最终产物是一张有固定形态的纸，纸上每个格子都要对。

反过来，字段平铺、版式无所谓的问卷和配置页，走这条路是给自己找活：你没有一版要还原的纸，解析器白建。

## 五、技术路线对比总结

| 维度        | 模板             | JSON          | 控件          |
| --------- | -------------- | ------------- | ----------- |
| 结构载体      | 文档本身           | 字段规则数组        | 代码里的坐标表     |
| 合并单元格     | 解析结果即结构        | 一维字段模型，表达不了   | 控件原生支持      |
| 表头、签字栏、脚注 | 本来就在结构里        | 字段模型里没有对应物    | 代码里另画一遍     |
| 改版式由谁做    | 业务方直接改文档       | 改规则配置         | 改代码并重新发版    |
| 打印        | 与填写同源          | 浏览器二次排版       | 自行实现分页      |
| 动态明细      | 圈定区域声明循环       | 规则描述，渲染时按版式重排 | 代码里展开，样式跟着算 |
| 前期技术投入    | 高，需引入成熟的表单开发工具 | 低             | 低           |

一句话：要算选控件，要问选 JSON，要照原样选模板。

这张表逐行看下来，单据场景的答案没什么悬念。这类表单最后要落成一张纸，要签字、归档、审计，模板路线在结构保真、改版式的成本、打印还原这三项上同时占优，而且是三条里唯一不产生第二份结构的路线。控件要在代码里维护坐标，JSON 要在规则里维护 span，两者都得和那张纸保持同步，同步一断，错位不报错。

控件和 JSON 的主场不在这里。要算的选控件，字段为主的选 JSON。一个系统里同时跑三种表单很正常：预算编制用控件、内部申报用 JSON、对外出具的报告用模板。容易出事的是反过来，拿一条路去套所有场景，然后在一张具体单据上不断加特例。

选路真正要回答的不是“哪个技术更先进”，而是“这张表的结构最终归谁所有”。

结构归代码，就归开发团队，每次变更是一次迭代；归规则，归配置者，见效快，但表达力被字段模型卡住；归文档，归业务方，前期把解析器建扎实，之后改版式、换打印格式都不用再动开发。三条都要投入，区别在投入的时间点：一次付清，还是摊到每张单据上。单据越多，一次付清越划算。

检测原始记录、检验报告这类必须和纸上一样的单据，交给 FlashTable 这类以文档模板为结构的表单开发工具去承接，模板原样还原、明细按数据展开、打印与填写同源，比让开发人员把每张表的坐标写成常量要撑得更久。


“表单开发”这个词很松。三个人说同一句话，指的经常不是一件事：一个想把纸质表格在浏览器里画出来，所见即所印；一个只想给业务表配套录入界面，字段对了就行；还有一个想让业务部门自己拼个问卷，明天就不管了。

表单开发的三条技术路线：控件、JSON、模板

表单开发有三条路线：控件把结构写进代码坐标表，JSON 序列化成字段规则，模板直接以 .docx 为结构。前两条都要另存一份格子与字段的对应关系，改一次版式同步一次；模板路线解析一次得到单元格结构，渲染、填写、打印共用同一份数据。单据越多、版式越固定，第三条越省。

开发者

编程语言

表单开发三条技术路线深度对比：控件路线适合计算场景，JSON路线适合字段平铺场景，模板路线适合固定版式与打印归档场景。三者核心差异在结构存储位置，直接影响改版成本与维护难度。模板路线通过解析OOXML实现版式还原，是检验报告等单据的最优解。

代码解释

大数据

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

表单开发的三条技术路线：控件、JSON、模板-腾讯云开发者社区-腾讯云

表单开发的三条技术路线：控件、JSON、模板

表单开发的三条技术路线：控件、JSON、模板

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐