企业官网建设流程全解析

简介：头豹研究院《2022年中国低代码无代码平台行业研究报告》以PDF形式呈现，面向企业数字化负责人、低代码厂商从业者及行业研究人员，聚焦低代码/无代码平台如何快速构建企业数字化应用这一问题。报告从定义与分类切入，梳理低代码需少量代码、无代码零代码搭建的差异与适用企业群体，并沿发展历程、平台架构、四种商业模式（直接面向客户、间接面向客户、前后端开发平台、生态型平台）、公有云与私有化部署方式、收费模式及投融资情况逐层展开，最后落到厂商盈利现状与未来趋势判断。压缩包内仅含1个PDF文件，约3.43MB，单份文档即可完整阅读，无需解压多个子目录。已有111人学习下载，适合用作行业入门梳理、方案汇报引用与商业模式对比的参考底稿。

1. 低代码的真相：省掉的不是代码量，是从需求到可运行之间的反复翻译

很多人对低代码/无代码平台的第一印象是「一个更花哨的代码编辑器」：把 if-else 换成连线，把类图换成拖拽。方向反了。真正让这类平台跑起来的不是编辑器，而是它背后那层被压得很扁的元数据模型——应用不是被「写」出来的，是被「描述」出来的，运行时负责把描述解释成界面、SQL、状态流转和权限谓词。搞懂这一层，你才有资格判断一个平台的天花板在哪：它省的从来不是敲键盘的时间，而是需求到可运行之间来回翻译的次数。这份 2022 年的行业研究报告把这条链路从平台架构、厂商分类一路拆到商业模式与部署形态，顺着机制往下读，比看一百页功能清单有用。

2. 元数据驱动：拖出来的应用凭什么能跑起来

低代码不是横空出世的东西，它前面倒过两代先行者。上世纪 90 年代那批桌面可视化开发工具，思路是「先画界面、再挂业务逻辑」，快速应用开发（RAD）由此流行起来；问题也很清楚——开发环境绑死在某套工具链上，产物缺乏模块化，两个人几乎没法协作改同一个工程。2001 年前后，业界又提出模型驱动架构（MDA），试图把需求捕获、分析、设计、编码、测试、部署串成一条从模型自动向下推导的流水线。方向没错，但那批实践普遍卡在同一个地方：模型和代码之间没有稳定的映射，模型改一次，代码分叉一次，最后没人知道哪边才是真相。

低代码真正的转折，是把这件事的野心往回收了一档。

2.1 从「写代码」到「描述应用」：控制权到底交给了谁

前两代方案都想让模型生成代码。生成这条路有个绕不开的坑，叫往返工程：编辑器吐出一份代码，工程师手改了三行，再回到可视化界面动一下，手改的部分就没了。谁来承担这个损失？没人愿意。所以低代码平台的主流实现换了个法子——不生成代码，直接解释元数据。你在设计器里拖出来的东西，落库的是一份结构化的描述，运行时读这份描述，实时决定渲染什么控件、查哪张表、走哪个状态、拼什么条件。

这个选择能成立，靠的是两个前提同时到位。第一，把「模型」的边界收窄：不再试图描述整个软件工程，只描述一个应用里真正高频的那几类东西——实体与字段、页面与组件、流程与节点、角色与权限。窄，才可能做到语义闭合。第二，运行时被统一了：云计算把操作系统、中间件、数据库这几层差异抹平，同一份元数据可以在不同租户、不同环境里被同一套解释器执行。

代价同样明确：表达能力被锁死在 Schema 能描述的范围里。后面所有的「场景不匹配」「定制做不动」「上线三个月没人用」，根子几乎都能追到这一刀上。低代码不是不能做复杂业务，是它从设计的第一天起就默认放弃了那部分表达力，换来的是速度和一致性。

2.2 一条元数据的完整链路：从 JSON 到建表语句，再到查询谓词

元数据驱动听起来抽象，落到代码上其实很朴素。一个实体在平台里的样子，大概率长这样：

{ "entity": "purchase_order", "label": "采购单", "fields": [ { "name": "code", "type": "string", "length": 32, "required": true, "unique": true }, { "name": "supplier_id", "type": "reference", "target": "supplier", "required": true }, { "name": "amount", "type": "decimal", "precision": 18, "scale": 2 }, { "name": "status", "type": "enum", "options": ["draft", "submitted", "approved"], "default": "draft" }, { "name": "owner_id", "type": "user" } ], "indexes": ["supplier_id", "status"], "permissions": { "read": "owner_id == $currentUser.id || $currentUser.roles contains 'purchaser'", "update": "status == 'draft' && owner_id == $currentUser.id" } }

这份 JSON 在平台里会被两条链路消费。编译期把它翻成物理表结构，运行期把它翻成查询和校验。常见的实现思路大致如下：

# 编译期：实体元数据 -> 建表语句 def compile_entity(meta, dialect): cols = [] for f in meta["fields"]: t = f["type"] if t == "reference": # 关联字段物理上只存对端主键，展示用的名称靠联表或冗余列补齐 cols.append(f'{f["name"]} BIGINT NOT NULL') elif t == "decimal": cols.append(f'{f["name"]} DECIMAL({f["precision"]},{f["scale"]})') elif t == "enum": cols.append(f'{f["name"]} VARCHAR(32) DEFAULT \'{f["default"]}\'') else: cols.append(f'{f["name"]} ' + dialect.type_of(t, f)) # 元数据里声明的查询条件字段，必须在建表时就落成索引，否则上线后必然补刀 return dialect.create_table(meta["entity"], cols, meta.get("indexes", [])) # 运行期：权限表达式 + 用户筛选 -> WHERE 谓词 def build_query(meta, user, filters): where = [compile_expr(meta["permissions"]["read"], {"currentUser": user})] where += [compile_filter(f) for f in filters] # 字段级权限在 SQL 投影里裁剪，而不是靠前端隐藏控件 sql = 'SELECT ' + projection(meta, user) + ' FROM ' + meta["entity"] return sql + " WHERE " + " AND ".join(where)

meta是实体描述，user是当前登录身份（含角色、所属组织），filters是页面上下发的筛选条件，dialect是数据库方言适配器。这里面最容易被低估的是权限那一行：把permissions.read编译成 SQL 谓词，而不是查完了再在内存里过滤，是两个完全不同的量级。前者能走索引，后者在分页场景下会出结构性错误——先过滤再分页，每页条数会飘；先分页再过滤，页内条数会缺。我见过不少平台在早期版本里就是这么错的，数据量一上来才被发现。

2.3 同一份 Schema 怎么同时喂给 PC 和移动端

答案是中间表示。元数据不直接映射到控件，先经过一层「这个字段在业务上是什么」的抽象，再由各平台的适配层去挑具体控件。字段类型到控件的映射，通常是这么一张表：

真正的渲染代码只关心语义，不关心平台长相：

// 中间表示只回答"这个字段是什么"，不回答"它长什么样" const CONTROL_MAP = { reference: { pc: 'SelectWithSearch', mobile: 'PickerPopup' }, decimal: { pc: 'NumberInput', mobile: 'NumberPad' }, enum: { pc: 'RadioGroup', mobile: 'ActionSheet' }, string: { pc: 'TextInput', mobile: 'TextInput' } }; function toViewNode(field, platform) { const spec = CONTROL_MAP[field.type] || CONTROL_MAP.string; return { key: field.name, control: spec[platform], // 同一份元数据在两套控件库里各取所需 props: { label: field.label, readonly: field.readonly }, rules: buildRules(field) // 校验规则同样来自元数据，前后端共用一份 }; }

platform取pc或mobile，决定了从映射表里挑哪一列；buildRules从required、length、precision这些元数据属性推导出校验规则，服务端拿到的是同一份规则对象——这是低代码能做到「前端校验不重复写两遍」的关键。固定布局和响应式布局的差别也在这层：前者把坐标写死在元数据里，后者只声明栅格跨度和断点行为，具体像素由渲染引擎算。移动端不是 PC 页面的等比缩小，它是另一套控件体系，中间表示就是两边唯一能对上的公共语言。

3. 六大引擎：平台层到底封装了什么

报告里以某家表格软件厂商的低代码产品为例，把平台层拆成六类引擎：数据模型、业务逻辑、工作流、页面渲染、智能报表、系统集成。这个拆法有参考价值，因为它把「低代码」从编辑器神话还原成了一组运行时服务——设计器只是壳，真正决定能力边界的是这六个引擎各自做到什么程度。自下而上的分层也很清楚：基础层是数据库、操作系统、云主机；平台层是这六类引擎；应用层才是 CRM、进销存、工单、设备运维这些具体系统。

3.1 数据模型引擎：内建库和直连外部库是两条完全不同的路

内建一个小型嵌入式数据库，和直连企业已有的数据库，看起来只是存储位置不同，实际上是两种产品哲学。内建库的 schema 所有权在平台，字段加一个、类型改一次，平台自己能做主，迁移脚本它自己生成，所以「五分钟建一张表」的体验才成立。直连外部库就不一样了，schema 归 DBA 管，平台只能在上面架视图和映射，任何结构变更都要走变更流程。前者适合从零起步的长尾应用，后者适合已经有 ERP、MES 这类存量系统的中大型企业——你不能为了做个巡检表，把核心库的数据搬一遍。

真正吃工程量的是方言适配。可视化查询设计器画出来的是一棵关系代数树，落到不同数据库上语法差异很大：分页、字符串拼接、日期函数、标识符大小写、空值排序，全都要单独处理。

class Dialect: def limit(self, sql, offset, size): raise NotImplementedError class MySQLDialect(Dialect): def limit(self, sql, offset, size): return f"{sql} LIMIT {size} OFFSET {offset}" class OracleDialect(Dialect): def limit(self, sql, offset, size): # 老版本没有 LIMIT，只能套 ROWNUM；低代码对接存量系统时最先撞上的就是这类差异 inner = f"SELECT t.*, ROWNUM rn FROM ({sql}) t WHERE ROWNUM <= {offset + size}" return f"SELECT * FROM ({inner}) WHERE rn > {offset}" class DomesticDialect(Dialect): # 国产库多数兼容 Oracle 语法，但分页关键字、大小写敏感、隐式类型转换仍有出入 ...

offset是跳过行数，size是页大小，这两个参数看着简单，写错一个就会导致翻页丢数据或者重复数据。视图这层抽象才是数据模型引擎的真正价值：它让元数据可以指向一张已有系统的表，只声明「我要哪几列、怎么关联、哪些字段可写」，不必把数据搬进平台自己的库。代价是权限和事务边界要跟源系统对齐，跨库 join 基本别想，性能上限由源库决定。

3.2 业务逻辑引擎与工作流引擎：状态机才是流程的真身

业务逻辑引擎要解决的是一个矛盾：同一段校验逻辑，既要在页面上即时反馈，又要在服务端兜底防绕过。做法通常是让逻辑描述与执行位置解耦——一段编排好的逻辑可以被编译成前端脚本，也可以被服务端解释器执行，两边共用同一份表达式。表达式语言几乎不会直接用宿主语言的eval，而是自定义一套 DSL，配 AST 解释器和函数白名单，原因很实在：多租户环境下执行用户写的任意代码，等于把服务器交出去。

工作流引擎的内核是一个有限状态机，外面套了组织架构解析和任务分派。一份流程定义大致长这样：

{ "process": "purchase_approval", "variables": ["amount", "dept_id"], "states": ["draft", "submitted", "approved", "rejected"], "transitions": [ { "from": "draft", "to": "submitted", "event": "submit", "guard": "amount > 0 && items.length > 0" }, { "from": "submitted", "to": "approved", "event": "approve", "assignee": "role:dept_manager", "scope": "dept_id" }, { "from": "submitted", "to": "rejected", "event": "reject", "assignee": "role:dept_manager", "scope": "dept_id", "require_comment": true } ] }

guard是流转的前置条件，assignee是审批人解析规则，scope限定了角色在哪个组织范围内生效，require_comment强制填写意见。这里最见功力的是assignee的写法：如果写成具体用户 ID，组织架构一调整，单据就卡死；写成role:dept_manager加scope，系统会在运行时去查当前部门的负责人，人换了也不影响。

驳回为什么是工作流里最难做的部分？因为它要求状态可回退，而大多数引擎天然是单向推进的。要么只允许退回上一节点，业务不认；要么允许退到任意历史节点，那就得把中间节点的任务实例全部作废、变量回滚、通知清理干净，稍有不慎就出现两张待办指向同一张单子。会签、或签、加签、转办、超时自动流转，每一个都在这套状态机上开一个口子，口子开得越多，状态一致性越难保证。这也是为什么「流程引擎」在低代码平台里往往是独立演进的一条产品线。

3.3 页面渲染引擎与智能报表引擎：开箱即用的代价

页面渲染引擎的活是：拿组件树，套主题，出页面。开箱即用的 UI 组件库和样式模板是它最大的卖点，支持固定布局和响应式布局，允许任意拖动元素位置。但组件库越丰富，定制成本反而可能越高——你想要的刚好是第 37 号组件的第 4 种变体，而它没做。

智能报表引擎是另一条完全独立的渲染管线，这一点很多人不理解。普通页面是「组件树」，树形结构天然适合自上而下布局；而中国式复杂报表是二维网格——合并单元格、斜线表头、分组小计、跨页表头重复，本质是一个二维布局求解问题，跟组件树模型天然冲突。所以报表通常用单元格模型：

{ "sheet": "monthly_sales", "cells": [ { "r": 0, "c": 0, "colspan": 4, "text": "月度销售汇总", "style": "title" }, { "r": 1, "c": 0, "text": "区域", "style": "th" }, { "r": 1, "c": 1, "text": "金额", "style": "th" }, { "r": 2, "c": 0, "binding": "=ds.region", "expand": "down", "group": true }, { "r": 2, "c": 1, "binding": "=sum(ds.amount)", "expand": "down" } ] }

r、c是行列坐标，expand: down表示这一格按数据集向下展开，group: true表示按该列分组并触发小计，colspan在数据展开之后需要重新计算——这就是为什么报表引擎不能复用普通页面的渲染器。类 Word 的报告则是第三种模型：模板加数据绑定，段落级重复和表格级重复是两套展开逻辑。三类渲染管线共存在一个平台里，是低代码产品复杂度被严重低估的地方。

3.4 系统集成引擎：低代码的边界在这里划

集成能力决定了低代码能长在哪个位置。常见的三类：数据库直连，把已有系统的表挂成数据源；WebAPI 的构建与调用，让平台能被别的系统调，也能调别人的接口；用户认证与权限同步，把企业统一身份和组织架构接进来，否则每个应用都要维护一份人员名单，不出三个月就会对不上。

报告里提到一个很务实的定位：大型制造企业的 ERP 功能已经很完善，他们不需要用低代码重做核心系统，而是在 ERP 旁边用低代码搭一些补充应用，通过接口把数据接过去。这条边界挺关键——低代码吃的是长尾应用：那些业务上确实存在、但不够格立项、长期靠 Excel 加人肉传递顶着的场景。反过来，核心交易系统不适合搬上来，事务边界、并发控制、复杂 SQL 优化，这些恰恰是元数据解释器最不擅长的领域。

4. 低代码与无代码：同一套技术为什么长出两种产品

技术底座几乎是同一套，产品形态却分成了两岔。报告里给了一组很直白的对比：低代码相比传统开发快 2 倍左右，无代码能快 8 倍。速度快 4 倍的差距不是靠工程优化挤出来的，是靠砍掉自由度换来的。

4.1 抽象层高度决定用户天花板

低代码产品的路子偏开放：UI 界面可以用 HTML 这类语言去写，数据库处理可以用 SQL 深度加工，容器功能给得多，但每一处都不够精细，用户得靠少量代码把它改到想要的形态。无代码产品反过来，把基础功能全部封装死，字段设定、数据处理只能调用现成的，场景覆盖窄，但垂直场景做得精细，拿来即用。

这张表背后是一条规律：抽象层每往上抬一级，单点交付效率上升，正交可组合性下降。无代码把「字段」「表单」「流程」这几类原语做成了不可拆的整件，所以业务人员十分钟能出一个应用；但也因为不可拆，遇到「差一点点」的需求就彻底卡住。低代码保留了下拆的余地，代价是必须有人会拆。

4.2 逃逸阀：低代码必须留的那道门

我把这个叫逃逸阀。它是低代码和无代码最本质的分水岭，也是选型时最该问的一个问题：当平台做不了某个需求时，有没有一条不需要等厂商发版的出路？

常见的逃逸阀有三种。一是自定义代码块，在前端事件或服务端逻辑里嵌一段脚本；二是自定义 SQL 视图，把复杂查询写成视图挂上去；三是外部 API 调用，把做不了的部分放到外面实现，平台只负责编排。有这三种，平台的能力边界就从「它能做什么」变成「它配合你能做什么」。

但逃逸阀不是免费的。一旦允许用户写代码，沙箱、审计、版本管理、多租户隔离全都要重做一遍：

// 逃逸阀不是"随便写 JS"，而是把用户代码关进一个有边界的执行环境 const runner = createSandbox({ context: { api, user: { id, roles }, utils: { formatDate } }, // 只注入业务需要的对象 globals: ['Math', 'JSON', 'Date'], // 白名单，window/document 一律不给 timeout: 500, // 毫秒，防死循环拖垮渲染线程 memoryLimit: 16 * 1024 * 1024 // 单次执行内存上限 }); const result = runner.exec(userScript); // 超时和异常走统一出口，便于审计和定位

context决定了用户脚本能碰到哪些能力，给多了等于开后门；globals是全局对象白名单，window、document、require这类必须屏蔽；timeout和memoryLimit是防止一段死循环把整个租户的页面拖垮。参数看着简单，每一条都是踩过坑之后加上的。

4.3 公有云与私有化：收费、维护、周期的真实差异

报告把两种部署方式在五个维度上做了对比，结论很明确：公有云前期投入低，按模块数量和使用时长周期付费，即买即用没有部署周期，但不能和企业内网对接；私有化需要买服务器、做定制开发和集成，部署周期长，价格从几千元一年直接跳到百万级，换来的是数据留在自己机房、可以自由拓展、升级更灵活。

从架构上看，这个差别对应的是多租户模型的选择：共享库共享表加租户字段、共享库独立 schema、独立实例，隔离性依次增强，运维成本也依次上升。私有化真正的成本不在安装，在版本分叉——客户现场改过表结构、加过触发器，下一次升级脚本就可能冲突。报告里说大多数成功交付的产品是公有云形态，价格在几千元一年，这不是厂商不想做私有化，是私有化的边际成本压不下来。

4.4 四种商业模式，其实是四条交付边界

报告把低代码厂商的商业模式分成四类，换个角度看，它们画的是厂商把「实施」这件事往外推了多远。

直接面向客户模式是主流：厂商既卖产品又做实施，通用模块搞不定的就上定制开发，产品和人力捆在一起卖。间接面向客户模式往后退一步：厂商只提供相对通用的产品，定制需求交给第三方 ISV 或咨询公司，厂商赚产品费，伙伴赚实施费。前后端开发平台模式更靠上游：面向软件开发商卖框架、插件、控件、组件，帮别人提效，自己不碰

本文还有配套的精品资源，点击获取