1. 2026年低代码市场怎么了：这轮盘点为什么还是刚需

说起来挺有意思，我最近连续被三拨朋友问到同一个问题："低代码平台到底还能不能选？选哪家？"

有人是被领导安排做技术选型，手头有几十份厂商资料看到眼花；有人是团队已经做了半年POC，结果卡在"demo很美、生产拉胯"的尴尬位置；还有人更直接——被某个平台的AI宣传片打动，差点拍板采购，冷静下来发现连"AI到底能干什么"都没人说得清楚。

这些问题不是个例。低代码平台经过这几年的爆发式增长，已经从"要不要用"的问题，彻底转向了"怎么选、怎么用、怎么不被坑"的问题。尤其到了2026年，市场格局和两年前相比变化非常大：头部厂商完成了平台化和生态化转身，垂直场景厂商开始深耕行业Know-how，开源阵营也在快速收敛。单纯看官网功能列表已经没用了，因为每家都写得很全，真正的差异藏在架构设计、定价策略、扩展边界和厂商的商业模式里。

所以我想以多年做集成、做内部系统、也踩过几次选型坑的亲身经历，做一次尽量客观、尽量贴近落地场景的盘点。本文会完整拆解15家标杆厂商的分工格局、各家底牌与短板，然后给出真正可用的选型路线和避坑问题清单。

文章适合这几类人看：

• 正在做低代码平台采购选型，需要一份"提问清单"而不是又一份厂商宣传册的人；
• 公司已经买了低代码平台，但用起来总觉得别扭，想知道自己是选错了还是在用错了的人；
• 想用低代码做开源项目、自托管应用，但不确定哪条路线最省心的个人开发者。

另外多说一句：我选择的15家厂商不代表"只有它们值得看"，而是它们恰好覆盖了市场上最主要的几种技术路线和商业模式。理解了这几种路线，其他同类产品你也能自行判断。

2. 筛选15家的尺子：我看重的六个评估维度

低代码工具的评测文章网上很多，但大部分是"功能罗列式"的：A平台有表单、有流程、有报表，B平台也有，然后得出结论"各有千秋、按需选择"。这种文章看了等于没看。厂商之间的真实差异从来不在"有没有"，而在"做到什么程度、为谁而做、成本结构如何"。

我做这轮盘点时，给自己定了一把统一的"尺子"，六个维度，每个维度往下拆出可量化的判断标准。

2.1 驱动模型的差异：页面驱动、表单驱动还是模型驱动

这是最容易被忽略、但影响最深远的维度。页面向的低代码把"搭页面"作为中心，适合做展示类应用，但遇到复杂数据关系就容易乱；表单驱动的平台以"填单-审批"为核心，做流程类应用很顺手，可一旦业务对象之间的关系复杂了，数据模型就会散成一团；模型驱动的平台先把业务对象、关系、权限、状态机定义清楚，再由模型生成界面，开发效率和后期维护性完全不一样。

我见过不少团队选型时只看demo里"拖拽出页面"多流畅，根本没人问数据模型怎么管理。等做到第三个应用，发现同样的客户信息在五个模块里各存一份，想统一成主数据，才发现平台的关联模型能力撑不住，那真是叫天天不应。

2.2 扩展边界与逃生通道：能不能写代码，能写到多深

纯拖拉拽的工具永远只适合简单场景，成熟业务最终一定会碰"平台没提供的能力"。所以我要看三件事：有没有代码级扩展点（自定义页面、自定义组件、后端脚本节点）；能不能用标准方式调用外部API、收发消息；以及最关键的一旦平台撑不住了，你的数据、应用定义、业务逻辑能不能导出来，导出到什么粒度。

最后这一点就是"逃生通道"。"导出Excel"听起来能备份，但你导不出流程定义、权限配置和页面逻辑，这不算可迁移。我最近看到一个真实案例：某公司想把A平台的采购流程迁到B平台，A平台导出的只有数据表和静态页面截图，整个工作流状态机全部要重建，三个月工作量直接打水漂。

2.3 集成能力不是"有连接器"，而是"连接器能通到什么程度"

很多平台宣称"内置几百个连接器"，实际用起来你会发现，所谓连接器可能就是"能发一次HTTP请求"，认证方式只支持固定几种，字段映射只支持最简单一一对应。真正的集成能力要看：连接器如何管理凭据和密钥、是否支持自定义连接器、有没有可编程的Webhook、对消息队列的支持程度怎么样、以及平台本身能不能作为事件中枢，而不只是被动调用第三方。

2.4 权限模型的粒度：这是企业级和玩具的分水岭

小团队用低代码，权限做到"管理员-普通用户"两级就够了。但企业环境里，同一个单据，不同组织、不同角色、不同数据范围都可能有不同可见性和操作权限。有些平台能做"角色+组织+字段级"的权限矩阵，有些平台连"只看自己创建的记录"这种行级权限都要靠写脚本。这个维度在POC阶段几乎不会被发现，因为演示数据都是造出来的，但一旦接入真实组织架构，区别就是天堂和地狱。

2.5 AI能力的水分排查：哪些是真增强，哪些是贴标签

2026年的低代码平台没有不谈AI的。但水分差别极大。真增强至少要有几项能力：通过自然语言描述生成页面结构（而不是生成一段宣传文案）；根据数据模型自动推荐业务对象和字段；在流程节点上做语义级别的配置辅助。水分很大的表现是：所谓"AI助手"只会帮你生成一段示例代码，或者帮你格式化一个表格，核心价值约等于零。

我评估时还会单独问一句：AI能力是内置免费用，还是按调用次数额外计费？这个坑我在后面专门展开。

2.6 商业模式与成本演化：按用户数、按应用数还是按资源量

最后但绝非最不重要的是钱的问题。低代码平台很少有"一口价"，常见的计费模式包括按用户数、按应用数、按运行环境资源量、按API调用次数、按AI调用次数。不同模式在不同规模下的总成本曲线差异巨大。更关键的是，你的应用数量增长后，厂商的收费阶梯是平滑上升还是垂直起飞。有些平台在"体验版"阶段极其慷慨，等你做第10个应用时才发现，每个应用的运维要另收钱，表单数量也有限制。

一句话总结我的筛选逻辑：功能列表只证明它想做什么，架构、扩展、权限、集成、AI落地方式和成本结构，才说明它实际能把事情做到什么程度。

3. 分梯队拆解：15家标杆厂商的真实底牌与短板

接下来进入正文重头戏。我按产品定位和典型用户群，把这15家分成四个梯队来盘。每家的点评我会尽量压缩到"底牌+短板+适配人群"三个信息点，方便你横向对比。先看总表，再逐家展开。

3.1 一梯队：三驾马车，风格截然不同

厂商A是典型的"老牌大厂"路线，从工作流和表单起家，积累了海量企业客户。它的优势是功能覆盖面极广，你想到的应用类型它基本都有现成模板，实施团队也多，简历一抓一大把，招聘压力小。项目管控类、审批流类、内部管理系统类项目，它的交付确定性很高。

但它的短板恰恰藏在"老"字上。底层数据模型是为流程审批设计的，当你需要构建"以客户为中心"的跨模块数据模型时，往往要通过大量关联表弥补，配置复杂度直线上升。另外它的AI能力更多是"外挂式"的，在原有界面上加了一个聊天窗，尚未做到从模型层就具备AI原生设计。

适配人群：流程驱动、制度明确、需要快速交付大量内部管理系统的传统企业和政企单位。如果你是追求"高确定性"而不是"高自由度"的团队，A是安全牌。

厂商B走的是另一条路——模型驱动。我接触的平台里，B对业务对象建模、关系、状态机、角色权限矩阵的支持是最系统的。它让你先用类似"数据库设计+对象建模"的方式定义业务骨架，然后平台自动生成多端界面。做复杂业务系统时，这种方式的长期维护性远胜表单驱动。

代价是学习曲线陡峭。别说业务人员了，连很多程序员第一次用都会被它的"先建模再建页面"思维绕晕。如果你的团队没有一位能把业务对象理清楚的架构型角色，B平台很可能被用成"高级表单工具"，花了大价钱只发挥了三成能力。界面样式也偏保守，做对外展示型应用会显得不够精致。

适配人群：有专业开发背景、业务逻辑复杂、对数据规范和长期维护性要求高的中大型企业。B选得好是资产，选不好是负担，建议先做一个小而完整的业务对象模型测试题再决定。

厂商C是近年的新贵，从云原生出发，产品理念更接近"用现代前端工程方法做低代码"。它的组件体系灵活，页面渲染性能好，对开发者友好。更重要的是，它的AI能力是内生式的——同一个模型驱动体系内，AI可以直接帮你生成业务对象、建议页面布局、辅助写表达式脚本，而不是单纯做个对话机器人。

短板也很明显：私有化部署的成本弹性很大，很多能力深度绑定自家云生态，如果你们公司是混合云架构或者自建机房为主，部分功能可能用不上或者要加钱。另外它的生态和案例积累毕竟比A/B薄一些，招到资深实施人员的难度更高。

适配人群：云原生架构、开发能力强、愿意接受新工具的互联网和中大型科技企业。C是"能力上限最高，但也最需要团队跟上"的选项。

3.2 二梯队：云平台军备竞赛里的选手

厂商D是某大型云厂商的低代码套件。它的最大优势是"全家桶"——身份认证、对象存储、API网关、消息队列、数据仓库都是现成的，做出来的应用和云服务天然打通，几乎不用操心基础设施。开发速度确实快，尤其是做云上内部工具，体验极佳。

但它的独立性较弱。如果你不想被云厂商全局绑定，或者企业有出海业务、多云部署需求，D的很多能力会变成负担。还有一点，它的计费模式碎片化（计算、存储、流量、API调用分开计价），中小项目还好，规模化以后账单会相当复杂。

厂商E的基因是集成平台，它做低代码的思路是"连接优先"。一个复杂业务流程横跨五六套系统，E的编排能力是几家里最强的，连接器质量普遍较高，对认证协议、字段映射、错误重试的支持远非"能发请求"的级别。如果你的核心痛点是系统孤岛而非应用开发，E的集成中台路线非常有吸引力。

短板是纯界面搭建能力相对弱，UI自由度不如专业低代码厂商，个性化前端体验要求高的场景会吃力。另外它本质是个平台型产品，意义在于长期承载你的集成体系，小团队短期用起来会觉得"杀鸡用牛刀"。

厂商F来自业务中台流派。它不像D那样从云基础设施往下长，而是从企业业务中台的项目经验中提炼出来的低代码产品。对中国式复杂组织、复杂流程、多层级汇报关系的理解很深，做大型集团的管理类系统时，它的组织模型和权限体系几乎是最贴合的。

代价是需要较重的实施服务。F不是"买来就能自己玩"的工具，通常需要厂商或者咨询团队深度参与。如果你希望业务部门自己拖拽开发，F会让你失望；如果你的目标是集团级的统一数字化底座，那它的重反而是优势。

3.3 三梯队：懂行业的玩家，在特定战场里更能打

通用平台追求覆盖广度，垂直平台追求场景深度。第三梯队的厂商各有自己的行业根据地，对不懂行业痛点的人来说，这些平台的模板和配置项会让人觉得"很怪"，但对行业内的人来说，每一条都是多年需求沉淀。

厂商G深耕制造业场景，对工单、巡检、备件、设备台账、生产异常上报这些业务的理解远超通用平台。它的表单和流程预设直接面向车间使用习惯，能快速搭建贴合生产的移动应用。制造业客户选G，实施周期可以比选通用平台缩短一半以上。

缺点是出了制造业，比如让你用它做个电商后台或者内容管理系统，会处处觉得别扭。行业平台的通病是"行业之外皆是荒野"。

厂商H面向金融行业。金融场景的真正门槛不是页面漂亮，而是权限合规、操作留痕、审计追踪、敏感数据脱敏这些治理能力。H在这些方面的默认配置非常完善，做内部信贷审批、合规报送、风险管理类应用，能省掉大量的合规监理工作。

同样的，它的通用性不强，行业外团队用它既不会更高效，还容易因为不理解金融术语而误配置。非金融行业的读者可以直接跳过它，金融行业的读者可以把它当成"快速落地合规应用"的优先选项。

厂商I在教育、公共服务和社区治理场景下了很多功夫。基层工作人员做的门户网站、办事流程、数据上报系统，它提供了大量本地化程度很高的模板，很多配置是"开箱即用"的。

技术底座的迭代速度相对较慢，如果业务涉及高并发（比如大量居民同时在线办理）或者复杂可视化大屏，I的表现会比较吃力。它的优势在于"低门槛解决常见问题"而不是"解决复杂问题"。

厂商J聚焦零售和分销领域。门店管理、订单流转、库存盘点、促销活动配置、导购任务管理，J的模板与零售业务流程深度绑定，实施起来很对路。

短板是定价偏"产品化"，一些定制需求需要走厂商的二次开发流程，协商成本高。如果你只想快速复制行业模板、不想深度定制，J很稳；如果你需要频繁做差异化功能，要提前问清楚定制规则。

3.4 四梯队：开源与自托管阵营，自由与代价的权衡

开源低代码和商业平台的逻辑完全不同。它的诱人之处是没有厂商锁定、数据完全自主、代码可改；代价是很多能力需要自己补，出了问题没有售后，遇到难啃的bug只能靠社区。

厂商K是老牌开源流程引擎项目，工作流能力极其扎实，对复杂流程、会签、或签、条件路由、超时提醒的支持非常成熟。很多商业平台的工作流内核其实都是从K这类项目演化而来的。但K主要解决"流程"这件事，前端界面、数据模型、权限体系需要自己用其他框架补齐，通常适合开发团队把它嵌到自己系统里，作为流程子引擎使用。

厂商L是轻量级开源平台，部署特别简单，一个后端加一个前端就能跑起来，表单、数据表格、简单权限都够用。个人开发者做小工具、内部小团队做轻应用非常顺手，学习成本极低。

它就是"玩具级天花板"，复杂计算、复杂权限、大数据量的性能都会见顶。如果你预估应用只有百人级别使用规模、十几个界面，L会很舒服；一旦要支撑数千人并发，就得考虑商业平台了。

厂商M的开源定位是"集成链"而非完整应用平台，它擅长把多种数据源、多个服务、多套系统串起来做自动化场景。在自动化领域它是社区活跃度很高的项目之一，很多团队用来做定时任务、消息流转、跨系统同步。

M不适合直接构建面向用户的应用界面，你仍然需要一个前端框架来承载交互。它解决的是"数据和任务流动"问题，不是"人机交互"问题。

厂商N走的是"组件库型低代码"路线，提供了极其丰富的前端组件和现成页面模板，开发人员可以在自己熟悉的技术栈内嵌入N的组件体系，快速拼出管理后台、报表看板、数据录入界面。

严格说它不是一个完整的低代码平台，因为它没有配套的数据模型、权限服务和发布运维体系。最适合的场景是做"前端效率工具"：已有系统需要快速补管理端页面时，N很香；从零搭建一套业务系统，还得配N之外的底座。

厂商O是最典型的"内部工具专用"平台，主打用极低成本搭运维工单、值班排班、测试管理、环境申请、发布记录这类流程性小应用。IT团队内部用非常顺手，图形化配置方式一两小时就能上线一个工具。

规模化后的治理能力弱，多部门、多租户、复杂权限矩阵场景它支撑不住。它是个"好用的轻武器"，不是"重炮平台"。适合超过一半需求是自用工具的团队，作为正式平台的补充件使用。

4. 四套选型路线：照着企业画像对号入座

看完15家逐个点评，很多人反而更纠结了——信息过载之后不知道怎么落地。所以这一节我不再按厂商讲，而是按"你处在什么位置"来给路线建议。我把真实选型中常见的企业画像归纳成四条路线，每条给出建议目标、考虑顺序和核心取舍。

4.1 路线一：中大型企业想要统一数字化底座

典型画像：集团型公司，有多个部门、多套系统、复杂的组织权限需求，希望用低代码承载内部管理类应用的长线建设，未来还可能承载部分核心业务。

优先级排序：数据模型能力（厂商B、厂商C）> 权限与治理体系（厂商F、厂商A）> 集成能力（厂商E）> 私有化部署成本（厂商D）。

这条路线最忌讳"从部门小工具开始凑合"——你一开始选了个轻量平台，做到第三个部门就撞上组织模型和权限天花板，被迫迁移的代价远大于一开始就多花预算。我的建议是优先做一次"复杂度演练"：拿一个跨部门、跨系统、包含多种单据流转的业务场景，让候选厂商现场建模实施，而非只看demo。谁的模型能一次说清"组织、角色、数据范围、审批链"四个问题，谁才是底座候选。

4.2 路线二：业务部门自建部门级应用

典型画像：业务团队没有专职数字化队伍，期望运营、销售、人事等岗位能用低代码快速搭自己的小工具，缩短需求排队时间。

优先级排序：上手门槛（厂商L、厂商O、厂商N）> 模板丰富度（厂商J、厂商I）> 价格透明度（厂商L开源免费、厂商O廉价订阅）> 数据权限够用即可。

这条路线最大的敌人不是"功能不够"，而是"没人持续维护"。业务部门自己搭应用，短期很兴奋，半年后原始搭建者调岗，应用就变成没人敢动的黑盒。所以选择这类工具时务必确认两件事：一是平台要有清晰的"应用交接"机制（管理员能完整接手别人的应用配置），二是平台退出成本低——最坏情况下数据能原样导出，应用可以重搭。

个人经验是：部门级应用不要追求一次做全，先搭一个真实小场景跑通，连续使用一个月再逐步扩展。很多部门级项目死于"做了十个界面但核心场景没打通"。

4.3 路线三：软件服务商拿低代码做交付提效

典型画像：外部团队或独立开发者，承接大量中小企业的管理系统、小程序后台、电商管理后台等定制需求，希望用低代码压缩交付周期、减少重复劳动。

优先级排序：扩展与二次开发能力（厂商C、厂商B）> 多租户与白标能力（厂商A、厂商F）> 代码生成质量（厂商C、厂商N）> 客户环境适配能力（厂商K、厂商L自托管路线）。

这个场景里，我强烈建议优先考虑"能自托管、能写代码、能导出工程"的平台。外部项目交付最害怕的就是平台厂商动向波动，AB两家平台都有过客户被原厂收走的情况。如果你接单做生意，起码要做到：项目结束后客户可以拿着完整应用部署到自己服务器，而你不需要为每个客户按月付费。商用授权条款要逐行看，不少开源平台允许商业利用但禁止提供托管服务，或者要求修改代码开放源码，这些都要在接单前算清楚。

4.4 路线四：中小企业预算敏感型自用

典型画像：团队几十到两三百人，预算有限，没有专职IT，需要把合同管理、客户跟进、报销审批这类基础流程线上化。

优先级排序：总成本（优先低订阅费或开源）> 实施速度（模板多、不用培训）> 数据安全底线（至少支持私有化或所在地区数据驻留）> 品牌可靠性（避免选一两年后停止维护的产品）。

这条路线里我最推荐的是"小步快跑 + 渐进升级"：先用厂商L或O这类轻量工具把最痛的一两个场景跑起来，花不了多少钱，也不依赖重实施。等真正用出价值、团队习惯改变之后，再评估是否需要升级到第一二梯队的中端方案。很多中小企业一步到位买了个大平台，结果没人会用也没人维护，最后变成"年度付费的僵尸系统"，这种情况我见得太多了。

四类路线的共同结论只有一个：选型不是选最强的平台，是选和你的组织能力、业务复杂度、预算曲线最匹配的那一个。

5. demo背后看不见的成本：试用前必须问清的五个问题

最后这部分可能是本文最值钱的经验。我在过去几年帮团队评估过的低代码平台不少于二十个，发现"demo阶段一切完美，上线后处处惊喜"是行业普遍现象。为了避免你重蹈覆辙，我把那些"没人主动说、但决定项目成败"的问题整理成了五条，建议你拿着这五条去问每一个候选厂商，参考答案是判断对方专业度的试金石。

5.1 用户数量变化的账单到底怎么算

几乎所有厂商都会说"我们按用户数收费，很透明"。但真实情况往往是：正式用户、匿名用户、审批人、外部访客、只读用户、管理员用户各自的计费口径完全不同。有的平台"审批人"也要算正式用户，某公司一段采购审批链上有七个审批人，结果用户数直接爆了三倍。

我的建议是：拿自己企业真实的用户结构（有多少人登录、多少人审批、多少人只看报表、多少外部人员需要提交表单）做一张表，让销售按这个结构报价，并且明确要求报价单里写明未来增加50个用户、100个用户的价格变化。凡是含糊其辞的，后面大概率有暗坑。

5.2 API调用和附加功能的用量配额

低代码平台的免费档和起步档通常限制API调用次数。如果你做的应用需要和外部系统实时同步，这个小数字很快会用完。更要命的是，如果平台规定"附加应用需要额外购买运行时套餐"，而你预计一年做20个应用，成本就不是线性增长而是台阶式跳跃。

把这些用量指标除以自己团队的月均预期值，再乘以12个月，你才能算出真实的年度运行成本。低于这个精度的预算，都是拍脑袋。

5.3 数据导出和迁移的真实粒度

这是我在第一部分就强调的"逃生通道"，这里再次强调并给出具体的提问方式。"你们的应用导出的对象包括哪些？数据表、视图、流程定义、页面配置、权限配置、定时任务都包含吗？"能导出到什么格式？这些配置导入到另一个实例后，是否需要人工调整？"如果对方回答"主要能导出Excel"或者"我们提供专业技术服务协助迁移"，你一定要把这句话视为最高风险警报。

今天你选平台是因为它的功能，明天你想离开平台一定是因为它的限制。出得去，才是你的资产；出不去，那叫质押品。

5.4 所谓AI功能到底收不收费

AI增强是2026年低代码选型里最容易产生误解的部分。很多厂商在销售阶段会强调"AI赋能"，但你一定要问清楚：

• AI生成页面、AINL2SQL、AI辅助搭建这些能力，是包含在基础订阅里，还是按调用次数另计费；
• 如果另计费，单价是多少，有没有套餐包；
• 生成的AI能力跑在谁的云上，数据会不会被用于模型训练，是否支持关闭数据回传。

真实发生的场景是：某团队购买的低代码平台从7000元/年涨到20000元/年，官方解释是"新增了AI能力需要共享成本"，但实际业务里他们从来没主动用过AI功能。这种"强制搭售"在不少平台已经出现，付款前一定要把AI费用独立列出来问清楚。

5.5 平台的使用人数峰值和性能保障

低代码平台在POC阶段跑的是几十条数据，上线后面对的是几千用户、几百万条数据，性能表现可能完全两样。你要问的不是"并发能力多强"这种销售话术，而是具体场景问题：

• 一个列表页加载10000条记录需要多久？分页怎么处理？
• 复杂报表是实时查询还是预聚合？
• 平台对单表数据量有没有硬限制？
• 私有化部署时，运行环境最低配置是多少？
• 有没有明确的SLA（可用性承诺、响应时间承诺）？

如果对方听了这些问题开始慌了，恭喜你，你找到了真正靠谱的筛选方法。合格平台应该能清晰回答这些问题，或者坦诚告诉你它的性能边界在哪里。答不上来又满口"我们很稳定"的，直接Pass。

6. 写在最后：几次选型项目之后我的一些体会

做了这么多年系统建设和集成工作，关于低代码平台，我最大的体会是：选型这个动作本身，往往比平台本身更能决定项目成败。

很多团队把选型当成"找一个最厉害的工具"，把大量时间花在比较功能列表上，却忽略了三个更根本的问题：

第一个是组织准备度。你们的业务部门真的愿意改变工作方式吗？有没有一个清晰的"第一个吃螃蟹的应用"？如果第一个应用不是大家真正头疼的业务场景，而是IT部门觉得"适合演示"的场景，那项目大概率会烂尾。第二个是治理准备度。买了平台之后，谁负责管理平台本身的主数据规范、权限标准、应用准入制度？没有这套治理规则，低代码平台很快会变成"一堆无法维护的野应用集合"。第三个是长期心态。低代码不是"一次购买终身解决"，它更像一辆车——买回来只是开始，日常驾驶、保养、升级路况，每一步都需要投入。

如果让我给一个最实在的落地建议，那就是：选定两三家备选平台，各自给它们一个小而完整的真实业务场景，比如"跨部门审批 + 外部数据同步 + 权限分级 + 周期报表"，让它们各自在两周内搭建出可运行的应用，然后让自己的业务人员真实试用，再根据试用反馈、成本明细和维护难度做最终决策。这个方法听起来朴素，但比任何厂商演示和第三方评测都更能暴露平台的真实水平。

最终选哪家不重要。重要的是你手里有一份"自己算过的账"、一张"自己验证过的测试题"、和几个"销售最怕被追问的问题"。带着这三样东西去选，不管市场上有多少平台、换多少名字，你都不会再做那个花了大钱、最后只能在论坛里问"怎么迁移出去"的人了。