一、OA表单自定义化概述

什么是表单自定义化

说白了，表单自定义化就是让业务人员自己搭表单。

不用写代码，不用找开发。

拖拖拽拽，点几下鼠标，一个报销单、请假单就出来了。

我刚开始做OA那会儿，客户提个表单需求，我得排期两周。现在想想，真是浪费生命。

表单自定义化，核心就三件事：

• 字段自定义——文本框、下拉框、日期选择，想加就加
• 布局自定义——一行几列，分组折叠，随你安排
• 逻辑自定义——字段联动、计算公式、审批流程，都能配

嗯，这里要注意，不是所有表单都适合自定义。那些核心业务、高并发场景，还是老老实实写代码吧。

为什么需要表单自定义化

你想想看，一个中型企业，有多少种表单？

请假、报销、采购、合同、用印、出差、加班、调休……少说几十种。

每个表单的字段都不一样。今天财务说加个「预算科目」，明天HR说加个「职级系数」。

如果每次都找开发改代码，结果就是：

• 开发累成狗，天天改表单
• 业务等得急，一个需求排两周
• 系统越来越臃肿，维护成本飙升

我在项目中遇到过一家客户，光报销单就改了17版。每次改完，测试、上线、回滚，折腾得够呛。

后来上了自定义表单，业务自己配，半小时搞定。开发终于能腾出手做点正经事了。

表单自定义化的核心价值

价值这东西，说多了像吹牛。我挑三个最实在的讲：

1. 响应速度从「周」降到「小时」

   以前改个表单，需求评审、开发、测试、上线，一周算快的。现在业务自己配，上午提需求，下午就能用。

2. IT部门从「背锅侠」变「赋能者」

   业务说「系统不好用」，IT说「需求太多做不完」。两边都委屈。自定义化之后，IT提供平台，业务自己玩。谁也别怨谁。

3. 系统扩展性指数级提升

   传统开发模式，加一个表单就是加一堆代码。自定义化之后，加一个表单就是加一条配置记录。维护成本天差地别。

表单自定义化的挑战

说实话，这东西不是银弹。我踩过的坑，能写一本书。

一个简单的自定义表单配置示例

光说不练假把式。我拿一个最简单的请假单举例：

{
  "formName": "请假申请单",
  "fields": [
    {
      "key": "leaveType",
      "label": "请假类型",
      "type": "select",
      "options": ["年假", "事假", "病假", "婚假"],
      "required": true
    },
    {
      "key": "startDate",
      "label": "开始日期",
      "type": "date",
      "required": true
    },
    {
      "key": "endDate",
      "label": "结束日期",
      "type": "date",
      "required": true
    },
    {
      "key": "reason",
      "label": "请假原因",
      "type": "textarea",
      "maxLength": 500,
      "required": false
    }
  ],
  "layout": {
    "columns": 2,
    "groups": [
      {
        "title": "基本信息",
        "fields": ["leaveType", "startDate", "endDate"]
      },
      {
        "title": "补充说明",
        "fields": ["reason"]
      }
    ]
  }
}

你看，这就是一份自定义表单的配置。JSON格式，前端解析渲染，后端存储数据。

业务人员不需要懂JSON，他们通过可视化界面拖拽，系统自动生成这份配置。

嗯，这里有个坑要注意：字段类型别只给「文本」「数字」「日期」这种基础类型。我建议加上「关联表单」「附件上传」「签名」这些企业常用的高级类型。不然业务配到一半发现没有，又得找开发加，那就尴尬了。

总结一下

表单自定义化，说白了就是让业务自己动手，丰衣足食。

它的核心价值是快——响应快、迭代快、扩展快。

但挑战也不少——性能、权限、体验，哪个处理不好都够你喝一壶的。

我个人习惯，做自定义化之前，先问自己三个问题：

• 这个表单的变化频率高不高？
• 业务人员有没有能力自己配？
• 现有的技术架构能不能支撑动态渲染？

三个问题都回答「是」，那就放心大胆地干吧。