低代码平台设计：表单 / 流程 / 报表的代码生成

前言

做前端架构的人要不要懂低代码？我的回答是要——不是去实现一个低代码平台，而是建立”什么是低代码的边界”的工程判断。原因有三：

简历里”ERP 半低代码项目”是稀缺经验。低代码不是替代开发,是 80% 通用业务 + 20% 定制开发的工程模式。
低代码不是银弹。过度抽象 = 灵活性丢失——所有需求都想用配置实现 = 业务方配置地狱。
Schema 驱动是低代码的底层逻辑。JSON Schema + JSON Logic + AST 编辑器 = 低代码三大支柱,理解原理比会用 jinja / amis 重要。

这一篇是『前端架构修仙路』的第 26 篇。我跳过具体低代码平台（不教 jinja / amis 怎么用），用架构图 + 设计哲学 + 真实案例，把表单生成 / 流程编排 / 报表配置讲透。下一篇深度聊 RBAC 权限系统。

一、低代码三层抽象

图 1：低代码三层抽象

三层：

Schema 层：JSON Schema 描述长什么样（字段 / 类型 / 校验）
引擎层：Schema 渲染器执行怎么动（JSON Logic 表达式）
业务层：权限 / 流程 / 集成 = 跟业务的接缝

架构师心法：Schema 驱动是底座,业务层是平台核心壁垒。只做 Schema + 引擎 = 通用低代码,做不出商业价值。

二、Schema 驱动的表单生成

// JSON Schema 描述表单
const userFormSchema = {
  type: 'object',
  properties: {
    name: { type: 'string', title: '姓名', minLength: 2, maxLength: 20 },
    email: { type: 'string', format: 'email', title: '邮箱' },
    age: { type: 'number', title: '年龄', minimum: 0, maximum: 150 },
    role: { type: 'string', enum: ['admin', 'user'], title: '角色' },
  },
  required: ['name', 'email'],
};

// 通用渲染器
function FormRenderer({ schema, onSubmit }) {
  const [values, setValues] = useState({});
  
  return (
    <form onSubmit={() => onSubmit(values)}>
      {Object.entries(schema.properties).map(([key, prop]) => (
        <FieldRenderer
          key={key}
          prop={prop}
          value={values[key]}
          onChange={v => setValues({ ...values, [key]: v })}
        />
      ))}
    </form>
  );
}

优势：业务方改 schema 就改 UI,不需要前端开发介入。

三、JSON Logic：可视化表达业务规则

// JSON Logic 表达"当 a > 10 时 b = a * 2"
const rule = {
  if: [{ '>': [{ var: 'a' }, 10] }, { '*': [{ var: 'a' }, 2] }, { var: 'b' }],
};

// 通用执行器
function evaluate(rule, data) {
  if (rule.if) {
    const [cond, then, else_] = rule.if;
    return evaluate(cond, data) ? evaluate(then, data) : evaluate(else_, data);
  }
  if (rule['>']) return evaluate(rule['>'][0], data) > evaluate(rule['>'][1], data);
  if (rule['*']) return evaluate(rule['*'][0], data) * evaluate(rule['*'][1], data);
  if (rule.var) return data[rule.var];
  return rule;
}

生产案例：某 ERP 报销规则”金额 > 5000 需部门总监审批”——业务方拖拽配置 JSON Logic,前端开发零介入。

四、流程编排：可视化 BPMN

// 流程定义（简化的 BPMN 风格)
const processDefinition = {
  id: 'leave-approval',
  nodes: [
    { id: 'start', type: 'start' },
    { id: 'submit', type: 'userTask', assignee: 'employee' },
    { id: 'manager-review', type: 'userTask', assignee: 'manager' },
    { id: 'end', type: 'end' },
  ],
  edges: [
    { from: 'start', to: 'submit' },
    { from: 'submit', to: 'manager-review', condition: 'days <= 3' },
    { from: 'manager-review', to: 'end' },
  ],
};

// 通用执行器:状态机推进
async function executeProcess(processDef, currentNode, context) {
  const next = processDef.edges.find(e => e.from === currentNode);
  if (!next) return;
  if (next.condition && !evaluate(next.condition, context)) return;
  await executeNode(processDef.nodes.find(n => n.id === next.to), context);
  return executeProcess(processDef, next.to, context);
}

架构师心法：流程引擎 = 状态机 + JSON Logic——业务方拖拽 = 配 schema 和 condition,前端开发只写 UI 节点。

五、报表拖拽式配置

// 报表配置
const reportConfig = {
  dataSource: {
    type: 'api',
    url: '/api/sales',
  },
  dimensions: ['region', 'product'],
  measures: [{ field: 'amount', agg: 'sum' }],
  chartType: 'bar',
  // ...
};

// 通用渲染器
function ReportRenderer({ config }) {
  // 调用 ECharts / Recharts
  // 套通用样式
  return <Chart options={buildEChartsOption(config)} />;
}

生产案例：ERP 半低代码项目,业务方拖拽配置 200+ 报表,前端只做通用渲染器——节省 80% 报表开发人力。

六、踩坑提醒（资深架构师请重点看）

不要试图让低代码覆盖 100% 需求。20% 复杂需求永远要”逃生口”——支持业务方写 custom code 而不是限制只能用配置。
不要把 schema 设计得过于灵活。Schema 越灵活 = 越难调试。限制 schema 字段 / 类型 / 校验 = 业务方更不容易出错。
不要在低代码里做权限控制。权限是业务层——低代码做的是 UI 生成,权限用 RBAC 独立系统。
不要忽视低代码平台的性能。渲染 100 个 schema 字段 vs 写死的 React 组件,前者可能慢 10 倍。虚拟滚动 / 懒加载必须考虑。
不要做”大而全”的低代码平台。80% 业务用 schema + JSON Logic 解决,20% 写 custom code——架构师职责是设计边界。

总结

这一篇用 5 个关键事实把低代码平台串起来：

三层抽象:Schema 层 (JSON Schema) + 引擎层 (JSON Logic) + 业务层 (权限 / 流程 / 集成)。
Schema 驱动表单:业务方改 schema 就改 UI,前端开发零介入。
JSON Logic 业务规则:可视化拖拽配置”当 X 时 Y”,规则即数据。
流程编排:BPMN 风格流程图 + 状态机执行,业务方设计流程。
报表配置:拖拽 dimensions / measures / chartType,通用渲染器。

下一篇:RBAC 权限系统——动态路由 / OAuth 2.0 / JWT,SSO 统一权限项目实战。

5 道重点面试问题方向

Q1(答案):低代码平台的核心抽象层是什么?为什么 Schema 驱动是关键?

A:三层抽象:① Schema 层 — JSON Schema 描述「长什么样」(字段 / 类型 / 校验);② 引擎层 — 渲染器 + JSON Logic 执行「怎么动」;③ 业务层 — 权限 / 流程 / 集成 = 业务接缝。为什么 Schema 驱动关键:业务方改 Schema 就改 UI / 流程 / 报表,前端开发零介入——80% 通用业务由业务方自己配,20% 定制需求前端写代码。不是替代开发,是减少重复开发。

Q2(思考):JSON Logic 是什么?为什么业务规则用 JSON Logic 而不是写 JS 代码?

A:JSON Logic 是数据驱动的业务规则表达格式,用 JSON 对象表示「if a > 10 then b = a * 2」的规则。为什么用 JSON Logic:① 可视化拖拽 — 业务方拖拽节点生成 JSON,不需要懂 JS;② 可序列化 — 规则存数据库,版本化 / 灰度;③ 执行器通用 — 写一次 evaluate 函数适用所有规则;④ 业务方能改 — 改 JSON 不需要发版。反例:某团队把规则写 JS,业务方每次改需求都让前端发版,效率极低。

Q3(思考):低代码平台和传统开发的边界在哪里?哪些需求必须用代码不能用配置?

A:80/20 边界:80% 通用业务(表单 / 列表 / 流程 / 报表)→ 低代码配置;20% 复杂需求(复杂交互 / 定制动画 / 性能敏感 / 深度业务逻辑)→ 写代码。必须用代码的场景:① 复杂交互（如 FinSpread 表格单元格编辑);② 性能敏感（如大表格虚拟滚动);③ 深度业务逻辑（如多步骤业务编排);④ 集成复杂（对接硬件 / 老系统);⑤ 体验极致（动画 / 3D)。架构师职责:设计逃生口——低代码平台留「custom code」区域,业务方在低代码 + 写代码之间自由切换。

Q4(思考):低代码平台的性能瓶颈是什么?Schema 渲染怎么避免卡顿?

A:三大性能瓶颈:① Schema 解析慢 — 100 个字段的 schema 解析 200ms,需用流式解析;② 渲染字段多 — 100 个 React 组件 mount 慢,需用虚拟滚动 / 懒加载;③ JSON Logic 表达复杂规则 — 嵌套深的 if/else 跑 100ms,需编译为 AST 一次 + 重复执行。生产案例:某表单 200 字段,初次渲染 1.5s,优化后（字段分组 + 懒加载 + 预编译 rule)→ 200ms。

Q5(思考):你在 ERP 半低代码项目里是怎么平衡「低代码覆盖度」和「代码灵活度」的?业务方 vs 开发的协作模式是什么?

A:半低代码 80/20 原则:80% 通用业务(表单 / 列表 / 审批 / 报表)→ 业务方低代码配置;20% 定制需求→ 写代码。协作模式:① 业务方有 schema 配置权——表单字段 / 列表列 / 审批流 / 报表都自己配;② 开发有代码接缝——/src/custom/ 目录业务方可以挂自定义 React 组件;③ 灰度发布 — schema 改动有版本,业务方选版本回滚;④ 培训 — 给业务方 3 天低代码培训,会改 schema 不用懂代码。效果:200+ 报表 80% 业务方配置,前端只做 20% 复杂报表,节省 60% 报表开发人力,需求交付周期 -60%。

💡 每道题后面都有 AI 助手按钮,一键拿到详细答案。

参考资料

JSON Schema (Official) — JSON Schema 官方规范
JSON Logic (GitHub) — JSON Logic 规则引擎
amis (GitHub) — 百度 amis 低代码框架
formily (GitHub) — 阿里 Formily 表单方案
bpmn.io — BPMN.io 流程建模工具
Low-Code Engine (GitHub) — 阿里低代码引擎

前言