主流低代码框架怎么选：amis / formily / tmagic / h5-Dooring / lowcode-engine 逐家拆解
· 阅读需 11 分钟
上一篇聊了低代码的发展史与 AI 时代的平台格局，那是「行业面」。这篇落到具体框架：国内最常被摆在一起比较的五个开源项目——amis、formily、tmagic、h5-Dooring、lowcode-engine，它们其实不在同一个赛道，硬比「谁更强」是错的问法。
这篇做三件事：先把它们分类（不同类的框架解决不同问题）→ 逐家拆定位与技术路线 → 给一张选型决策表和几个必踩的坑。文中的版本号与开源协议都来自 npm 元数据实测（2026-09），其余事实标注了来源。
一句话先给结论：做中后台页面 → amis；做复杂表单 → formily；做运营活动页 → tmagic / h5-Dooring；想自己造一个低代码平台 → lowcode-engine。
一、先分类：它们根本不在一个赛道
| 类别 | 框架 | 一句话定位 | 核心抽象 |
|---|---|---|---|
| 配置渲染型 | amis | 用 JSON 生成后台页面 | JSON Schema → 渲染器 |
| 表单引擎型 | formily | 高性能动态表单 | 字段模型 + 响应式 + JSON Schema |
| 可视化搭建型 | tmagic、h5-Dooring | 拖拽产出 H5/PC 页面 | 画布 Schema + 运行时渲染 |
| 平台引擎型 | lowcode-engine | 用来「造低代码平台」 | 物料协议 + 页面协议 + 插件体系 |
记住这条分界线：前三类是「用低代码」，最后一类是「造低代码」。选型时先问自己站在哪一边。
二、逐家拆解
1. amis（百度）——JSON 换页面
- 定位：MIS（管理信息系统）页面生成工具，npm 描述原文就一句「一种 MIS 页面生成工具」；
- 核心用法：写一段 JSON 配置，内核渲染成可交互页面；内置 100+ UI 组件，表格/表单/图表/CRUD 一站式，数据源与联动也写在配置里；
- 实测版本/许可：
amis@6.13.0，Apache-2.0，仓库 baidu/amis； - 适合：中后台 CRUD、内部工具、报表页——前端人手不够时最速成；
- 不适合：高度定制交互、复杂动画、C 端展示（它是「配置驱动」，不是「自由前端」）；
- 坑：JSON 一长就难维护（需要拆分成 schema 片段/复用配置）；复杂逻辑会想在 JSON 里写表达式，越写越像一门残缺的编程语言。
2. formily（阿里）——表单领域的「性能 + 协议」
- 定位：动态表单/字段联动的解决方案，起家于「React 后台表单渲染性能」，把每个字段做分布式管理，字段变化只重渲染自己；
- 核心抽象：
@formily/core（响应式内核）+@formily/react/@formily/vue（框架适配）+ JSON Schema 描述表单（支持标准 JSON Schema 扩展）+ designable 设计器； - 实测版本/许可：
@formily/core@2.3.7、@formily/react@2.3.7、@formily/vue@2.3.7，MIT，仓库 alibaba/formily； - 适合：表单即业务的系统（审批、配置台、B 端 SaaS）、需要字段级联动/校验/性能的场景；
- 不适合：不是页面搭建器——别拿它去拼整页布局；
- 坑：学习曲线比 amis 陡（要先理解它的响应式与字段模型）；脱离它的设计器单独用时，Schema 手写成本不低。
3. tmagic-editor（腾讯）——运营页面的拖拽生产平台
- 定位：可视化页面搭建平台，源自腾讯魔方平台，用于快速生产 H5 / PC / TV 页面，在腾讯视频、腾讯会议等业务里使用；
- 技术路线：Schema + 沙箱运行时渲染，产物是一份 JSON/JS schema（DSL）；runtime 提供 vue2 / vue3 / react 多框架实现；
- 关键事实：官方能力表里**「下载页面源码：不支持」（tmagic 发布文档）——它是运行时路线**，不是出码路线；
- 实测版本/许可：
@tmagic/editor@1.7.13、@tmagic/core@1.7.13，Apache-2.0，文档 tencent.github.io/tmagic-editor； - 适合：运营活动页、专题页、需要「非技术人员自助搭建」的场景；
- 不适合：想要最终拿到可维护源码交付的项目（它不给你出码）；
- 坑：物料库要自己开发维护——搭建平台的价值 80% 在物料，不投入物料就是空壳。
4. h5-Dooring——H5 可视化搭建的最佳实践
- 定位：面向 H5 落地页/活动页的可视化配置方案，作者 MrXujiang；技术栈以 React + TypeScript 为主，配套 Node 后端，另有 PC 版与 Electron 桌面版；
- 特点：拖拽操作、上手快，强调 H5 场景的「搭建 → 预览 → 下载源码」链路（源码可导出，便于交付给开发继续维护）；
- 注意：npm 上没有同名包（我查过
h5-dooring不存在），它是仓库形态的项目，用的时候按仓库 README 走； - 适合：营销活动、落地页、创业团队快速出页面；
- 不适合：复杂中后台（那是 amis/lowcode-engine 的地盘）；
- 坑：社区项目 vs 大厂项目的维护节奏差异；深度定制要读源码。
5. lowcode-engine（阿里）——「造平台」的内核
- 定位：一套面向扩展设计的企业级低代码技术体系（npm 描述原文），来自阿里/钉钉宜搭团队，理念是「最小内核、最强生态」；
- 它产出两份数据（这是理解它的关键）：
- 资产包
assets：物料名称/包名/获取方式 → 对应《低代码引擎资产包协议规范》； - 页面
schema：页面结构、生命周期、代码信息 → 对应《低代码引擎搭建协议规范》；
- 资产包
- 两条消费路径：交给渲染模块（运行时，能在编辑器里继续改）或交给出码模块（
@alilc/lowcode-code-generator，生成可运行源码）； - 实测版本/许可：
@alilc/lowcode-engine@1.3.4，MIT，站点 lowcode-engine.cn； - 适合：企业自建低代码平台、要把搭建能力嵌进自己产品、需要插件/物料/设置器完整扩展点；
- 不适合：只想快速做个页面——用它等于「用造车工具造自行车」；
- 坑：学习曲线最陡（插件化 + 协议 + 渲染/出码双路径）；物料协议是长期成本，一旦自建平台，物料维护就是持续投入。
三、绕不开的技术路线：运行时渲染 vs 出码
这五家里除了 formily（表单库、不涉整页），其余都要面对这个选择：
- 运行时路线：amis、tmagic 是代表（tmagic 官方明确不支持下载源码）；
- 双路线：lowcode-engine 同时提供渲染与出码（出码文档 里列了三个适用场景：极致打开速度/降低 LCP·FID、老项目 + 新需求想 merge 源码、协议无法描述的代码逻辑）；
- 代价：出码意味着「一次性的交接」——交出源码后，页面就脱离了低代码编辑器，后续改动回到 ProCode 流程。想清楚「这个页面是要长期拖拽维护，还是交付后交给开发」，路线就定了。
四、一张选型表
| amis | formily | tmagic | h5-Dooring | lowcode-engine | |
|---|---|---|---|---|---|
| 定位 | 页面配置工具 | 表单引擎 | 可视化搭建平台 | H5 搭建方案 | 平台内核引擎 |
| 核心产物 | JSON 配置 | Schema + 字段模型 | 画布 Schema | 页面配置/源码 | 资产包 + 页面 Schema |
| 技术栈 | React/Vue | React/Vue 适配 | Vue 为主，runtime 支持多框架 | React + TS + Node | React |
| 出码 | 有 | 不涉 | 不支持 | 支持导出源码 | 支持 |
| 学习曲线 | 平缓 | 中偏陡 | 中等 | 平缓 | 陡峭 |
| 版本/许可（npm 实测） | 6.13.0 / Apache-2.0 | 2.3.7 / MIT | 1.7.13 / Apache-2.0 | 无 npm 包 | 1.3.4 / MIT |
| 谁适合 | 中后台快速出页 | 表单密集型系统 | 运营活动页 | 营销 H5/落地页 | 自建平台的团队 |
五、几个必踩的坑（选型时先想清楚）
- 「低代码省人力」是错觉的一半：省的是页面搭建，不省物料/组件/权限/数据源/发布——这些才是长期成本，尤其自建平台（lowcode-engine）时；
- Schema 会膨胀：无论 amis 的 JSON 还是 tmagic 的画布 Schema，页面一复杂就会出现「配置比代码还难读」；提前定好拆分与复用策略（片段化、物料化）；
- 协议即锁定：用了谁的 Schema，就绑定谁的协议与运行时；lowcode-engine 的物料协议生态最大，也意味着迁移成本最高（这也是它被称为「事实标准」的另一面）；
- 出码不是银弹：出码解决性能与交付，但牺牲了后续的可视化维护；反过来运行时路线牺牲性能换灵活性。按页面生命周期选，别按喜好选；
- 表单场景别硬上页面搭建器：复杂联动/校验用 formily 这类领域引擎，比在页面搭建器里拼表单稳定得多。
六、放到 AI 时代看
上一篇说过：AI 时代的低代码，内核从「编排 UI/流程」变成「编排 Agent」。两者并不冲突，而是两条互补的谱：
- 确定性低代码（本篇这些）：拖拽/配置产出确定行为的页面与流程，适合稳定、可审计、要长期维护的界面；
- 概率性编排（Dify/Coze/n8n）：用自然语言编排不确定的模型与工具，适合探索型、变化快的自动化。
正在出现的交叉点：物料协议 + 工具协议。当 lowcode-engine 这类引擎把「能力」描述成标准化的物料/资产包时，它和 MCP 那套「把能力描述成工具」的思路其实是一回事——描述清楚能力，谁来调用都可以（人拖拽、或 Agent 调用）。这大概就是「低代码平台」在 AI 时代最可能的演化方向。
参考
- Low-Code Engine 出码文档（出码适用场景与代价）
- tmagic-editor 文档（发布与「下载源码不支持」）
- 10 个前端低代码开源项目盘点（腾讯云社区）
- 前端低代码工具盘点（掘金）
- 低代码平台架构深度剖析（潘征）
- 本 blog 姊妹篇：低代码二十年：从拖拽表单到编排 Agent
- 版本/许可数据：本机
npm view <包> version license实测（2026-09）
声明：本文无厂商合作；各家能力迭代快，选型前请以官方文档与最新版本为准。文中「适不适合」是基于公开资料与社区经验的判断，欢迎讨论。