大家好，我是何遇
有过企业级低代码项目落地经验，也出版过相关图书《低代码平台开发实践：基于 React》。
很多朋友简历里写了低代码项目，但面试时总感觉说不清楚，抓不住重点。
今天，我就结合自己的经历，跟你聊聊面试中如何把低代码经验讲得更具说服力，希望能给同样在简历里写了低代码的你，带来一些启发。
4 个核心要点
你可以从以下 4 个方面，向面试官清晰地展示你的低代码项目经验：
1. 项目缘起与目标
简要说明为何要开发低代码平台。是为了提效？解耦？支持更多非技术角色？让面试官理解这个系统为何而生。
2. 产出物如何上线运行
解释低代码平台生成的内容（如代码、配置、DSL）是如何与现有系统集成，并最终部署上线的。
3. 底层协议设计
如果你参与了协议或 schema 的设计，可以说说如何定义组件、布局、交互逻辑的数据结构。
4. 渲染机制实现
介绍平台的渲染思路，例如是否采用运行时引擎？是如何根据协议动态渲染出组件的？
下面我们逐一展开。
项目缘起与目标
低代码平台，本质上是「生产应用的工厂」。建一个这样的「工厂」，工程量巨大，绝非拍脑袋的决定。所以在面试时，你一定要讲清楚开发这个平台的背景动因、预期目标以及主要的使用人群。
我的案例
2019 年，公司高层要求将多个供应链子系统集成到新项目中。我采用微前端技术完成了系统整合，但紧接着，一个新挑战出现了：
如何统一各个遗留系统的样式和交互逻辑？
一开始，我们尝试直接改代码，但很快就发现此路不通：
- 技术栈杂乱：项目涵盖 React、Vue 甚至 JSP，改动成本极高。
- 工作重复枯燥：团队成员（包括我）积极性普遍不高。
正是在 2019 年底，我开始在社区关注低代码。当我读到某位博主的实践经验后，突然眼前一亮！低代码，也许能为我们的问题提供一个突破性的解法。
我们的系统是典型的 B 端应用，大量页面都是列表页。于是，我以列表页为切入点，率先搭建出支持列表配置的低代码方案，随后又扩展出第二种搭建模式，覆盖了表单页、详情页等场景。
因此，在面试中，我会这样总结我的项目背景：
痛点/初衷： 整合 React / Vue / JSP 等遗留系统后，统一样式和行为的人工成本过高，且团队缺乏意愿持续投入。
目标：逐步替换过时的技术栈，实现系统现代化。
主要用户：前端工程师。
产出物如何上线运行
社区里聊低代码，很多人都盯着「拖拽如何实现」。但我告诉你，这远远不够！
“生成的应用如何上线运行？”是平台设计中不可忽视的关键问题。甚至在平台开发之初，就必须对它有清晰的规划。
我曾专门撰写过一篇文章，介绍低代码页面如何接入中心系统。欢迎阅读。
我所负责的低代码平台，其运行机制为：
我们平台的产出单位是「页面」，每个页面都会被集成到中心系统的微前端基座中。基座负责路由管理与权限控制。
页面生成到上线的流程
1. 页面创建 & Schema 生成
使用者通过平台创建页面，产出一个 Schema (页面描述文件)。这个 Schema 初期存数据库，后来演进为推送到 Git 仓库，最终存储在 OSS 上。
2. 路由注册
页面创建后，使用者基于 ID 为页面定义一个路由。基座通过后端接口获取所有路由，确保每个页面都有访问入口。
3.用户访问 & 页面渲染
用户点击菜单，基座加载对应的低代码子应用。子应用根据 ID 获取 Schema，交给渲染器进行最终渲染。
渐进式演进：从 Schema 渲染到出码
在平台后期，我引入了「出码」机制，将 Schema 直接转化为代码再部署。这显著提升了页面性能，也让线上页面与低代码概念实现了脱钩。无论是运行时渲染还是出码部署，页面都通过统一的路由配置和微前端接入基座。
底层协议设计
协议，就像是低代码世界的「TypeScript interface」。它定义了页面的结构和能力，是构建页面的基础。
面试官可能会问，你是如何设计协议的？你可以从这两个核心问题入手：
- 页面需要具备哪些能力？
- 是否复用现有组件？如何适配？
页面能力的抽象
在我的实践中，我们定义的页面能力主要包括：
- 网络请求：页面和组件级别的数据加载与提交。
- 表单校验：支持基础规则与自定义逻辑。
- 联动能力：字段间的值联动、组件间的交互联动。
- 组件取数：如表格、下拉框等组件依赖接口动态加载数据。
- 交互逻辑：支持预置行为（跳转、弹窗）和自定义 JS。
明确这些能力后，再为每种能力定义清晰的数据结构，让平台能够解析并执行。
组件复用的策略
我选择了复用公司现有的组件库。
为此，在渲染层为每个组件增加了一层包裹逻辑，用于适配协议。
以表格（table）组件为例，其包裹层负责：
- 从协议中读取「取值路径」等配置；
- 获取对应数据；
- 将处理后的数据传入真正的
table组件进行展示。
这种方式既保留了既有组件的成熟能力，也保证了它能平滑接入低代码平台。
渲染机制实现
渲染，就是将 Schema 变成用户能看到的界面。它可以分为两个部分：
- 设计阶段的画布渲染（所见即所得）
- 页面运行阶段的最终渲染（用户访问时）
画布渲染：独立的 iframe 环境
画布渲染，要确保高性能、低延迟，还要保证环境纯净，避免变量污染和样式干扰。
我的选择是：将画布运行在一个独立的 iframe 中，我称之为「渲染器环境」。
实现画布渲染的 3 个关键点：
- 启动渲染器环境：设计器加载时，唤起并初始化 iframe。
- 跨 iframe 通信：由于同源，设计器通过
iframe.contentWindow直接调用渲染器挂载在window上的 API，实现组件增删改、拖拽定位、Hover 高亮等高频交互。 - 渲染器的实现：渲染器环境内部，是一个核心的 React 组件，被称为渲染器。它递归地将 Schema 转换为 React 树，并处理数据绑定和事件联动。
线上渲染：运行时 vs 出码
用户最终看到的页面，通常有两种渲染策略：
1. 运行时渲染
用户访问时，动态获取 Schema，再由渲染器实时解析生成页面。需要注意的是：仅有 Schema 不足以完成渲染。还必须确保 Schema 中引用的组件在运行环境中是可用的。通常做法是根据组件的使用情况，动态加载对应的资源，例如通过 <script> 标签按需引入组件模块，确保渲染器可以正确渲染出完整页面。
- 优点：灵活性高，修改实时生效。
- 缺点：有一定的首屏性能损耗。
2. 出码渲染
平台将 Schema 直接转换为标准的前端代码（如 React/Vue 项目），再部署上线。
- 优点：性能高，产物与手写项目无异。
- 缺点：更新依赖重新出码和部署。
两种策略对比：
| 对比维度 | 运行时渲染 | 出码渲染 |
|---|---|---|
| 灵活性 | 高 | 中 |
| 首屏性能 | 较低 | 高 |
| 更新成本 | 实时生效 | 需重新出码、部署 |
| 技术复杂度 | 高（依赖运行时渲染器） | 中（转译构建过程更重） |
| 场景适配 | 变更频繁、需求多样 | 页面稳定、性能要求高 |
大多数成熟的低代码平台，都会同时支持这两种策略，供使用者按需选择。
写在最后
我是何遇，感谢你的阅读。
希望这篇文字能为你厘清低代码的基本脉络，在面试中更有条理、更有自信。
