低代码平台选型学习路线：我是怎么入门的

低代码是这两年最火的技术概念之一。Gartner预测，到2024年低代码应用开发将占所有应用开发的65%以上。各种低代码平台层出不穷，国外的OutSystems、Mendix、Microsoft Power Apps、Appian，国内的宜搭、明道云、氚云、简道云、轻流、活字格等，让人眼花缭乱。

面对这么多平台，很多人不知道怎么选，也不知道怎么学。低代码到底是什么？它和传统开发有什么区别？适合什么场景？怎么选平台？怎么学习？这些问题我刚开始接触的时候也很困惑。

我从去年开始接触低代码，先是出于好奇试用了几个平台，后来公司有项目需要，又深入研究和对比了十几个平台，在实际项目中用了几个，踩了不少坑，也积累了一些经验。从最开始的"低代码是什么鬼"，到现在能独立用低代码平台搭建中小型应用，也算是入门了。

本文分享我的低代码平台选型和学习路线，聊聊低代码是什么、适合什么场景、怎么选平台、怎么学习，以及使用低代码的一些心得和建议。希望能给打算入门低代码的朋友一些参考，让你少走弯路。

先说明一下：本文基于我个人的使用经验，主要关注的是面向企业内部应用的低代码平台，不涉及面向消费者的无代码建站工具（比如Wix、凡科等）。不同平台的定位和特点不同，我的体验可能有局限性，仅供参考。

一、低代码是什么，它不是什么

在说选型和学习之前，先搞清楚低代码是什么，它不是什么。很多人对低代码有误解，要么把它神化，觉得它能取代程序员；要么把它贬得一文不值，觉得它就是玩具。

什么是低代码。

低代码（Low-Code）是一种应用开发方式，通过可视化的界面和拖拽式的操作，让开发者用更少的代码、更快的速度构建应用。低代码平台通常提供：

• 可视化的页面设计器，拖拽组件搭建界面
• 可视化的数据模型设计器，不用写SQL就能建表
• 可视化的流程设计器，拖拽搭建业务流程
• 预置的组件和模板，快速搭建常见功能
• 低代码/无代码的逻辑编排，用配置代替编码
• 一键部署和运维，不用关心服务器和基础设施

低代码的核心价值是提高开发效率，降低开发门槛。传统开发一个应用，需要前端、后端、数据库、运维等多个角色，写大量代码，周期长、成本高。用低代码平台，一个开发者甚至业务人员，通过可视化配置，几天甚至几小时就能搭建一个可用的应用。

低代码和无代码的区别。

很多人分不清低代码和无代码，简单来说：

• 无代码（No-Code）：完全不需要写代码，通过纯可视化配置就能搭建应用。适合业务人员、非技术人员，搭建简单的应用（比如表单、数据收集、简单流程）。代表平台：简道云、轻流、Airtable等。
• 低代码（Low-Code）：以可视化配置为主，但在需要的时候可以写代码扩展。适合开发者，搭建更复杂的应用。低代码平台通常提供代码扩展能力，比如自定义组件、自定义函数、API集成、前端代码扩展等。代表平台：OutSystems、Mendix、宜搭、明道云、活字格等。

简单来说，无代码是低代码的子集，低代码包含无代码的能力，同时提供代码扩展能力，能做更复杂的事情。

低代码不是什么。

为了避免误解，也说说低代码不是什么：

1. 低代码不是银弹，不能解决所有问题。 低代码适合某些场景（比如企业内部管理系统、工作流、表单、数据看板），但不适合所有场景（比如高并发的互联网应用、复杂的游戏、对性能要求极高的系统）。不要指望用低代码做所有事情。

1. 低代码不能取代程序员。 很多人担心低代码会取代程序员，我觉得这种担心是多余的。低代码只是提高了开发效率，让开发者从重复的编码中解放出来，专注于更有价值的事情（比如业务逻辑、架构设计、用户体验）。而且，复杂的低代码应用依然需要开发者来搭建和扩展，业务人员能做的只是简单的应用。低代码会改变程序员的工作方式，但不会取代程序员。

1. 低代码不是玩具，它能做生产级的应用。 有些人觉得低代码就是玩具，只能做个demo，不能做生产级的应用。这种看法已经过时了。现在的低代码平台，尤其是国外的OutSystems、Mendix，已经非常成熟，很多世界500强企业都在用它们做生产级的应用，包括核心业务系统。国内的平台也在快速发展，虽然和国外顶尖平台还有差距，但做中小型企业应用已经完全没问题了。

1. 低代码不是零成本，它也有学习曲线和成本。 有些人觉得低代码就是"拖拖拽拽就行，不用学习"，这是误解。低代码虽然降低了开发门槛，但它依然有学习曲线。你需要学习平台的概念、组件、逻辑编排方式、数据模型设计、API集成等。复杂的应用还需要写代码扩展，这就更需要技术能力了。而且，低代码平台通常是收费的，按用户数、按应用数、按流量收费，成本也不低。

理解了低代码是什么、不是什么，我们才能理性地看待它，合理地使用它。

二、低代码适合什么场景，不适合什么场景

选型之前，先搞清楚低代码适合什么场景，不适合什么场景。不要为了用低代码而用低代码，要根据实际需求选择合适的技术方案。

低代码适合的场景。

1. 企业内部管理系统。 这是低代码最适合的场景。比如OA系统、CRM系统、项目管理系统、进销存系统、人事管理系统、财务管理系统等。这些系统的特点是：用户是企业内部员工，并发量不高，业务逻辑相对标准，界面要求不是特别高。低代码平台能快速搭建这些系统，而且容易修改和维护。

1. 工作流和审批流程。 低代码平台通常都有强大的流程引擎，能可视化地搭建审批流程。比如请假审批、报销审批、采购审批、合同审批等。这些流程的特点是：流程节点多，审批规则复杂，需要灵活调整。低代码平台的可视化流程设计器能很好地满足这些需求，而且流程变更时不用改代码，直接在设计器里修改就行。

1. 表单和数据收集。 低代码平台通常都有强大的表单设计器，能快速搭建各种表单。比如调查问卷、报名表、登记表、反馈表等。这些表单的特点是：字段多，验证规则复杂，需要收集和管理数据。低代码平台能拖拽搭建表单，自动生成数据库表，自动做数据验证，还能做数据看板和报表，非常方便。

1. 数据看板和报表。 低代码平台通常都有数据可视化组件，能快速搭建数据看板和报表。比如销售数据看板、生产数据看板、财务报表、运营报表等。这些看板的特点是：需要对接多个数据源，需要各种图表（柱状图、折线图、饼图、地图等），需要实时更新。低代码平台能拖拽搭建看板，对接各种数据源，自动刷新数据，比传统开发快很多。

1. MVP和原型验证。 低代码非常适合做MVP（最小可行产品）和原型验证。当你有一个想法，想快速验证它是否可行，用低代码平台几天就能搭出一个可用的原型，给用户试用，收集反馈。如果验证成功，再考虑用传统开发重构；如果验证失败，损失也不大。这比传统开发几个月才发现方向错了，成本低很多。

1. 遗留系统的扩展和补充。 很多企业有老的遗留系统，功能不够用，但又不想完全重构。这时候可以用低代码平台搭建新的功能，通过API和遗留系统集成，作为遗留系统的扩展和补充。比如老的ERP系统没有移动端，可以用低代码平台搭一个移动端应用，通过API对接ERP的数据。这样成本低，速度快，风险小。

低代码不适合的场景。

1. 高并发的互联网应用。 低代码平台通常是多租户的SaaS架构，性能和并发能力有限。如果你的应用是面向消费者的互联网应用，需要支撑几万甚至几十万的并发，低代码平台可能扛不住。这种场景还是用传统开发，自己掌控基础设施和性能优化。

1. 对性能要求极高的系统。 低代码平台是通用平台，为了通用性做了很多抽象和封装，性能肯定不如专门优化过的传统开发。如果你的系统对性能要求极高（比如毫秒级响应的交易系统、实时计算系统），低代码可能不适合。

1. 高度定制化的用户界面。 低代码平台的UI组件是预置的，虽然可以一定程度上自定义，但自由度有限。如果你的应用需要高度定制化的UI（比如炫酷的营销页面、复杂的3D展示、独特的交互效果），低代码平台可能满足不了，还是用传统前端开发更灵活。

1. 复杂的算法和计算密集型应用。 低代码平台的逻辑编排能力有限，适合做业务流程和数据管理，不适合做复杂的算法和计算密集型的任务。比如机器学习模型训练、大规模数据处理、复杂的科学计算等，这些还是用传统开发，用专门的语言和库来做。

1. 需要完全掌控代码和基础设施的场景。 低代码平台通常是SaaS模式，代码和数据都在平台上，你不能完全掌控。如果你的应用有严格的合规要求（比如金融、医疗、政府），需要数据完全本地化，需要完全掌控代码和基础设施，低代码SaaS平台可能不适合。可以考虑私有化部署的低代码平台，但成本会高很多。

了解了低代码适合和不适合的场景，你就能判断你的需求是否适合用低代码。如果适合，再继续选平台；如果不适合，就不要勉强，用传统开发更合适。

三、低代码平台怎么选：我的选型框架

确定了要用低代码之后，接下来就是选平台。市面上的低代码平台很多，各有特点，怎么选？我总结了一个选型框架，从以下几个维度来评估。

1. 定位和目标用户。

不同的低代码平台定位不同，目标用户不同：

• 面向业务人员的无代码平台：比如简道云、轻流，操作简单，功能相对基础，适合非技术人员搭建简单应用。
• 面向开发者的低代码平台：比如OutSystems、Mendix、活字格，功能强大，提供代码扩展能力，适合开发者搭建复杂应用。
• 面向企业的aPaaS平台：比如宜搭、明道云、氚云，功能全面，集成能力强，适合企业搭建内部管理系统。
• 大厂生态内的低代码：比如Microsoft Power Apps（微软生态）、Salesforce Lightning（Salesforce生态）、宜搭（阿里钉钉生态），适合已经在使用对应生态的企业。

先搞清楚你的团队是什么样的，是业务人员为主还是开发者为主，再选择对应定位的平台。

2. 功能能力。

这是最核心的评估维度。要评估平台的功能是否能满足你的需求：

• 页面设计能力：有哪些UI组件？能不能自定义样式？能不能做响应式布局？支不支持移动端？
• 数据模型能力：能不能可视化建表？支持哪些字段类型？支持表之间的关联吗？支持子表吗？能不能导入导出数据？
• 流程引擎能力：支不支持可视化流程设计？支持哪些流程节点（审批、条件、并行、子流程等）？支持流程变量吗？支持流程撤回、退回、加签吗？
• 逻辑编排能力：怎么做业务逻辑？是纯配置还是可以写代码？支持哪些逻辑（条件判断、循环、变量、函数等）？
• 集成能力：支不支持API调用？能不能对接第三方系统？支持哪些数据源（MySQL、Oracle、SQL Server等）？支不支持Webhook？
• 报表和看板能力：有哪些图表组件？支持哪些数据源？能不能做交叉表、透视表？能不能导出报表？
• 权限管理能力：支持哪些权限粒度（角色、部门、字段、行级）？支持数据权限吗？支持单点登录（SSO）吗？

把你的需求列出来，一条条对照平台的功能，看是否满足。注意不要只看官方的功能列表，要实际试用，因为很多功能看起来有，但实际用起来体验很差。

3. 易用性和学习曲线。

低代码的核心价值之一是降低开发门槛，所以易用性很重要。评估：

• 界面是否直观，操作是否简单
• 有没有完善的文档和教程
• 有没有活跃的社区和论坛
• 有没有官方的培训和认证
• 新手能不能在几小时内搭出一个简单应用
• 复杂功能的学习成本高不高

建议实际注册一个账号，跟着官方教程做一个小应用，感受一下平台的易用性。如果一个平台，你花了一天都搞不清楚怎么用，那它的学习曲线就太陡了，不适合你的团队。

4. 扩展性和灵活性。

低代码平台虽然以可视化配置为主，但复杂的应用往往需要代码扩展。评估：

• 支不支持自定义代码（前端JS、后端代码）
• 支不支持自定义组件
• 支不支持自定义函数和插件
• 支不支持API扩展
• 代码扩展的方式是否友好（是在平台里写，还是需要本地开发再上传）
• 扩展能力有没有限制（比如只能用特定的API，不能完全自由开发）

如果你的应用比较复杂，或者未来可能会变复杂，一定要重视扩展性。一个扩展性差的平台，前期用着爽，后期遇到平台做不了的功能，就会非常痛苦，要么放弃低代码重构，要么用各种hack的方式勉强实现，维护成本很高。

5. 部署方式和数据安全。

评估平台的部署方式和数据安全能力：

• 是SaaS模式还是支持私有化部署
• 数据存在哪里，是否支持数据导出
• 有没有安全认证（ISO27001、等保等）
• 数据备份和恢复机制
• 权限和审计能力
• 能不能满足你的行业合规要求

如果是企业内部应用，数据安全很重要。尤其是金融、医疗、政府等行业，有严格的合规要求，可能需要私有化部署。这时候就要选支持私有化部署的平台，虽然成本高，但能满足合规要求。

6. 性能和稳定性。

评估平台的性能和稳定性：

• 页面加载速度
• 数据查询速度（尤其是大数据量的时候）
• 并发能力
• 平台的可用性（SLA）
• 历史上有没有大的故障
• 大表单、大数据量的时候会不会卡

可以在试用的时候，导入一些测试数据（比如几万条），测试一下查询和列表的性能。如果几万条数据就卡得不行，那这个平台的性能就有问题，不适合数据量大的应用。

7. 成本和商业模式。

低代码平台的收费模式各不相同，要算清楚成本：

• 按用户数收费（每个用户每月多少钱）
• 按应用数收费（每个应用多少钱）
• 按资源收费（存储、流量、API调用次数）
• 一次性买断还是订阅制
• 私有化部署的费用
• 有没有免费版或试用版
• 隐性成本（培训、实施、定制开发等）

成本要算长期的，不要只看第一年。有些平台入门便宜，但用户数多了之后成本很高；有些平台前期贵，但长期来看更划算。根据你的应用规模和用户数，算一下3-5年的总成本，再做选择。

8. 厂商实力和生态。

评估厂商的实力和生态：

• 厂商的规模和融资情况
• 产品的发展历史和更新频率
• 有没有大客户案例
• 合作伙伴生态（有没有咨询公司、实施伙伴）
• 第三方应用市场（有没有现成的应用和组件可以用）
• 社区活跃度

选低代码平台是一个长期决策，要用很多年，所以厂商的实力很重要。如果厂商经营不善倒闭了，或者产品停止更新了，你的应用就麻烦了。尽量选实力强、产品成熟、生态好的厂商。

四、主流低代码平台简介

下面简单介绍一些主流的低代码平台，帮你有个初步了解。注意，这只是基于我个人体验的简单介绍，不构成购买建议，具体选型请自行试用和评估。

国外平台。

1. OutSystems：公认的低代码领域领导者，功能最强大，扩展性最好，能做非常复杂的企业级应用。适合开发者和大型企业。缺点是价格贵，学习曲线陡，国内访问速度一般。

1. Mendix：另一个领导者，和OutSystems齐名，功能强大，建模能力强，支持云原生部署。适合开发者和中大型企业。缺点也是价格贵，国内生态一般。

1. Microsoft Power Apps：微软的低代码平台，和Office 365、Azure、Dynamics深度集成。如果你已经在用微软生态，Power Apps是很好的选择。优点是集成能力强，价格相对便宜；缺点是功能相对OutSystems/Mendix弱一些，复杂应用扩展性有限。

1. Appian：主打BPM（业务流程管理）的低代码平台，流程引擎非常强大。适合流程驱动的企业应用。缺点是价格贵，国内用的人不多。

1. Salesforce Lightning：Salesforce的低代码平台，和Salesforce CRM深度集成。如果你已经在用Salesforce，这是很好的选择。缺点是离开Salesforce生态就没什么优势了，价格贵。

国内平台。

1. 宜搭：阿里钉钉的低代码平台，和钉钉深度集成。如果你公司用钉钉，宜搭是很好的选择，组织架构、消息通知、审批都能和钉钉打通。优点是集成能力强，价格相对便宜，易用性不错；缺点是离开钉钉生态优势不明显，复杂应用的扩展性有限。

1. 明道云：国内较早做低代码的平台之一，功能比较全面，数据建模、流程、报表、API集成都不错。支持私有化部署。适合中小企业搭建内部管理系统。优点是功能均衡，文档完善，社区活跃；缺点是UI相对朴素，超复杂应用的扩展性一般。

1. 简道云：帆软旗下的无代码/低代码平台，主打表单和数据收集，报表能力强（毕竟帆软是做报表出身的）。适合业务人员搭建数据收集、简单管理应用。优点是易用性好，报表能力强，价格便宜；缺点是复杂应用的能力有限，代码扩展弱。

1. 氚云：阿里投资的低代码平台，和钉钉也有集成。功能比较全面，适合企业内部管理应用。优点是和钉钉集成不错，价格适中；缺点是产品体验一般，社区活跃度一般。

1. 轻流：主打流程管理的无代码平台，流程引擎不错，易用性好。适合流程驱动的简单应用。优点是易用性好，流程能力强；缺点是复杂应用能力有限，数据建模能力一般。

1. 活字格：葡萄城旗下的低代码平台，定位是开发者低代码，提供较强的代码扩展能力，支持私有化部署。适合开发者搭建复杂的企业应用。优点是扩展性强，性能不错，支持私有化；缺点是易用性一般，学习曲线陡，生态一般。

1. 腾讯微搭：腾讯的低代码平台，和微信生态、腾讯云集成。适合做微信小程序和企业内部应用。优点是和微信生态集成好，价格便宜；缺点是产品还在快速发展中，功能相对不够成熟。

以上只是部分主流平台，还有很多其他平台（比如ClickPaaS、黑帕云、Treelab、飞书多维表格等），就不一一列举了。建议根据你的需求，选3-5个平台实际试用，对比之后再做决定。

五、我的低代码学习路线

选好平台之后，接下来就是学习了。很多人拿到低代码平台，不知道从何学起，东看看西看看，学了很久还是不会做复杂应用。我总结了一个学习路线，按这个路线学，能比较系统地掌握低代码开发。

第一阶段：入门（1-2周）。

目标：了解平台的基本概念，能搭建简单的表单和列表应用。

学习内容：

1. 注册账号，熟悉平台界面和基本操作
2. 跟着官方入门教程，做一个最简单的应用（比如待办事项、联系人管理）
3. 学习数据模型设计：怎么建表，有哪些字段类型，怎么设置字段属性
4. 学习页面设计：怎么用拖拽方式搭建表单页和列表页，常用组件有哪些
5. 学习基本的权限设置：怎么创建角色，怎么给角色分配权限
6. 学习数据的导入导出

实践任务：搭建一个简单的图书管理应用，包含图书信息的增删改查、分类管理、简单的借阅记录。

这个阶段的重点是熟悉平台的基本操作，建立对低代码的感性认识。不要追求做复杂的东西，先把基础打牢。

第二阶段：进阶（2-4周）。

目标：能搭建有业务逻辑和流程的中等复杂度应用。

学习内容：

1. 深入学习数据模型：表之间的关联（一对一、一对多、多对多）、子表、数据校验规则、公式字段
2. 学习业务逻辑编排：条件判断、变量、循环、函数调用，怎么用可视化方式实现业务逻辑
3. 学习流程引擎：怎么设计审批流程，流程节点、流程变量、流程规则（条件分支、并行、子流程），流程的撤回、退回、加签
4. 学习页面进阶：自定义页面、多页面应用、页面之间的跳转和传参、组件的高级属性和事件
5. 学习报表和看板：怎么用图表组件做数据看板，怎么做交叉表和透视表，怎么配置数据刷新
6. 学习权限进阶：数据权限（行级权限、字段级权限）、部门和角色的配合、自定义权限规则
7. 学习消息通知：怎么配置站内信、邮件、短信通知，怎么在流程中触发通知

实践任务：搭建一个请假审批系统，包含请假表单、多级审批流程、请假余额管理、请假记录查询、请假统计看板。

这个阶段是低代码开发的核心，掌握了这些，就能应对大部分企业内部应用的需求。要多动手实践，在做项目的过程中学习，比单纯看教程效果好很多。

第三阶段：高级（1-3个月）。

目标：能搭建复杂应用，能做系统集成和代码扩展。

学习内容：

1. 学习API集成：怎么调用第三方API，怎么把平台的数据通过API暴露出去，怎么做身份认证，怎么处理API错误
2. 学习Webhook：怎么配置Webhook，怎么接收第三方系统的事件通知
3. 学习代码扩展：怎么用平台支持的语言（通常是JavaScript）写自定义逻辑，怎么扩展前端组件，怎么写自定义函数
4. 学习数据库操作：怎么直接操作数据库（如果平台支持），怎么写复杂查询，怎么做数据迁移
5. 学习性能优化：大数据量下的查询优化、列表分页优化、缓存使用、避免N+1查询
6. 学习应用架构：怎么设计复杂应用的模块划分、数据模型、权限体系，怎么避免技术债
7. 学习运维和部署：应用的发布、版本管理、备份恢复、监控告警、用户管理
8. 学习最佳实践：平台官方的最佳实践文档，社区里的经验分享，常见问题和解决方案

实践任务：搭建一个完整的项目管理系统，包含项目管理、任务管理、团队协作、工时统计、项目看板、甘特图、和第三方系统的API集成（比如对接钉钉/企业微信的组织架构和消息通知）。

这个阶段需要深入理解平台的能力边界，知道什么能做、什么不能做、怎么做最好。遇到平台做不了的功能，要学会用代码扩展或者API集成的方式解决。这个阶段的学习是无止境的，需要在实际项目中不断积累经验。

学习建议。

1. 做中学，不要只看教程。 低代码是实践性很强的技能，光看教程不动手，学了也会忘。一定要边学边做，在实际项目中遇到问题、解决问题，这样才能真正掌握。

1. 从简单的应用开始，逐步增加复杂度。 不要一开始就想做一个大而全的系统，先从简单的应用开始，比如待办事项、联系人管理，熟悉基本操作之后，再做更复杂的应用。循序渐进，基础才扎实。

1. 善用官方文档和社区。 遇到问题，先查官方文档，大部分问题文档里都有答案。文档里没有的，去社区论坛提问，或者搜索别人的经验分享。不要自己闷头想，善用资源能少走很多弯路。

1. 研究别人做的应用。 很多低代码平台有应用模板或者应用市场，可以下载别人做的应用来研究，看别人是怎么设计数据模型、怎么编排逻辑、怎么设计页面的。研究优秀的应用，是提高低代码能力的好方法。

1. 不要局限于低代码本身。 低代码只是工具，要做好应用，还需要很多其他知识：数据库设计、业务建模、用户体验设计、系统架构、API设计等。这些知识是通用的，不管用不用低代码都需要。平时多学习这些基础知识，用低代码的时候才能游刃有余。

六、使用低代码的心得和建议

最后，分享一些我使用低代码的心得和建议，都是踩坑踩出来的经验。

1. 数据模型设计是核心，一定要花时间做好。

低代码应用的核心是数据模型，数据模型设计得好，后面的页面、流程、逻辑都好做；数据模型设计得不好，后面会处处受限，甚至要推翻重来。

做数据模型之前，先理清楚业务需求，有哪些实体，实体之间是什么关系，每个实体有哪些字段。可以先在纸上或者用建模工具画ER图，想清楚了再在平台里建表。

不要边做边改数据模型，改数据模型的成本很高，已经做的页面和逻辑可能都要改。前期多花点时间把数据模型设计好，后期能省很多事。

2. 不要过度追求无代码，该写代码的时候就写代码。

有些人用低代码，追求完全不写代码，什么都想用可视化配置实现，结果绕了很大的弯，做出来的东西还不好维护。

低代码的核心是"低代码"，不是"无代码"。平台提供可视化配置，是为了提高效率，不是让你完全不写代码。遇到可视化配置做不了或者做起来很麻烦的功能，该写代码就写代码，几行代码就能解决的问题，不要用几十个配置节点去绕。

当然，写代码也要适度，不要什么都写代码，那就失去用低代码的意义了。把握好平衡，可视化配置能高效解决的就用配置，配置解决不了的就用代码。

3. 做好版本管理和备份。

低代码应用也是软件，也要做好版本管理和备份。很多低代码平台有版本管理功能，可以发布版本、回滚版本，一定要用好这个功能。每次大的改动之前，先发布一个版本，万一改坏了可以回滚。

另外，重要的数据要定期导出备份，不要完全依赖平台。虽然平台通常会做备份，但自己手里有备份更安心。尤其是用SaaS平台的时候，数据不在你手里，更要定期导出备份。

4. 注意性能，不要等慢了才优化。

低代码平台虽然帮你屏蔽了很多底层细节，但性能问题依然存在。数据量大了、查询复杂了、页面组件多了，都会变慢。

不要等应用慢得用不了了才优化，在开发的时候就要注意性能：

• 列表页一定要分页，不要一次加载几万条数据
• 不要在列表页做太多关联查询，避免N+1问题
• 数据量大的表要建索引（如果平台支持）
• 页面不要放太多组件，尤其是复杂组件（图表、子表等）
• 复杂的计算和数据处理，尽量在后台做，不要在前端做
• 定期清理无用的数据，避免数据量无限增长

5. 重视用户体验，不要做出来的东西没人用。

很多人用低代码做应用，只关注功能能不能实现，不关注用户体验，结果做出来的东西功能有了，但难用得很，用户不愿意用，最后项目失败了。

低代码平台的UI组件虽然是预置的，但还是可以做一定的用户体验优化：

• 页面布局要合理，常用功能放在显眼的位置
• 表单字段要分组，不要一长串字段堆在一起
• 操作流程要简洁，能一步完成的不要分三步
• 要有必要的提示和反馈，用户操作之后要知道成功还是失败
• 移动端体验也要考虑，现在很多人用手机办公
• 做出来之后给真实用户试用，收集反馈，持续优化

用户体验好的应用，用户才愿意用，应用才有价值。否则功能再强，没人用也是白搭。

6. 评估好平台的能力边界，不要硬做平台不擅长的事情。

每个低代码平台都有自己的能力边界，有些事情它擅长，有些事情它不擅长。不要硬做平台不擅长的事情，否则会非常痛苦。

比如，有些平台不擅长做复杂的前端交互，你非要用它做一个炫酷的单页应用，那就会很痛苦，做出来效果也不好。这种情况，不如用传统前端开发做前端，低代码做后端和管理后台，各取所长。

再比如，有些平台不擅长处理大数据量，你非要用它做一个几百万条数据的分析系统，性能肯定不行。这种情况，不如用专门的大数据工具做分析，低代码做数据录入和简单查询。

了解平台的能力边界，在它擅长的领域用它，不擅长的领域用其他技术补充，这样才能发挥低代码的最大价值。

7. 不要被平台锁定，做好迁移的准备。

用低代码平台，最大的风险之一是被平台锁定。你的应用、数据、逻辑都在平台上，如果哪天平台涨价了、停止服务了、或者你想换平台了，迁移成本会非常高。

怎么降低被锁定的风险？

• 选平台的时候，优先选支持数据导出、支持API访问的平台，这样至少数据能拿出来
• 重要的数据定期导出备份，不要完全依赖平台
• 复杂的业务逻辑，尽量用通用的方式实现，不要过度依赖平台特有的功能，这样迁移的时候成本低一些
• 如果是大型企业，关键应用可以考虑支持私有化部署的平台，至少基础设施在自己手里
• 不要把所有应用都放在一个平台上，可以多平台组合使用，降低单一平台的风险

当然，完全避免被锁定是不可能的，用任何技术栈都有迁移成本。但至少要有这个意识，做好准备，万一需要迁移的时候不会手足无措。

七、写在最后

低代码是一个很有前景的方向，它正在改变应用开发的方式。它不是银弹，不能解决所有问题，也不能取代程序员，但在合适的场景下，它能大大提高开发效率，降低开发成本，让更多人能参与到应用开发中来。

我从最开始的"低代码是什么鬼"，到现在能独立用低代码平台搭建中小型应用，一路走来踩了不少坑，也收获了很多。最大的感受是：低代码的核心不是"不用写代码"，而是"用更少的代码做更多的事情"。它把开发者从重复的编码中解放出来，让我们更专注于业务逻辑和用户体验。

如果你是开发者，不要排斥低代码，去了解它、试用它，把它当成你的工具库中的一个新工具。在合适的场景下用它，能大大提高你的工作效率。

如果你是业务人员，低代码给了你自己搭建应用的能力，不用再排队等IT部门开发。但也要认识到，低代码虽然降低了门槛，但做好应用依然需要学习和思考，不是随便拖拖拽拽就能做好的。

本文分享了我的低代码平台选型和学习路线，以及一些使用心得。希望能给打算入门低代码的朋友一些参考。低代码这个领域还在快速发展，新的平台、新的功能不断涌现，我的经验可能很快就会过时。最重要的还是自己去试用、去实践、去总结，找到适合自己的平台和方法。

最后用一句话结束本文："工具是为人服务的，不要为了工具而工具。"低代码只是一个工具，重要的是用它解决实际问题，创造价值。愿我们都能善用工具，做有价值的事情。