03 — 低代码设计器的基本布局：插件栏、画布、属性面板和底部扩展区

大多数低代码设计器最终都会走向同一套布局——不是巧合，而是因为用户的注意力分区和能力作用域，决定了空间结构只能长成这样。

一个典型设计器的四栏骨架

参考 lowcode-engine、tiny-engine 这类成熟低代码设计器，可以抽象出一个非常稳定的布局。这里说"四栏"，指的是左侧工作区、中间画布、右侧属性面板和底部扩展区；顶部工具栏横跨整个工作区，承载全局命令。

当前实现里，左侧工作区不是单栏，而是进一步拆成应用入口栏、文档入口栏和左侧内容面板。这样才能把应用级能力和当前页面/组件能力区分开。(lowcode-engine最早是没有workspace能力的，tiny-engine到现在还是只支持单页面)

这不是单纯的视觉布局，而是设计器的职责分层。 每个区域管什么、不管什么，应该是清晰的：

后面每个模块的实现，都可以对照这张表找到自己应该挂在哪里。

顶部工具栏：放全局命令

顶部工具栏应该放和当前页面整体相关的命令，而不是放具体组件配置。

常见命令包括：保存、预览、撤销、重做、页面缩放、设备切换、发布、出码、查看 Schema。

顶部工具栏的特点是：它不依赖当前选中了哪个组件。 无论画布上选中的是页面、按钮、表单还是空白区域，保存、预览、撤销这些命令都应该始终可用。

这类能力适合做成 command，而不是普通 UI 组件。后面设计插件系统时，我们可以让插件注册自己的工具栏按钮：

designer.registerCommand({name: 'preview',title: '预览',handler: () => {// 打开预览窗口  },})

这篇先明确一件事：顶部工具栏承载全局命令，command 系统的具体实现放到后面专门来讲。

左侧插件栏：放入口型能力

为什么左侧要分两栏

低代码设计器同时维护两个层次的 Schema：

AppSchema  pages  components  router  dataSources  assets  theme  globals  materialPackagesDocumentSchema  当前 PageSchema 或 ComponentSchema  componentsTree  state / methods / computed / watch  props / emits / slots / models  styles

这两个层次的作用域完全不同。"路由管理"影响的是整个应用，不应该被理解成当前页面的配置；"当前文档结构"只影响当前页面或组件，不应该和应用资源管理混在一起；"组件契约"只有在编辑业务组件时才有意义，它属于当前 ComponentSchema 的 public contract。

如果把这两类能力混在一条左侧栏里，用户很难判断当前操作的影响范围。

所以左侧分两栏不是视觉装饰，而是作用域语义：

这样用户可以形成稳定心智：左侧第一栏是在管理应用资产，左侧第二栏是在管理当前文档，画布是在编辑当前文档的可视结构，右侧是在编辑当前选中对象。

两栏的结构和内容

左侧插件栏可以设计成三层：

左侧应用入口栏：应用级插件左侧文档入口栏：当前文档插件左侧内容面板：当前插件内容

实际展示效果大致是：

┌────┬────┬─────────────────┐│应用│文档│ 当前面板内容      │├────┼────┼─────────────────┤│物料│结构│ Button          ││组件│逻辑│ Form            ││页面│契约│ Table           ││接口│    │ SearchForm      ││路由│    │                 │└────┴────┴─────────────────┘

入口栏负责切换工作区，内容面板负责展示当前插件内容。当前实现里，左侧面板标题会根据作用域显示"应用工作区"或"当前文档工作区"，这能提醒用户自己正在修改的是整个应用，还是当前页面/组件。

这也是 lowcode-engine 和 tiny-engine 这类设计器常见的思路：左侧不是写死一个组件树，而是一个可扩展的插件区。

中间画布：设计器的主工作区

中间画布是设计器最重要的区域。它至少要承担这些职责：渲染当前页面、支持选中组件、支持拖拽放置组件、显示选中框、显示容器高亮、显示辅助线、支持缩放、支持画布滚动、支持空状态。

画布不是普通预览 iframe，也不是普通 DOM 容器。它是一个带编辑能力的运行区。

同一个组件在运行态和编辑态会有不同表现：

• 运行态：按钮点击触发真实业务逻辑
• 编辑态：按钮点击优先选中节点

所以设计器画布需要在 Schema 渲染之上叠加一层编辑能力。但这里的"三层"不完全是三个可见 DOM 层，更准确地说，是一条从运行渲染到编辑绘制的依赖链：

编辑辅助层  ↑ 使用 rect / nodeId / hit-test节点定位层  ↑ 测量真实 DOMSchema 渲染层

如果画布运行在 iframe 里，实际 DOM 结构通常是：

iframe document└─ body   ├─ #schema-root   │  └─ 真实组件渲染结果   └─ #editor-overlay      ├─ selected-box      ├─ hover-box      ├─ drop-indicator      └─ guides

Schema 渲染层负责把组件树渲染成真实 DOM。编辑辅助层是覆盖在最上面的可见编辑态 UI，负责画选中框、拖拽占位、辅助线、容器高亮。

节点定位层通常不是一个独立可见的 DOM 容器，而是一组测量和映射能力：给 Schema 渲染出的 DOM 打 data-node-id，维护 nodeId -> HTMLElement，通过 getBoundingClientRect() 计算位置，处理 iframe 内滚动、缩放和设备画布偏移，把鼠标事件命中结果转换成 Schema 节点，再把测量结果提供给编辑辅助层绘制。

后面真正实现画布时，我们会围绕这三层展开。

右侧属性设置区：跟随选中节点变化

右侧属性面板是设计器中最容易被低估的部分。

它不是一个固定表单，而是一个上下文面板。 当前选中对象不同，右侧能配置的内容就不同：

选中页面时，右侧显示页面名称、页面 code、页面状态、生命周期、数据源、页面样式。选中按钮时，右侧显示文字、类型、尺寸、禁用状态、点击事件、样式。选中业务组件时，右侧显示组件 props、events、slots 和 v-model 绑定。

右侧属性面板的本质是：根据当前选中的 Schema 节点，找到它对应的物料描述，然后生成属性编辑器：

selectedNode.componentName   ↓material.props / events / slots   ↓setter   ↓右侧属性面板

这篇先建立认知：右侧面板不是固定表单，而是由物料协议驱动的上下文编辑器。 具体如何实现，等到物料系统和 setter 系统那篇再展开。

底部扩展区：放辅助但高频的能力

底部区域不一定每个设计器都有，但它很适合承载一些辅助能力：图层树、页面结构树、历史记录、操作日志、数据源调试、事件流调试、Schema 查看器、控制台。

这些能力不是每次都需要，但一旦进入复杂页面，它们会非常高频。

为什么不都放左侧？左侧更适合资源入口，底部更适合"当前画布的辅助信息"。图层树、操作日志、调试面板，它们都和当前画布强相关，跟着画布走比跟着资源入口走更自然。

底部区域同样应该是插件化的：

底部 Tabs  ├─ 图层  ├─ 历史  ├─ 日志  └─ Schema

后续需要加数据源调试器、事件调试器，注册到底部即可，不用改设计器主布局。

为什么要插件化，而不是写死布局

写死布局最大的代价是：每次加新能力，都要改设计器主组件。

低代码平台的能力迭代是持续的——物料、数据源、事件编排、调试器、出码器，每一个都会持续变复杂。如果主框架不为扩展留位置，它迟早会变成一个没人敢动的大组件。

更合理的做法是把设计器布局抽象成几个插槽区域：

topBarappActivityBardocumentActivityBarleftPanelcanvasrightPanelbottomPanelstatusBar

插件可以注册到不同区域：

designer.registerPlugin({name: 'material-panel',area: 'leftPanel',render: MaterialPanel,})designer.registerPlugin({name: 'schema-viewer',area: 'bottomPanel',render: SchemaViewer,})

这样设计器主框架只负责布局、状态和插件挂载，具体能力由插件提供。lowcode-engine、tiny-engine 这类设计器值得借鉴的地方正在这里：真正重要的不是某个界面长得像不像，而是主框架要为扩展留出位置。

最小设计器骨架

这篇暂时不实现完整拖拽和渲染引擎，只先确定一个最小骨架：

DesignerShell  ├─ TopToolbar  ├─ LeftActivityBar  │  ├─ AppActivityBar  │  └─ DocumentActivityBar  ├─ LeftPanel  ├─ CanvasArea  ├─ RightSettingsPanel  └─ BottomPluginPanel

它们之间最核心的共享状态只有几个：

interface DesignerState {schema: AppSchemacurrentDocument: {kind: 'page' | 'component'id: string  }selectedNodeId: string | nullactivePanel: {scope: 'app' | 'document'pluginId: string  }activeAppPlugin: stringactiveDocumentPlugin: stringactiveBottomPlugin: string | null}

有了这个骨架，后续才能继续往里填能力：画布渲染 Schema、左侧应用栏管理物料和路由、左侧文档栏管理结构和逻辑、从物料面板拖入组件、点击画布选中节点、右侧修改 props、底部查看 Schema、顶部保存和预览。

这就是设计器从 0 到 1 的第一步。

本章小结

布局不是视觉问题，是职责分层问题。

左侧两栏对应两个作用域（AppSchema 和 DocumentSchema），画布是主工作区，右侧跟随选中上下文，底部承载辅助能力。这套结构之所以稳定，是因为它和设计器的状态分层是同构的——不同区域，管不同粒度的 Schema。

更重要的是，这些区域应该天然支持插件化。设计器主框架不预设所有能力，而是提供稳定的区域和状态，让物料、页面、组件、调试、出码等能力逐步挂载进来。

下一篇，我们就可以基于这个布局骨架，开始实现一个可运行的设计器 Shell。

下一篇：04 — 搭建设计器 Shell