低代码平台这两年几乎成了企业软件领域的“标配话题”打开技术社区看到的是各种拖拉拽做表单的demo厂商宣传的也都是“不用写代码”“业务人员自己搭系统”。但真正深入做过低代码平台的人都知道那层光鲜的可视化界面只是冰山一角。一个能支撑真实业务、敢让开发团队托管给业务方使用的低代码平台其技术内核远不止“画页面”这么简单它本质上是一套**“构建能力”与“运行治理”并存的双层结构**。这篇文章我想把这些年在低代码平台设计、落地和踩坑过程中的思考做一个系统梳理聊清楚这两层到底是干什么的、它们如何协同、以及为什么只关注任何一层都做不出真正好用的低代码平台。不是所有人都需要看懂这篇。如果你只是用现成平台搭几个表单那没必要往下读。但如果你是技术负责人、后端架构师、前端中后台团队的骨干或者正在调研“要不要自研低代码”“该选哪个开源方案”那这篇值得你花十分钟认真看完。我们会从架构视角切入拆解构建层如何把业务需求翻译成结构化表达运行层如何让这些表达变成稳定可用的生产系统再配合一些我在实际项目中遇到的典型问题希望能帮你建立一套判断低代码平台好坏的方法论。1. 低代码平台的“双层结构”到底是什么先理清整体作战图1.1 低代码的本质从“写代码”到“描述系统”很多团队第一次接触低代码是被它的可视化拖拽界面吸引的左侧一个组件库中间一个画布右侧属性面板拖拖拽拽就能出一个界面。这个体验确实很爽但它只是低代码的表层能力。如果只停留在“拖控件、调属性”这个层面那跟用PPT画原型没多大区别。低代码真正厉害的地方在于它在“人机对话”的层面做了一次根本性转换。传统开发模式下需求要变成代码代码经过编译构建变成可运行的程序而在低代码模式下你通过拖拽和配置生成的东西并不是一段可直接运行的代码而是一份结构化的应用描述。这份描述可以用JSON存储、可以进数据库、可以走版本管理然后由另一套引擎在运行时把它解释、渲染、执行成用户真正能用的页面和接口。这就是双层结构的起点构建能力层负责“表达”运行治理层负责“执行”。前者解决的是“我怎么把需要的东西描述出来”的问题后者解决的是“描述出来的东西怎么稳定跑起来”的问题。1.2 构建层与运行层一对容易混淆却必须解耦的孪生体我在和很多开发者交流时发现大家最容易犯的错误就是把这两层混为一谈。有人以为低代码平台就是把设计器做得够好用做完设计器就大功告成了也有人以为低代码就是运行时拿到一段JSON渲染出来忽略掉构建过程对Schema质量的影响。实际上这两层各有各的核心命题。我做一个对照维度构建能力层设计态运行治理层运行态核心目标降低表达门槛让配置者高效产出保障可靠性让应用稳定服务用户主要用户业务人员、实施人员、低代码开发者终端用户、运维人员、平台管理员核心产物应用Schema、组件资产、数据绑定关系渲染实例、权限策略、发布版本、运行日志关键指标配置效率、组件丰富度、易用性渲染性能、稳定性、安全性、可治理性典型技术可视化编辑器、Schema设计器、表达式引擎Schema解释器、权限引擎、版本控制、监控体系这两层必须解耦原因有几个。第一设计器的迭代节奏和运行时引擎完全不同界面交互改版可以高频进行但运行时引擎的升级必须谨慎再谨慎牵一发动全身第二构建层可以随时替换设计器实现比如从React版换到Vue版只要输出的Schema标准不变运行层完全不受影响第三只有运行层足够健壮低代码产出的应用才能被纳入企业级IT治理体系否则业务部门用得很嗨运维和安全部门看了直摇头。我可以用一个比较生活化的类比构建能力层像作曲家写乐谱运行治理层像乐团按乐谱演奏。作曲家用符号把旋律记录下来乐手们照着符号演奏。乐谱记法可以升级指挥可以更换但最终决定音乐会好不好听的既有乐谱本身的质量也有乐团执行力。一个低代码平台的含金量恰恰体现在这两方面是不是都在水准之上。2. 构建能力层拆解设计器和可视化建模背后的技术内幕2.1 画布、组件树、属性面板设计器三件套的底层逻辑几乎所有低代码设计器都逃不过“组件库-画布-属性面板”这个经典布局。很多人觉得这只是UI设计习惯实则不然这三个区域对应的正是构建能力层最核心的三个子系统组件资产系统、可视化编辑内核、Schema生成器。组件资产系统管理着平台所有可拖拽的组件。我在实际落地中发现组件库一定不能是扁平的它至少要分成三层原子组件是最基础的Input、Select、Button这类业务组件是封装好的业务单元比如“客户选择器”“订单状态标签”它们内部可能组合了多个原子组件并且预置了数据请求逻辑模板组件则是更粗粒度的页面级积木比如“标准查询表单”“详情页布局”。分层的意义在于原子组件保证灵活性业务组件提升配置效率模板组件让新手也能快速起步三者的比例需要根据目标用户来调配。可视化编辑内核承担的是对画布内容的增删改查和撤销重做。拖拽一个组件进来本质上是往组件树里插入一个节点拖动调整位置本质是改变节点的层级或顺序。这些操作背后是一个标准的操作栈每一步操作都封装成命令对象支持undo/redo。这块要是没做好设计器会非常难用。我建议在架构设计时所有对组件树的操作必须走统一的数据变更接口绝不允许组件直接修改全局树否则撤销重做、快照保存都会失控。属性面板是连接界面操作和Schema的桥梁。你选中画布上的组件时属性面板要动态展示这个组件可配置的属性。这里的技术关键是“Schema驱动表单渲染属性面板”每个组件在注册时附带一份属性声明声明它有哪些属性、每个属性的类型是什么、取值范围是什么属性面板拿到这份声明自动生成编辑控件。这样一来新增组件不用改设计器代码只要注册元信息就行这是组件生态能否扩展的基石。2.2 属性绑定与数据源配置组件和真实业务接轨的关键环节光把组件拖上去只是搭了个空壳真正的业务逻辑是从“属性绑定”开始的。我见过不少低代码平台的失败案例共同点都是组件看起来很丰富但属性只能写死静态值一遇到动态数据就抓瞎。一个合格的构建层必须支持属性值的多种来源。最简单的来源是静态值直接写死其次是数据源绑定属性值从某个API接口、数据库表或全局变量中获取再高级一点的是表达式绑定属性值由一段表达式动态计算得出比如根据当前登录人的角色控制某个字段是否只读。数据源配置本身也是一个不小的工程。我推荐平台核心维护一个“数据源管理器”统一管理API地址、请求参数、返回结构映射和缓存策略。在实际业务中常见的数据源类型我梳理了这样几类API接口数据源最通用支持RESTful接口可配置GET/POST、Header、请求体数据库表数据源平台直连数据库通过元数据自动生成查询、插入、更新能力适合内部管理类系统页面上下文数据源来自页面内其他组件的选中项、表单提交结果等全局共享数据源登录用户信息、系统配置参数、字典数据这里有一个特别容易踩的坑数据返回结构和组件期望结构不一致。最稳妥的做法是平台为每个数据源配置“映射关系”例如接口返回的是{ code: 0, data: { list: [...] } }下拉框组件期望的是[{ label: xx, value: 1 }]构建层需要允许配置提取路径和字段映射而不是要求开发人员去改接口。表达式引擎也是构建层一个需要投入技术力量的点。字段联动A选了什么B显示什么、表单校验规则、按钮显隐控制这些动态逻辑都依赖表达式引擎。表达式引擎的选型有几个方向小体量场景可以自己写一个安全的eval沙箱但更推荐直接集成成熟方案比如expr-eval这类轻量级求值库在构建层生成AST再在运行层执行。表达式一定要在构建层做语法校验和上下文提示否则业务人员配置时写错了等到运行时才报错体验会很崩溃。2.3 表单搭建低代码的第一战场为什么是表单行业里有个共识低代码平台最先做好的往往是表单能力因为中后台管理系统几乎一半以上的页面是“表单列表详情”的组合。标题里提到的“通过拖拉拽的方式创建表单”这是用户感知最强、最能评判一个低代码平台功底的功能。表单搭建看着简单深挖下去坑很多。一个表单要从拖拽字段变成可提交的完整功能至少要处理这么几件事字段模型的定义。每个表单字段要有统一的模型字段标识name、显示标签label、组件类型type、属性配置props、校验规则validation、初始值initialValue、联动规则displayRule、disableRule等。这个模型直接决定了后面渲染器怎么工作。布局能力。真实业务中表单不是简单从上到下排列的需要有多行多列、分组卡片、选项卡乃至动态增删行子表单。这要求构建层有一套布局渲染方案通常是栅格系统加容器组件容器内部承载字段。校验逻辑的配置。必填、长度限制、格式校验是基本能力更复杂的是跨字段校验比如“结束时间必须晚于开始时间”。这类校验单独写在字段上是不行的必须支持表单级校验表达式。我在做过一个排期管理应用时就是靠表单级校验表达式解决了资源冲突提示的问题。提交逻辑。字段数据收集完成后提交到哪里、用什么格式、成功后跳转还是弹窗这些也要在构建层配置清楚。提交动作可以是一个API请求、一个导出任务甚至可以触发一个工作流。联动逻辑的编排。字段之间的显隐、禁用、取值联动我建议做成“规则列表”让配置者可视化维护而不是让他写大段表达式。比如“当部门类型等于技术部时显示技术等级字段”这种规则前后端各存一份构建层存规则定义运行层存规则引擎。设计器做得好的表单搭建会让业务人员觉得“比Excel高级但又不比Excel难多少”。如果做出来需要理解一堆技术概念那说明构建层的抽象还没到位。判断标准很简单让一个完全不懂代码的运营同事去搭一个带联动校验的报名表单看看他能不能在半小时内完成过程中需要向开发求助几次。3. 运行治理层拆解低代码应用在生产环境“跑得稳”的关键3.1 运行时引擎Schema解释器如何把描述变成真实界面构建层产出的Schema只是一堆JSON真正让用户看到界面的是运行时引擎。这个引擎的核心是一个Schema解释器它拿到Schema后做三件事解析、实例化、渲染。解析阶段引擎遍历Schema里的节点树根据每个节点的组件类型去组件注册表里找到对应的渲染组件。这一步如果发现未注册的组件类型就会走异常兜底逻辑否则整个页面都会白屏。所以组件注册表的设计至关重要它是一个全局映射表Map的key是Schema里的组件类型字符串value是组件工厂函数。实例化阶段引擎根据Schema里的props配置、数据源绑定和表达式规则计算出组件实际接收的props。这里要注意一个问题绑定和表达式的计算时机。有的属性在页面加载时就要确定有的属性则依赖用户交互动态变化。一个成熟的低代码运行时需要内置依赖追踪机制比如当字段A的值变化时自动触发字段B可见性和取值表达式的重算。我遇到过很多实现简陋的平台联动逻辑要手动刷新才生效就是因为没有做响应式依赖管理。渲染阶段引擎递归渲染整棵组件树同时处理布局容器、表单状态、路由切换等逻辑。这里需要考虑的不仅是界面展示还有周边配套错误边界、加载状态、空数据占位、组件懒加载等。状态管理是运行时引擎绕不开的话题。一个低代码页面通常有几类状态同时存在页面内临时状态比如搜索表单当前值、跨组件共享状态比如列表页选中了哪一行、服务端状态来自接口的数据。坦白讲现在不少低代码平台的运行时在状态管理上是比较粗糙的直接拿全局store存所有东西导致内存泄漏和性能问题。我的建议是运行时引擎要区分临时状态和共享状态临时状态尽量放在组件内部共享状态才进入全局store并且要有明确的清理策略。3.2 权限与多租户运行层的第一道安全闸门一个低代码应用如果只能“跑起来”但管不住“谁能用什么”那它永远进不了企业正式环境。运行治理层必须包含一套完整的权限体系。我通常把它拆成三个层级页面级权限控制谁能访问哪个页面。实现方式一般是路由守卫用户在跳转时校验是否有对应页面的权限码。页面权限通常是静态的用户登录后拿到角色角色映射到菜单权限渲染路由时直接过滤。操作级权限控制页面里的按钮、操作是否可见或可用。比如“新增”“删除”“导出”这些按钮同一页面不同角色看到的状态不同。这类权限适合在运行时注入一个权限上下文按钮组件通过权限指令或Hook判断当前用户是否有某个操作权限。比较麻烦的是很多平台只做了初始化判断用户角色在会话内变化了没有动态刷新导致权限状态不一致。数据级权限是门槛最高的控制你能看到哪些数据行、哪些字段。比如销售只能看自己的订单、部门主管能看整个部门的订单。这类权限必须前后端配合前端负责展示层的控制比如隐藏某些敏感列后端负责真正的数据过滤。很多低代码平台在这一层偷懒结果就是前端按钮隐藏了但直接调接口还是能拿到全部数据。多租户隔离也是运行治理层的高频需求。SaaS模式的低代码平台要让不同租户的数据互不可见常见实现方式有独立库、共享库独立Schema、共享表加租户ID过滤三种。低代码场景大多数用第三种因为它能复用一套运行引擎但必须在数据源的查询层统一注入租户条件绝对不能依赖各业务系统自己加条件否则漏一个就是数据事故。3.3 版本管理与发布机制低代码应用的“安全气囊”传统开发有Git分支、CI/CD流水线、灰度发布机制低代码应用在这个层面也不能裸奔。任何一个能进入正式环境的低代码平台必须有完善的版本管理和发布机制。设计器的每一次保存本质上都是在保存应用Schema的一个新版本。我在实际项目里通常会让平台记录Schema的完整快照并附带操作者、操作时间、变更说明。为什么是完整快照而不是增量补丁因为Schema的变更维度太复杂增量补丁的解析成本高、出错率也高快照存储的成本在JSON场景下完全可接受回滚也最简单直接。有了版本快照发布机制就顺理成章了。一般流程是编辑态草稿→ 测试态预览验证→ 正式态生产可用。每一个环境对应Schema的不同版本测试态可以随意发布正式态必须经由有权限的人确认。发布动作要把这份Schema打包成正式版本同步生成带版本号的静态资源引用方便CDN和浏览器缓存做指纹管理。出问题时一键回滚到上一个正式版本是必备能力。在大型组织里还需要考虑应用的灰度发布先让一部分用户看到新版本观察监控指标再全量放开。低代码平台的灰度实现可以在运行网关层做分流比如按用户ID哈希、按部门维度让不同用户路由到不同版本的Schema上这样极大降低了发布风险。3.4 监控、日志与审计运行治理层最后一块拼图许多低代码平台在功能上做得很炫可一谈到监控运维就露怯。可真正常年维护低代码平台的团队都知道没有可观测性的低代码系统就是一座黑箱出了问题只能靠用户截图反馈排查效率极低。运行治理层至少要覆盖几类可观测数据。性能指标包括页面首屏渲染耗时、组件加载耗时、接口响应耗时、资源加载成功率。由于低代码页面是动态渲染的渲染性能天然比硬编码页面差一些所以更需要监控数据说话帮助定位到底是哪类组件拖慢了整体速度。错误监控要捕获JavaScript异常、接口请求错误、Promise未处理的rejection并且把错误信息关联到具体的Schema版本和组件节点这样开发才能在“某某页面的某某组件出错”这个粒度上定位问题而不是面对一条孤零零的堆栈。操作审计是另一个容易被忽略的点。企业合规要求越来越严谁能改哪个应用、什么时间改的、改动前后差异是什么这些关键信息必须有记录。我做过一个项目审计日志不是锦上添花而是客户采购平台的前置条件。所以运行治理层要提供操作日志的查询和导出能力最好能把Schema的版本diff友好地展示出来解决“谁动了我的应用”这种典型的甩锅现场。4. 构建产物如何变成运行实例Schema与发布链路的完整闭环4.1 一份表单Schema的前世今生理解了构建层和运行治理层各自的职责我们再把目光拉回到两层之间的关键介质Schema。Schema就是整个平台的“通用语言”构建层负责生成它运行层负责消费它。我直接给一个简化但真实的表单Schema示例大家感受一下它长什么样。{ id: frm_employee, name: employeeForm, version: 1.0.0, layout: { type: Grid, columns: 2, padding: 16 }, fields: [ { name: name, label: 员工姓名, type: Input, props: { placeholder: 请输入姓名 }, validation: [ { type: required, message: 员工姓名不能为空 }, { type: maxLength, value: 20 } ], initialValue: }, { name: department, label: 所属部门, type: Select, props: { optionsSource: { type: api, url: /api/departments, method: GET, mapping: { label: name, value: id } } }, validation: [ { type: required, message: 请选择所属部门 } ] }, { name: manager, label: 直属主管, type: Input, props: { placeholder: 请选择直属主管 }, displayRule: { type: expression, expr: this.department ! this.department ! undefined } } ], submitAction: { type: api, url: /api/employees, method: POST, successMessage: 新增成功, afterAction: { type: navigate, target: /employee/list } } }这份Schema包含了表单最核心的要素字段结构、组件类型、属性配置、校验规则、初始值、字段间联动规则、提交动作。在构建层用户看到的是一个漂亮的表单设计界面存储层这份JSON被保存在数据库里运行层渲染引擎拿到它遍历字段列表逐项映射到实际组件绑定校验和联动逻辑最终在浏览器里渲染出可交互的表单界面。这个示例还反映出一个重要的设计原则Schema必须可逆。意思是构建层能用Schema渲染出设计界面运行层能用同一份Schema渲染出真实界面两边对Schema的理解必须完全一致。如果出现“配置时看到的效果和运行时不一致”那基本上就是Schema定义本身存在歧义或是两层实现有偏差。4.2 发布流水线Schema如何从“草稿”变成“正式”从构建层到运行层的完整链路可以抽象成一条发布流水线我用五步来概括。第一步是构建产物生成。用户点了保存设计器把当前画布内容序列化成为Schema同时把这个Schema依赖的组件资源清单、静态资源版本、API依赖列表等元信息一起做成一个产物包。产物包是应用发布的最小单元。第二步是环境准入。构建产物包先进入测试环境在这里Schema可以被预览、联调。测试环境可以通过模拟账号、模拟数据来验证确保Schema本身没有语法错误、没有引用不存在的组件。自动化检查也可以在这个环节跑比如校验必填的字段、校验表单提交地址是否可访问等。第三步是审批发布。正式环境发布前需要经过配置了审批流程的负责人在平台点击确认。我所在的项目里这块特意对接了企业IM审批通知避免“有人悄悄把一个还在开发中的表单发布到生产环境”这种事故。第四步是运行加载。正式环境接收到发布指令后把Schema写入应用的正式版本表同时触发缓存预热。运行服务侧的渲染接口开始为这份Schema服务当终端用户访问时从正式版本表读取Schema交给渲染引擎。第五步是反馈与治理。应用上线后运行监控体系开始采集性能数据、错误日志和用户行为这些数据流回运行治理层。如果发现异常管理员可以一键回滚到旧版本整个过程不需要改一行代码。4.3 热门开源低代码方案在双层结构上的典型实现差异目前开源社区里低代码方案很多如果从双层结构的视角去审视它们会发现各家对两层边界的理解不同落地方式也大相径庭。amis是百度开源的低代码方案核心特点是Schema直出。开发者写一份JSON配置amis运行时直接渲染成可用的后台页面它在运行层的解释能力非常强内置了大量组件和交互规则。但它的构建层主要靠手写或简易编辑器没有很重的可视化拖拽设计器这反而让它ER稳定。适用场景是“开发者用低代码语法提升开发效率”典型定位是配置化开发框架而不是给业务人员用的无代码平台。Formily是阿里的表单解决方案它的核心是表单领域模型。formily/core负责维护表单状态机formily/react和formily/vue负责绑定组件渲染Schema是描述表单结构的标准协议。Formily的双层结构更偏底层构建层和运行层没有完整封装需要开发者自己拼装但它的表达能力和扩展性非常强。如果你在一个技术团队内自研低代码平台Formily的Schema协议和状态管理模型值得认真研究。LowCodeEngine是阿里开源的低代码引擎这在“构建能力与运行治理双层分离”上做得比较彻底。它定义了资产包来描述组件设计器负责生成Schema渲染器负责消费Schema两边的协议可以独立升级。组件资产、插件机制、出码机制都是围绕“构建和运行解耦”来设计的。它更像一个引擎而不是成套的最终产品二次开发的工程量和门槛都不低。Appsmith则是另一个流派更偏向业务应用平台。它把“页面搭建、数据源连接、查询管理”整合得比较好表单只需要选择数据源它自动生成查询和提交逻辑。构建层和使用者的业务场景贴得很近但运行治理层的灵活性就相对没那么高。我做了一张表方便大家直接对比方案构建层形态运行层复杂度适合场景amis配置式JSON弱拖拽高解释能力强开发者快速搭建后台系统Formily框架级协议需自行封装中表单模型强大自研表单引擎、复杂表单场景LowCodeEngine完整可视化设计器引擎高协议标准化技术团队基于它做企业级低代码平台Appsmith可视化拖拽数据源集成中开箱即用内部工具快速搭建、数据面板理解这些差异之后你就知道市面上的低代码产品不是在同一个维度上竞争。有的在构建层做到极致适合业务人员自助有的在运行治理层做得细致适合被集成进企业技术体系。你拿“能否拖拽出表单”来横向比较就会把很多有含金量的能力给忽略掉。5. 低代码实战中常见的坑与排查思路实录5.1 页面渲染白屏或组件不显示从哪入手排查低代码应用白屏绝大多数问题出在Schema无法被运行时正确解释。我遇到过的典型原因有这样几类第一Schema里写了一个组件类型但组件注册表里根本没有对应组件尤其常见于跨环境发布后新组件没有同步注册到生产环境第二Schema版本和运行时渲染器版本不兼容比如之前的版本用了display: hidden表达新版本协议改成了displayRule.hidden第三接口数据异常导致渲染中断某个字段初始化时直接抛错整个页面挂了。排查思路其实不复杂。先打开浏览器控制台看是否有报错堆栈有报错就先看报错信息指向哪个组件再看Network面板确认Schema请求和依赖的静态资源是否都成功加载最后检查运行时组件注册表里到底注册了哪些组件。为这个场景我建议平台内置一个“Schema诊断工具”在预览态直接给出Schema里每个节点的解析状态是成功、警告还是失败并指出具体是哪个字段、哪种原因导致的能大幅减少这种基础问题的沟通成本。5.2 配置了数据绑定但不生效通常是路径或时机问题属性绑定了数据源但界面上就是不显示这类问题排第二实至名归。最常见的坑是数据路径写错了。运行时从接口返回的数据结构里提取值用的是类似data.list[0].name的路径表达式但接口返回的实际结构和配置时预期的结构经过了嵌套包装比如多了个data包裹层路径就直接指向了undefined。另一个常见问题是异步时序。页面加载时组件先以初始状态渲染了一次接口数据返回后没有触发该组件的重新渲染导致绑定看起来“没生效”。这个问题在Formily体系里其实解决得很好它的模型层会处理响应式依赖但在自研实现里很容易被忽略。我的建议是运行时引擎里每个组件的数据属性绑定必须经过统一的Connect机制由该机制负责订阅数据源变化变化后自动更新组件props。不要在组件内部自己拉数据否则这种问题会反复出现。调试这个问题时我通常会在运行时面板里展示每个数据绑定节点的“最终计算值”打开这个面板一眼就能看出到底绑定到了什么、路径是否有值、表达式的计算结果是什么比起瞎猜要快得多。5.3 权限策略生效但不彻底前端隐藏不等于安全低代码应用权限问题最能体现“运行治理”的价值。很多平台做了页面级权限菜单里看不到某个页面了团队就以为权限做完了。可实际渗透测试一打直接构造URL访问那个页面的地址照样能打开。这就是典型的只做了前端路由守卫、没有做接口级校验。权限问题必须遵循一个铁律前端控制是体验后端控制才是安全。低代码平台要在运行层的API网关上统一做权限校验而不是依赖各个业务接口自己判断。具体来说页面访问要校验页面权限码接口调用要校验接口权限码数据返回要在查询层注入数据权限条件。按钮级别的显隐只能作为体验优化不能作为安全边界。我在排查权限问题时常见情况是“角色配置正确、权限码也配了但还是越权”。这种情况往看权限是快照缓存导致的用户登录后角色信息被缓存管理员调整了用户角色但用户会话刷新前不会生效。解决思路是每次请求都从token中解析角色和权限集合或者设置一个极短的权限缓存TTL并且提供强制的“刷新权限”机制。5.4 表单字段一多页面就卡性能瓶颈往往在渲染层低代码表单的性能问题是用户体感最直接的痛点。一个表单十几个字段就开始卡顿在低代码平台里很常见根因通常是整树重渲染。用户每次输入一个字符整个表单组件树都被重新渲染了一遍几十个字段全部参与diff性能自然就崩了。解决的第一个策略是字段级渲染隔离。让每个字段组件自己管理自己的值状态只在自身值变化时更新自身不要把整个表单的值变化都广播到所有字段。Formily在这一点上用memo和响应式依赖做得很好值得参考。第二个策略是表达式按需计算。字段联动表达式如果依赖链路很长每次值变化把所有表达式全部重算一遍也是灾难。要建立依赖图只计算受影响的表达式而不是全量计算。第三个策略是大数据量场景的虚拟化。下拉框选项有成百上千条时一定要用虚拟列表或按需搜索不要一次性把所有选项渲染到DOM上。我做过一个选人组件全公司几千号人都在下拉里不用虚拟列表直接卡死换成远程搜索加虚拟滚动后体验完全不一样。最后再说几句实际体会做了几年低代码平台我的核心体会是永远先想清楚运行治理层再去做构建能力层。很多团队自研低代码一上来就投入大量精力做拖拽设计器界面做得很华丽可一到权限、版本、监控这些“不性感”的地方就没有下文了。结果平台只能在demo里玩玩根本扛不住真实业务。如果你现在正处于低代码平台的选型阶段我建议你用文中这套双层结构去做个快速的体检先问构建层产出的Schema是不是开放、可扩展的再看运行层能不能独立部署、权限模型到不到数据级、版本回滚方不方便、监控日志全不全。能在一个维度上做得很好的产品已经算不错两个维度都扎实的产品非常稀少遇到了就值得好好珍惜。我自己在踩过无数坑之后最大的顿悟是低代码不是在“降低编程难度”而是在“重新定义编程的对象”。开发者以前直接写代码现在变成了设计Schema、治理运行时。构建能力层和运行治理层这一对双胞胎才是低代码平台真正的技术内核。按这个思路去设计或选型大概率不会走偏。
