低代码面试反问与陷阱题

陷阱 1：低代码是不是就是拖拽几个组件

我一般会直接把这个认知纠正过来。拖拽只是交互表象，真正核心是 schema、编排引擎、运行时和扩展体系。只会讲拖拽，面试官会觉得你做的是 demo；把它讲成协议设计和状态变更系统，才更像平台能力。

因为低代码里真正重要的不是 DOM 最后长什么样，而是编辑动作怎么稳定地落成 schema 变更。直接改 DOM 看起来快，但后面做撤销重做、版本管理、diff、协作和运行态渲染都会变得很难。所以我会坚持让编辑器围绕数据结构，而不是围绕 DOM 本身。

因为这两者目标完全不同。编辑态要选中、高亮、拖拽、辅助线、属性面板；运行态只关心真实业务逻辑和页面表现。如果混在一起，前期可能省事，后期复杂度会上升得非常快。

我会把回答往三层拉。第一层是 schema 和数据结构；第二层是编排引擎怎么把动作转成 payload；第三层是运行时怎么消费 schema 把页面和联动跑起来。只要把这三层讲清楚，面试官就会知道你做的不是一个视觉交互，而是一套平台机制。

我一般不会顺着这个问题走极端。我会说低代码更适合结构化、重复性高的页面，比如后台、表单、表格、详情页。它不是替代前端，而是把前端经常重复实现的部分抽成平台能力，让研发从重复劳动里解放出来。

我会先看是不是拖拽过程中做了太多真实 DOM 读取和遍历，或者是不是每次动作都带出了整棵树重渲染。低代码编辑器最常见的问题，通常不是功能做不出来，而是页面一复杂就开始卡，所以我会优先查高频计算和渲染量。

低代码面试最容易踩的坑，就是把它讲成一个“拖拽控件题”。我会始终把它拉回到 schema、编排引擎和运行时这三件事上。