2020年，低代码（Low-Code）迎来了爆发式增长，越来越多的企业，开始使用低代码平台，快速开发应用，实现数字化转型。我在几个项目中，使用了低代码平台，踩了很多坑，也积累了一些实战经验。今天，就把低代码的踩坑总结和实战经验，分享出来，包括平台选型、适用场景、常见坑、最佳实践等，希望对大家有所帮助。

先说说背景。我所在的公司，这两年，在做数字化转型，需要开发很多内部管理系统，比如，OA、CRM、项目管理、审批流程、数据报表等。这些系统，需求变化快，逻辑不算特别复杂，但数量多，如果，都用传统的方式，从零开始写代码，开发周期长，成本高，维护也麻烦。

后来，我们开始调研低代码平台，希望，能用低代码平台，快速开发这些内部系统，提升开发效率，降低成本。我们调研了很多低代码平台，包括，国外的和国内的，然后，在几个项目中，实际使用了低代码平台，开发了一些应用。

在这个过程中，我们踩了很多坑，也积累了很多实战经验。今天，就把这些经验，分享出来。

一、什么是低代码

在说踩坑经验之前，先简单说说，什么是低代码。

低代码（Low-Code），是一种快速开发应用的方式，通过可视化的界面，拖拽组件，配置参数，就能快速开发出应用，不需要，写大量的代码。低代码平台，通常，提供了可视化的页面设计器、流程设计器、数据模型设计器、报表设计器等，开发者，只需要，拖拽组件，配置参数，就能快速搭建出应用的界面、流程、数据模型、报表等。

低代码的核心价值，是提升开发效率，降低开发门槛，让不懂代码的人，也能开发应用（公民开发者），同时，也能让专业开发者，从重复的编码工作中解放出来，专注于更复杂的业务逻辑。

和低代码相关的，还有无代码（No-Code），无代码，是完全不需要写代码，纯可视化操作，就能开发应用，适合，更简单的场景。低代码，是少量代码，加上可视化操作，适合，中等复杂度的场景。传统开发，是完全写代码，适合，高复杂度的场景。

低代码，不是什么新技术，其实，已经存在很多年了，比如，早期的Access、FileMaker、Salesforce等，都可以算是低代码的雏形。但这两年，随着数字化转型的加速，企业对快速开发应用的需求，越来越大，低代码，才迎来了爆发式增长，成为了一个热门的概念。

二、低代码的适用场景

低代码，虽然很火，但不是，所有场景，都适合用低代码。用对了场景，能大大提升效率；用错了场景，可能，还不如传统开发。

根据我的实战经验，低代码，适合以下场景：

1. 内部管理系统

内部管理系统，比如，OA、CRM、项目管理、审批流程、资产管理、人事管理等，是低代码最适合的场景。这些系统，通常，逻辑不算特别复杂，需求变化快，需要快速上线，而且，对UI的要求，不是特别高。用低代码平台，能快速搭建出这些系统，大大提升开发效率。

我们公司，用低代码平台，开发了好几个内部管理系统，比如，审批流程系统、项目管理系统、资产管理系统等，原来，用传统开发，可能需要一两个月，用低代码，一两周，就搞定了，效率提升非常明显。

2. 表单和流程类应用

表单和流程类应用，比如，调查问卷、报名表单、请假审批、报销审批、合同审批等，也是低代码非常适合的场景。低代码平台，通常，都提供了强大的表单设计器和流程设计器，拖拽组件，配置参数，就能快速搭建出复杂的表单和流程，不需要，写大量的代码。

我们公司，用低代码平台，搭建了很多审批流程，比如，请假、报销、采购、合同等，原来，这些流程，都是用纸质或者Excel，效率很低，用低代码，搭建了线上审批流程，效率提升了很多，也方便了管理和统计。

3. 数据报表和看板

数据报表和看板，也是低代码适合的场景。低代码平台，通常，都提供了强大的报表设计器和看板设计器，连接数据源，拖拽图表组件，配置参数，就能快速生成各种报表和看板，不需要，写大量的前端代码和SQL。

我们公司，用低代码平台，搭建了很多数据报表和看板，比如，销售数据看板、项目进度看板、财务报表等，原来，这些报表，需要开发人员，写SQL，写前端页面，很麻烦，用低代码，业务人员，自己就能拖拽生成，大大提升了效率。

4. 原型和MVP

低代码，也非常适合，做原型和MVP（最小可行产品）。在项目初期，需求不明确，需要快速做出原型，验证想法，用低代码，能快速搭建出原型，给用户试用，收集反馈，快速迭代。等需求明确了，再考虑，要不要用传统开发，重构。

我们公司，有几个新项目，最开始，就是用低代码，快速做出了MVP，给用户试用，收集反馈，验证了想法，然后，再决定，是继续用低代码，还是用传统开发，重构。这样，大大降低了项目的风险，也节省了成本。

5. 中小企业的数字化转型

对于中小企业来说，预算有限，IT人员少，但又有数字化转型的需求，需要开发很多应用，低代码，是一个非常好的选择。低代码，开发效率高，成本低，维护简单，而且，不需要，太多的专业开发人员，业务人员，经过简单培训，就能自己开发应用。

我们公司，有一些子公司，是中小企业，IT人员很少，用了低代码平台之后，业务人员，自己就能开发一些简单的应用，大大提升了数字化转型的效率，也降低了成本。

三、低代码不适合的场景

当然，低代码，也不是万能的，有些场景，不适合用低代码。

1. 高复杂度的核心业务系统

对于高复杂度的核心业务系统，比如，核心交易系统、核心账务系统、高并发的互联网应用等，不适合用低代码。这些系统，业务逻辑非常复杂，性能要求很高，安全性要求也很高，需要，精细的控制和优化，低代码平台，可能，无法满足这些需求，或者，用低代码，反而，更麻烦，性能也不好。

2. 对性能要求极高的应用

对于对性能要求极高的应用，比如，高并发的API服务、实时计算系统、大数据处理系统等，不适合用低代码。低代码平台，因为，有很多封装和抽象，性能，通常，不如手写代码，而且，很难做精细的性能优化。对于性能要求极高的应用，还是，用传统开发，更合适。

3. 对UI和交互要求极高的应用

对于对UI和交互要求极高的应用，比如，面向C端的互联网产品、营销活动页面、游戏等，不适合用低代码。低代码平台，生成的UI，通常，比较标准化，虽然，也能自定义，但很难，做到非常精美的UI和非常流畅的交互。对于对UI和交互要求极高的应用，还是，用传统开发，更合适。

4. 需要深度定制和扩展的应用

对于需要深度定制和扩展的应用，低代码，可能，无法满足需求。低代码平台，虽然，提供了很多组件和功能，但都是，封装好的，如果你需要，深度定制，或者，扩展一些平台不支持的功能，可能，会很麻烦，甚至，无法实现。如果，你的应用，需要很多深度定制和扩展，还是，用传统开发，更灵活。

5. 长期维护和演进的大型系统

对于需要长期维护和演进的大型系统，低代码，可能，会有 vendor lock-in（厂商锁定）的问题，而且，系统大了之后，低代码的可维护性和可扩展性，可能，不如传统开发。如果，你的系统，需要长期维护和演进，而且，规模会越来越大，要慎重考虑，要不要用低代码，或者，考虑，用开源的低代码平台，避免厂商锁定。

四、低代码平台选型

如果，你决定，要用低代码，接下来，最重要的，就是平台选型。低代码平台，很多，国外的，国内的，开源的，商业的，各有各的特点，选对了平台，项目就成功了一半；选错了，可能，会踩很多坑。

根据我的实战经验，低代码平台选型，要考虑以下几个方面：

1. 功能是否满足需求

首先，要考虑，平台的功能，是否满足你的需求。你要列出来，你需要哪些功能，比如，表单设计、流程设计、数据模型设计、报表设计、API集成、权限管理、移动端支持等，然后，看平台，是否支持这些功能，支持的程度如何。

不要，只看平台的宣传，要实际试用，用你的实际需求，去测试平台，看看，能不能满足你的需求。最好，能做一个POC（概念验证），用平台，开发一个小的原型，验证一下，平台的功能，是否满足需求。

2. 易用性和学习成本

低代码的核心价值，是降低开发门槛，提升开发效率，所以，平台的易用性，非常重要。如果，平台很复杂，学习成本很高，需要，专业的开发人员，才能用，那就失去了低代码的意义。

要选择，界面友好，操作简单，学习成本低的平台，最好，业务人员，经过简单培训，就能上手。可以，让业务人员，也参与试用，看看，他们能不能，快速上手，开发简单的应用。

3. 扩展性和灵活性

虽然，低代码，是可视化开发，但很多时候，还是需要，写一些代码，或者，扩展一些功能。所以，平台的扩展性和灵活性，非常重要。

要考虑，平台是否支持，自定义代码，是否支持，自定义组件，是否支持，API集成，是否支持，数据库的直接访问，是否支持，和其他系统的集成。如果，平台的扩展性很差，很多功能，无法实现，或者，实现起来很麻烦，那后期，可能，会遇到很多瓶颈。

4. 性能和稳定性

性能和稳定性，也是平台选型，需要考虑的重要因素。如果，平台性能很差，应用跑起来很慢，或者，经常出问题，不稳定，那用户体验，会很差，也会影响业务。

要测试，平台的性能，比如，大数据量的时候，列表加载快不快，查询快不快，并发用户多的时候，系统稳不稳定。可以，用一些测试数据，压力测试一下，看看，平台的性能和稳定性，是否满足需求。

5. 部署方式和数据安全

部署方式，也是需要考虑的。低代码平台，通常，有几种部署方式：SaaS（云端托管）、私有部署（部署在自己的服务器上）、混合部署。如果，你的数据，比较敏感，或者，有合规要求，需要，数据存在自己的服务器上，那就要选择，支持私有部署的平台。

数据安全，也非常重要。要考虑，平台的数据安全措施，比如，数据加密、权限管理、审计日志、备份恢复等。如果，是SaaS平台，还要考虑，平台的可靠性，数据会不会丢失，会不会泄露。

6. 厂商实力和生态

厂商的实力，也很重要。要选择，有实力的厂商，产品，持续更新，技术支持，及时响应，社区生态，比较完善。如果，厂商实力不行，产品，可能，会停止更新，或者，技术支持，跟不上，后期，会很麻烦。

还要考虑，平台的生态，比如，有没有，丰富的组件市场、模板市场、插件市场，有没有，活跃的社区，有没有，很多的合作伙伴和案例。生态好的平台，用起来，会更方便，遇到问题，也更容易解决。

7. 成本

最后，当然，要考虑成本。低代码平台的收费模式，通常，有几种：按用户数收费、按应用数收费、按服务器配置收费、一次性买断等。要算清楚，总成本，包括，平台费用、实施费用、培训费用、维护费用、扩展费用等，不要，只看表面的价格，有些平台，表面便宜，但后期，扩展和维护，费用很高。

要根据自己的预算和需求，选择，性价比最高的平台，不要，只选贵的，也不要，只选便宜的，适合自己的，才是最好的。

五、低代码常见的坑

说了这么多，接下来，说说，我在使用低代码平台的过程中，踩过的一些常见的坑，大家可以，引以为戒。

1. 过度依赖低代码，什么都想用低代码

这是最常见的坑。很多人，用了低代码之后，觉得，低代码，什么都能做，什么都想用低代码，包括，一些高复杂度、高性能、高定制化的需求。结果，做着做着，发现，低代码，无法满足需求，或者，实现起来，非常麻烦，性能也很差，最后，不得不，推倒重来，用传统开发，浪费了很多时间和精力。

所以，一定要，清楚低代码的适用场景，不要，什么都想用低代码。适合的场景，用低代码；不适合的场景，还是，用传统开发。不要，为了用低代码，而用低代码。

2. 平台选型不慎重，后期才发现不满足需求

很多人，选低代码平台的时候，很草率，看了几篇宣传文章，或者，听了厂商的介绍，就决定用了，没有，做深入的调研和POC。结果，用了一段时间之后，才发现，平台的功能，不满足需求，或者，性能不行，或者，扩展性太差，这时候，想换平台，已经，投入了很多时间和精力，数据和应用，都在平台上，迁移成本很高，进退两难。

所以，平台选型，一定要慎重，要做深入的调研，要做POC，用实际需求，去测试平台，确认，平台能满足你的需求，再决定用。不要，只看宣传，不要，只听厂商说，要实际试用，实际测试。

3. 忽略数据模型设计，后期数据混乱

低代码平台，虽然，是可视化开发，但数据模型，还是，非常重要的。很多人，用低代码的时候，忽略了数据模型的设计，随便建几个表，字段，也不仔细想，就开始做页面和流程。结果，做着做着，发现，数据模型，设计得不合理，很多需求，无法实现，或者，数据混乱，后期，要改数据模型，非常麻烦，已经有的数据，也要迁移。

所以，用低代码，也要，重视数据模型的设计，在项目初期，就要，仔细分析需求，设计好数据模型，表结构、字段、关系、索引等，都要设计好，不要，随便建表。数据模型，是应用的基础，基础打好了，后面，才会顺利。

4. 不写文档，后期维护困难

低代码，因为，是可视化开发，很多人，觉得，不需要写文档，或者，觉得，可视化的东西，一看就懂，不用写文档。结果，过了一段时间，开发人员，换了，或者，需求变了，要修改应用，才发现，根本看不懂，这个应用，是怎么设计的，逻辑是什么，数据模型是什么，修改起来，非常困难，甚至，不敢改，怕改出问题。

所以，用低代码，也要，写文档，数据模型说明、页面说明、流程说明、逻辑说明、接口说明等，都要写清楚。不要，觉得，可视化开发，就不用写文档，文档，是维护的基础，没有文档，后期维护，会非常困难。

5. 不做版本管理，出了问题无法回滚

低代码平台，很多，是在线开发的，修改了，就直接生效了，没有，版本管理的概念。很多人，修改应用的时候，不做备份，不做版本管理，结果，修改出了问题，想回滚，都回滚不了，只能，手动改回去，非常麻烦，甚至，导致，应用不可用，影响业务。

所以，用低代码，也要，做版本管理，每次，大的修改，都要备份，或者，用平台提供的版本管理功能，保存版本。如果，平台不支持版本管理，就要，自己，定期导出应用的配置和数据，做备份，出了问题，能回滚。

6. 忽略权限和安全，导致数据泄露

低代码平台，开发应用，很快，但很多人，忽略了权限和安全。比如，页面的权限，配置得很粗糙，不该看的人，也能看到；数据的权限，没有控制，所有人，都能看到所有数据；接口的权限，没有认证，谁都能调用；数据，没有加密，敏感信息，明文存储。结果，导致，数据泄露，或者，被人篡改，造成，严重的后果。

所以，用低代码，也要，重视权限和安全，页面权限、数据权限、操作权限、接口权限，都要仔细配置，敏感数据，要加密，重要操作，要有审计日志。不要，因为，开发快，就忽略了安全，安全，是应用的底线。

7. 性能问题，后期才发现

很多人，用低代码开发应用的时候，只关注功能，不关注性能，数据量小的时候，跑得很快，没问题。结果，上线之后，数据量越来越大，用户越来越多，才发现，应用很慢，性能很差，用户体验，非常差。这时候，再想优化，就很麻烦了，因为，低代码的性能优化，空间有限，很多时候，只能，改数据模型，改查询，甚至，换平台。

所以，用低代码，也要，关注性能，在开发的时候，就要考虑性能，数据模型，要设计好，索引，要建对，查询，要优化，不要，查全表，不要，关联太多表。上线之前，要用大数据量，测试一下性能，看看，能不能满足需求。不要，等上线了，才发现性能问题。

8. 厂商锁定，后期无法迁移

这是低代码，最大的坑之一。很多低代码平台，是商业的，闭源的，应用，是用平台特有的方式，开发的，数据，也存在平台的数据库里，格式，可能，也是特有的。如果，后期，你想换平台，或者，想用传统开发，重构，会发现，迁移成本，非常高，应用的配置，无法导出，数据，导出了，也很难用，几乎，只能，推倒重来。

所以，在选型的时候，就要考虑，厂商锁定的问题。如果，担心厂商锁定，可以，选择开源的低代码平台，或者，支持导出应用配置和数据的平台，或者，把数据，存在自己的数据库里，不要，存在平台的专属数据库里。这样，后期，想迁移，会容易一些。

六、低代码最佳实践

最后，说说，低代码的最佳实践，根据我的实战经验，做好以下几点，能让低代码项目，更成功。

1. 先做需求分析和数据模型设计

不要，上来就拖拽做页面，先做需求分析，弄清楚，要做什么，业务流程是什么，数据是什么。然后，设计数据模型，表结构、字段、关系、索引，都设计好。数据模型，是基础，基础打好了，后面，才会顺利。

2. 做POC验证平台能力

在正式项目之前，用平台，做一个小的POC，验证一下，平台的功能、性能、扩展性，是否满足需求。不要，直接就上大项目，万一，平台不满足需求，损失就大了。

3. 专业开发和公民开发结合

低代码，不是，只有业务人员能用，专业开发人员，也能用，而且，能发挥更大的作用。最好的方式，是专业开发人员，负责，数据模型设计、复杂逻辑、系统集成、性能优化等，公民开发者（业务人员），负责，简单的页面、表单、报表等。两者结合，既能提升效率，又能保证质量。

4. 重视文档和版本管理

不要，因为，是可视化开发，就不写文档，不做版本管理。文档，要写清楚，数据模型、页面、流程、逻辑、接口等，都要说明。版本管理，要做好，每次大的修改，都要备份，或者，保存版本，出了问题，能回滚。

5. 重视权限和安全

权限和安全，要从一开始，就考虑，页面权限、数据权限、操作权限、接口权限，都要仔细配置，敏感数据，要加密，重要操作，要有审计日志。不要，等出了安全问题，才重视。

6. 关注性能，提前测试

性能，要从一开始，就关注，数据模型，要设计好，查询，要优化，索引，要建对。上线之前，要用大数据量，压力测试，看看，性能是否满足需求。不要，等上线了，才发现性能问题。

7. 做好培训和推广

低代码应用，开发出来，只是第一步，还要，让用户，会用，愿意用。要做好，用户培训，让用户，知道怎么用，有什么好处。还要，收集用户反馈，持续优化，让应用，越来越好用。

8. 评估好，哪些用低代码，哪些用传统开发

最后，也是最重要的，要评估好，哪些需求，适合用低代码，哪些，适合用传统开发。不要，什么都用低代码，也不要，什么都用传统开发。适合的场景，用低代码，提升效率；不适合的场景，用传统开发，保证质量。两者结合，才是最佳的方式。

七、写在最后

低代码，是这两年，非常火的一个概念，它确实，能提升开发效率，降低开发门槛，帮助企业，快速实现数字化转型。但低代码，也不是银弹，不是，什么都能做，也有，自己的适用场景和局限性。

用对了，低代码，能大大提升效率，降低成本；用错了，可能，会踩很多坑，甚至，推倒重来。所以，我们要，理性看待低代码，了解它的优势和劣势，清楚它的适用场景，选对平台，用对方法，才能，真正发挥低代码的价值。

今天，分享了我在使用低代码平台过程中的，踩坑总结和实战经验，包括，什么是低代码、适用场景、不适合的场景、平台选型、常见的坑、最佳实践等。希望，能帮助大家，更好地认识和使用低代码，少踩坑，多受益。

最后，想说的是，技术，是为业务服务的，不管，是低代码，还是传统开发，只要，能解决业务问题，提升效率，降低成本，就是好的技术。我们要，根据业务需求，选择合适的技术，不要，盲目跟风，不要，为了用技术，而用技术。

如果，你也在使用低代码，或者，打算使用低代码，欢迎，在评论区，交流你的经验和看法。