业务天天要加字段？动态表单与自定义字段三种方案对比

做企业系统的团队都遇到过这种需求循环：业务方说"客户档案要加个'信用等级'字段"，开发改表、改接口、改页面、发版；两周后"供应商要加三个自定义属性"，又一轮。字段需求永远跑在发版前面，开发烦、业务等，两边都憋屈。

核心矛盾是：业务字段的多变性与数据库表结构的稳定性天然冲突，把"加字段"的自由度开放到哪一层，决定了灵活性、查询能力和维护成本的平衡点。 业界有三条主流路线：实体表加列（DDL 扩展）、EAV 模型、JSON 扩展字段，灵活性和工程代价逐级变化。

方案一：实体表加列

原理： 最朴素的方式：新需求来了就在业务表上加列，ORM 映射、接口、表单页面同步修改。每加一个字段走一遍完整开发流程。

优点：

• 查询性能最好：字段就是普通列，索引、关联、聚合全部原生支持
• 类型约束最严：数据库层面保证类型和完整性，脏数据进不来
• 代码可读性强：字段语义显式存在，新人接手无障碍

缺点：

• 每次都要发版：加字段=改代码+改表+发版，响应速度以周计
• 表越来越宽：低频字段越加越多，宽表维护和性能都是负担
• 多租户场景爆炸：不同租户要不同字段时，物理加列完全不可行

适用场景： 字段需求稳定、变化频率低（一年几次）的核心业务实体。订单、库存这类高频核心表，老老实实用加列，性能比什么都重要。

方案二：EAV 模型（实体-属性-值）

原理： 把字段从"列"变成"行"：属性定义表存字段元数据（字段名、类型、校验规则），属性值表按"实体 ID + 属性 ID + 值"逐行存储。加字段就是往定义表插一行配置，零代码零发版。

优点：

• 灵活性拉满：业务人员自己配置字段，即配即用
• 结构稳定：表结构永不变化，新字段不改表
• 多租户友好：每个租户一套字段配置，物理结构共享

缺点：

• 查询是噩梦：查"信用等级为 A 的客户"要自关联属性表，复杂查询的性能和可读性都堪忧
• 类型约束弱：值通常统一存字符串，类型校验全靠应用层自觉
• 报表生态断裂：BI 工具和报表引擎看不懂 EAV 结构，分析要额外转置

适用场景： 商品属性、设备参数这类"属性集天然多变、查询以实体为中心"的场景。电商商品 SPU 属性是 EAV 的经典主场。

方案三：JSON 扩展字段

原理： 业务表保留一个 JSON 类型的扩展列（如 ext_attrs），自定义字段以键值对存进 JSON；MySQL 5.7+、PostgreSQL 都原生支持 JSON 类型，支持 JSON 路径查询和函数索引。前端配动态表单引擎渲染。

优点：

• 平衡性好：加字段零发版，同时保留数据库级的查询能力（JSON 路径索引）
• 结构灵活：嵌套对象、数组都能存，比 EAV 的表达力强
• 工程成本低：主流 ORM 和数据库原生支持，没有额外的表设计负担

缺点：

• 约束弱于实体列：JSON 内的字段没有数据库级类型约束，校验在应用层
• 索引能力受限：JSON 字段的索引支持不如普通列直接，高频过滤字段不适合放 JSON
• 跨数据库兼容性：各家数据库 JSON 语法差异大，深度使用等于绑定数据库

适用场景： 扩展字段以"展示和辅助筛选"为主、核心查询字段稳定的业务系统。当前企业系统自定义字段的主流务实选择。

按场景对号入座

实战中最重要的经验是分层：高频查询、参与业务规则的字段走实体列；展示型、低频的扩展字段走 JSON；扩展字段一旦被报表和筛选高频使用，就该"固化"升级成实体列。

落地前必做的三件事

第一件：给字段分级立规矩。 哪些字段允许自定义、自定义字段能不能参与工作流和报表、命名规范是什么，写成开发规范。没有规矩的自定义字段，两年后就是数据沼泽。

第二件：元数据管理不能省。 无论哪条路线，自定义字段的定义（名称、类型、来源、谁在用）必须有统一的元数据台账。字段删不掉、不敢删，根源都是没人知道它还被谁用着。

第三件：动态表单和权限一起设计。 加了字段谁能看、谁能改、审计日志怎么记，权限模型要跟上。只解决"能加字段"不解决"字段权限"，等于给数据安全开了后门。

写在最后

动态表单的核心不是"让业务随便加字段"，而是"在灵活性和工程质量之间画出清晰的分层线"。核心字段求稳，扩展字段求活，高频字段及时固化。三条路线各有主场，混着用才是常态——怕的是不分层，一个方案硬扛所有场景。