低代码平台的原理与边界

低代码的本质是「把页面结构变成数据」。它适合变化频繁但复杂度可控的场景，不是万能的页面生成器。

一、Schema、渲染器与编辑器

任何低代码平台都由三块组成：Schema（用数据描述界面与逻辑）、渲染器（把 schema 解释成真实界面）、物料协议（组件能被描述的最小契约：有哪些属性、属性类型、默认值、可嵌套什么）。缺了第三件，物料就是各写各的，平台无法统一描述；缺了第一件，就没法保存与版本化。

理解这三件的关系，就能理解低代码难在哪：Schema 是「写什么」，渲染器是「怎么跑」，物料协议决定了「能写什么」。平台的能力上限，由物料协议定，而不由画布定。

图：编辑器产出 Schema、渲染器消费 Schema，能力上限由 Schema 的表达力决定

二、拖拽与撤销栈

画布经常被认为是难点，其实拖拽本身不难，坐标换算才是基础。拖出来的元素要能精确落到画布上的某个位置，需要从指针事件的客户端坐标减掉画布容器的偏移，再除以缩放比。缩放与网格吸附、多选与层级管理，都是建立在这个换算之上的增强。

function toCanvasPoint(e, container, scale) {
  const rect = container.getBoundingClientRect()
  // 客户端坐标减去容器偏移，再除以缩放比，得到画布内坐标
  return {
    x: (e.clientX - rect.left) / scale,
    y: (e.clientY - rect.top) / scale,
  }
}

连线类编排（流程图、依赖图）更适合用 Canvas（ZRender / Fabric 一类）来画，因为节点多、关系密，DOM 的层叠与重排会成为瓶颈；而普通表单、列表类画布用 DOM 更贴近真实渲染效果，所见即所得。选 DOM 还是 Canvas，看的是「画的是图结构还是组件树」。

三、协议设计决定上限

Schema 是平台的核心资产，必须可 diff、可版本化、可迁移。版本化不是加个字段那么简单——旧数据升级时必须兼容，不能因为平台升了一版就打不开历史页面。另一个常见错误是把渲染逻辑写进 schema：schema 应该只描述「结构与属性」，渲染交给渲染器，否则同一份 schema 在不同端表现会不一致。

// 带版本与迁移思路的 schema
{
  "version": 2,
  "components": [
    { "type": "Input", "props": { "label": "姓名", "required": true } }
  ]
}

// 版本迁移：v1 的字段名变化到 v2，旧数据自动升级
function migrate(schema) {
  if (schema.version === 1) {
    schema.components.forEach((c) => {
      if (c.type === 'Field') c.type = 'Input' // 旧类型名 -> 新类型名
    })
    schema.version = 2
  }
  return schema
}

四、复杂度天花板

低代码擅长的是结构稳定、交互简单、批量重复的界面：表单、列表、增删改查、审批流。它不擅长的是强交互（拖拽编辑、实时协同）、复杂动效、高性能渲染、以及需要精细控制像素与时序的页面。判断标准不是「页面复杂不复杂」，而是这套界面能不能被一套有限的 schema 完整描述——描述不了的部分每多一个，平台就要多一个逃生舱，代价迅速超过收益。

逃生舱（让业务方能在平台外扩展）要提前设计，而不是等平台不够用时才补。没有逃生舱的平台，业务方最终会绕开它，回到手写代码，平台的统一性就破了。

现实里更稳的姿态是「低代码 + 原生」混合：标准 CRUD、表单、审批流用平台，核心算法、高性能渲染、深度定制部分回到代码。判断那根线的不是技术偏好，而是「这部分如果平台做不了，绕开的代价是否小于手写的代价」——小于，就别硬塞进 schema。

schema 的版本迁移是真正的长期成本，读取时迁移而不是要求旧数据一起改：

function migrate(page) {
  let v = page.version ?? 1
  if (v === 1) {
    // 新增字段给默认值，旧页面不用改
    page.props.size ??= 'md'
    v = 2
  }
  if (v === 2) {
    // 字段改名：搬过去，保留旧值一段时间便于回滚
    page.props.title ??= page.props.label
    delete page.props.label
    v = 3
  }
  return { ...page, version: v }
}

五、做成配置地狱的几种情况

schema 越加越像一门新语言：为了覆盖 edge case 不断加配置项，最后比写代码还难用，还没人愿意学。
运行时性能失控：把所有状态都塞进 schema 驱动的运行时，复杂页面一多就卡。
出码与运行时两套不一致：同时支持「导出代码」和「运行时渲染」时，两套实现必然产生行为差异，要先确定主路线，另一套只是补充。
厂商锁定与影子 IT：业务方用平台自建应用若没有统一治理，会产生大量未经安全审计的「影子 IT」；平台停服、涨价或改路线时迁移成本极高。选型时优先支持私有化部署与代码导出的平台，把逃生舱从「能扩展」升级到「能带走」。

这些失败往往不是技术不行，而是目标定太大——想用一套 schema 描述所有页面。

协议能表达什么，决定了平台上限。一个最小 schema 大概长这样：

{
  "version": 3,
  "root": {
    "type": "Container",
    "props": { "layout": "vertical", "gap": 12 },
    "children": [
      { "type": "Text", "props": { "content": "订单详情", "size": "lg" } },
      { "type": "Table", "props": { "bind": "state.orders", "columns": ["id", "amount"] } }
    ]
  }
}

六、它什么都能生成是个错觉

低代码替代不了前端，它替代的是「重复的增删改查界面」，物料与平台本身仍然要前端开发。

schema 也不是越灵活越好——灵活到能写逻辑时，它就变成了一门没人愿意学的新语言。

出码和运行时渲染更不可能同时做到完美，两套实现必然产生一致性问题，要先确定主路线。

边界感是低代码能不能落地的关键：知道它不做什么，比知道它能做什么更重要。

schema 驱动这条路能走多远，很大程度取决于描述能力，JSON Schema 就是那套最常被拿来用的描述语言。

一、Schema、渲染器与编辑器​

二、拖拽与撤销栈​

三、协议设计决定上限​

四、复杂度天花板​

五、做成配置地狱的几种情况​