最近这两年，低代码平台越来越火，很多公司都在引入低代码平台，希望能提高开发效率，降低开发成本，让业务人员也能参与开发，解决IT部门人手不足的问题。

我这两年也在项目中用了几款低代码平台，有国内的，也有国外的，有做内部管理系统的，也有做对外业务系统的。用下来的感受是，低代码平台确实能提高开发效率，尤其是做一些表单、流程、报表类的系统，比传统开发快很多，但也踩了不少坑，有些坑还挺深的，差点把项目搞砸。

今天来分享一下低代码平台实战中踩过的坑，以及一些经验和建议，希望能给正在考虑用低代码平台，或者正在用低代码平台的朋友一些参考，少走一些弯路。内容都是我个人的实战经验，不一定适用于所有低代码平台，但很多问题是共性的，希望能给大家一些启发。

一、先说说低代码平台的优势

在说踩坑之前，先说说低代码平台的优势，毕竟它能火起来，还是有很多优点的。

1. 开发速度快

这是低代码平台最大的优势。做一个表单、流程、报表类的系统，用传统开发可能需要几周甚至几个月，用低代码平台，可能几天甚至几小时就能做出来。拖拽式的界面设计，可视化的流程配置，不用写大量的代码，就能快速搭建出一个可用的系统，对于快速验证想法、快速交付项目，非常有帮助。

2. 降低开发门槛

低代码平台不需要写太多代码，很多功能通过拖拽和配置就能实现，业务人员经过简单培训，也能搭建简单的应用，这样就可以让业务人员参与到开发中来，减轻IT部门的压力，也能让系统更符合业务需求。

3. 维护方便

低代码平台一般都有统一的技术栈和架构，升级和维护都比较方便，不需要担心技术栈过时，也不需要专门的运维团队来维护，平台厂商会负责平台的升级和维护。

4. 集成能力强

很多低代码平台都提供了丰富的连接器和API，可以方便地和其他系统集成，比如数据库、企业微信、钉钉、ERP、CRM等，不用自己写大量的集成代码。

这些优势，让低代码平台在很多场景下确实很有价值，尤其是做内部管理系统、OA、审批流程、数据报表这些，低代码平台的优势非常明显。

但是，低代码平台不是银弹，不是什么系统都适合用低代码平台做，用不好的话，反而会踩很多坑，甚至不如传统开发。下面就来说说我踩过的那些坑。

二、坑一：以为什么系统都能做，结果复杂需求做不了

这是我踩的第一个坑，也是很多人刚开始用低代码平台时容易犯的错误。

刚开始用低代码平台的时候，觉得低代码平台很强大，什么系统都能做，拖拽拖拽就能搭出来，于是把一个比较复杂的业务系统，也交给低代码平台来做。结果做到一半，发现很多复杂的业务逻辑，低代码平台实现不了，或者实现起来非常别扭，性能也很差，最后只能返工，用传统开发重新做，浪费了很多时间和人力。

低代码平台，擅长的是表单、流程、报表这类标准化、结构化的系统，对于业务逻辑复杂、交互复杂、性能要求高的系统，低代码平台就不太适合了。比如：

  • 复杂的业务规则引擎，需要大量的自定义逻辑
  • 高并发、高性能的系统，比如电商系统、支付系统
  • 交互复杂的前端页面，比如复杂的可视化、拖拽编辑器
  • 需要深度定制UI和交互的系统
  • 对数据安全和权限有极高要求的系统

这些系统，用低代码平台做，要么做不出来，要么做出来性能很差，要么维护成本很高，反而不如传统开发。

经验和建议：

  • 在选型之前，一定要充分评估需求，看看这个系统是不是适合用低代码平台做。
  • 低代码平台适合做标准化、结构化、业务逻辑不太复杂的系统，比如内部管理系统、OA、审批流程、数据报表、简单的CRUD系统。
  • 对于复杂的业务系统，要谨慎评估，可以先做一个原型验证，看看低代码平台能不能满足需求，再决定要不要用。
  • 不要为了用低代码而用低代码，要根据实际需求选择合适的技术方案。

三、坑二：定制化能力不足，稍微复杂一点的需求就搞不定

这是我踩的第二个坑，也是低代码平台最常见的问题。

低代码平台，虽然提供了很多标准化的组件和功能，但毕竟是平台，不可能满足所有的定制化需求。当业务需求稍微复杂一点，需要一些平台不支持的功能时，就会发现定制化能力不足，要么实现不了，要么需要用很别扭的方式绕过去，维护起来非常痛苦。

我遇到的具体问题有：

  • 某个表单需要一个复杂的联动逻辑，平台的表单组件不支持，只能写JavaScript代码来实现，但平台的自定义代码入口很有限，调试也很困难，写出来的代码很别扭，后续维护的人根本看不懂。
  • 某个列表页需要自定义渲染某一列，平台的列表组件不支持自定义渲染，只能用平台提供的几种格式化方式，满足不了需求，最后只能放弃，改成跳转到详情页查看。
  • 某个流程需要动态的审批人，根据业务数据动态计算，平台的流程引擎不支持这么复杂的逻辑，只能在流程里加很多个条件分支，流程图画得像蜘蛛网一样，非常难维护。
  • 需要对接一个第三方系统，平台没有提供对应的连接器，自己写API对接的时候，发现平台的自定义后端代码能力很弱，很多事情做不了，最后只能单独写一个服务来对接，再和低代码平台集成，架构变得很复杂。

这些问题，单个看都不是大问题，但累积起来，就会让系统变得非常难维护，开发效率也没有提升多少，甚至比传统开发还慢。

经验和建议：

  • 选型的时候，一定要重点评估定制化能力，看看平台支持哪些自定义方式，比如自定义前端代码、自定义后端代码、自定义组件、自定义API等。
  • 要了解平台的扩展机制，是支持写代码扩展，还是只能用平台提供的功能，扩展能力有多强，有没有什么限制。
  • 对于需要大量定制化的系统，要谨慎使用低代码平台，或者选择定制化能力强的平台。
  • 可以采用混合架构，核心的、复杂的业务逻辑用传统开发，标准化的、简单的部分用低代码平台，两者结合，各取所长。

四、坑三：性能问题，数据量大了之后卡得不行

这是我踩的第三个坑，也是低代码平台很容易出现的问题。

低代码平台，为了通用性和易用性，在底层做了很多封装和抽象，这就导致性能往往不如专门开发的系统。数据量小的时候，感觉不出来，一旦数据量大了，比如几万、几十万条数据，就会发现系统卡得不行，列表加载慢，查询慢，导出慢，用户体验很差。

我遇到的具体问题有：

  • 一个列表页，数据量到了五万条左右，加载就需要十几秒，用户抱怨很大，查了一下，发现平台的列表组件没有做分页优化，每次都把所有数据查出来再分页，数据量大了自然就慢。
  • 一个查询功能，用户输入条件查询，需要好几秒才能出结果，查了一下，发现平台生成的SQL语句很不优化，没有走索引，全表扫描，数据量大了就慢。
  • 一个导出功能，导出一万条数据，需要好几分钟，还经常超时失败，用户很不满意，最后只能单独写一个导出服务来处理。
  • 一个流程系统，流程实例多了之后，流程审批也变慢了，点击审批按钮，要等好几秒才有反应，体验很差。

这些性能问题，有些是平台本身的问题，有些是使用不当造成的，但不管是什么原因，最终都会影响用户体验，甚至导致系统不可用。

经验和建议：

  • 选型的时候，要评估平台的性能，看看平台有没有做性能优化，支持不支持分页、索引、缓存这些性能优化手段。
  • 要了解平台的数据量上限，什么样的数据量范围内性能是可以接受的，超过了会怎么样。
  • 在使用的时候，要注意性能优化，比如合理设计数据结构，建立索引，控制单表数据量，分页加载，避免大查询等。
  • 对于数据量大、性能要求高的系统，要谨慎使用低代码平台，或者做好性能测试和优化。
  • 如果平台性能确实满足不了需求，可以考虑把大数据量的部分单独拆出来，用传统开发做，低代码平台只做展示和操作。

五、坑四：数据安全和权限控制不够灵活

这是我踩的第四个坑，对于企业级应用来说，数据安全和权限控制是非常重要的，低代码平台在这方面往往不够灵活。

低代码平台一般都提供了基本的权限控制，比如角色权限、菜单权限、数据权限等，但对于复杂的权限需求，比如行级数据权限、字段级权限、动态权限、跨组织权限等，很多低代码平台就支持得不够好，或者配置起来非常复杂。

我遇到的具体问题有：

  • 一个多租户的系统，需要不同租户的数据完全隔离，平台的多租户支持不够好，需要自己做很多额外的处理，才能保证数据隔离，很容易出安全漏洞。
  • 需要行级数据权限，不同的用户只能看到自己负责的数据，平台的数据权限功能比较弱，只能按部门或者角色过滤，不能按自定义的业务规则过滤，最后只能在每个查询里手动加过滤条件，很容易遗漏，造成数据泄露。
  • 需要字段级权限，不同的角色能看到不同的字段，比如敏感字段只有管理员能看到，平台不支持字段级权限，只能做多个页面，不同角色看不同的页面，维护起来很麻烦。
  • 需要动态权限，根据业务数据的状态，动态控制用户的操作权限，平台的权限模型不支持这么灵活的控制，只能在前端做一些隐藏，后端没有真正的权限校验，有安全隐患。

这些权限问题，对于内部系统来说，可能还能勉强接受，但对于对外的业务系统，或者对数据安全要求高的系统，就是大问题了，一旦出了数据泄露，后果很严重。

经验和建议：

  • 选型的时候，要重点评估平台的权限控制能力，看看支持不支持角色权限、菜单权限、数据权限、字段权限、动态权限等。
  • 要了解平台的安全机制，比如数据隔离、密码加密、传输加密、审计日志等，是否满足企业的安全要求。
  • 对于对数据安全和权限要求高的系统，要谨慎使用低代码平台，或者选择安全能力强的平台。
  • 在使用的时候，要做好权限设计和测试，确保数据安全，不要依赖平台的默认配置，要根据实际需求做定制。
  • 可以在平台外面加一层权限控制，比如用API网关做统一的权限校验，弥补平台权限能力的不足。

六、坑五： vendor lock-in，被平台厂商绑定

这是我踩的第五个坑，也是很多人容易忽略的问题。

低代码平台，本质上是一个封闭的生态，你在平台上做的应用，是运行在平台上的，依赖平台的组件、API、数据结构、部署方式。一旦用了某个低代码平台，就很难迁移到其他平台，甚至很难迁移到传统的架构，因为应用和平台深度绑定，这就是vendor lock-in（供应商锁定）。

我遇到的具体问题有：

  • 在某个低代码平台上做了一个系统，后来因为平台涨价，或者服务不好，想换到另一个平台，发现根本迁不过去，数据结构、页面、流程、逻辑都是和平台绑定的，只能在新平台上重新做一遍，成本很高。
  • 想把低代码平台上的某个功能，拆出来单独部署，或者和其他系统深度集成，发现做不到，因为应用是运行在平台上的，不能单独拆出来，只能通过API和平台交互，性能和灵活性都受限制。
  • 平台厂商的战略调整，比如某个功能不再维护了，或者平台要升级了，导致之前做的应用不能用了，或者需要大量修改，很被动。
  • 平台厂商倒闭或者被收购，服务停止，应用就没法用了，数据也可能拿不出来，风险很大。

这些问题，在选型的时候往往不会考虑，但一旦遇到，就会非常被动，损失很大。

经验和建议：

  • 选型的时候，要考虑平台的开放性，看看平台支不支持数据导出、应用导出、自定义代码部署，有没有标准的API，能不能和其他系统灵活集成。
  • 要了解平台厂商的实力和稳定性，尽量选择大厂商、有实力的厂商，降低厂商倒闭或者战略调整的风险。
  • 要了解平台的定价模式，会不会突然涨价，有没有隐藏费用，避免被厂商绑架后被迫接受高价。
  • 核心的、重要的系统，要谨慎使用低代码平台，避免被绑定后无法迁移。
  • 可以做一些预案，比如定期导出数据备份，了解平台的迁移方案，万一需要迁移，能把损失降到最低。

七、坑六：调试和排错困难，出了问题找不到原因

这是我踩的第六个坑，低代码平台因为做了很多封装，出了问题之后，调试和排错往往比传统开发困难很多。

传统开发，出了问题，可以打日志、打断点、看堆栈，一步步排查，虽然有时候也麻烦，但至少有办法。低代码平台，很多东西是黑盒，你不知道平台内部是怎么运行的，出了问题，只能看到一个错误提示，甚至没有错误提示，就是不好用，不知道是哪里出了问题，排查起来非常痛苦。

我遇到的具体问题有：

  • 一个表单提交的时候报错，提示"系统错误"，没有具体的错误信息，不知道是表单校验的问题，还是后端逻辑的问题，还是平台的bug，只能一个个试，花了大半天时间才找到原因，是某个字段的格式不对，但平台的错误提示太笼统了。
  • 一个流程审批的时候，流程走到一半卡住了，不知道为什么，平台的流程日志很简单，看不出问题，只能联系厂商的技术支持，等了两天才解决，是平台的一个bug。
  • 自定义的JavaScript代码，在平台里运行出错，调试很困难，没有浏览器的开发者工具那么方便，只能alert或者写日志，排查效率很低。
  • 性能问题，不知道是哪里慢了，平台没有提供详细的性能分析工具，只能靠猜，优化起来很盲目。

这些调试和排错的问题，会大大降低开发效率，尤其是遇到平台本身的bug，自己解决不了，只能等厂商修复，很影响项目进度。

经验和建议：

  • 选型的时候，要了解平台的调试和排错能力，看看有没有详细的错误日志、调试工具、性能分析工具等。
  • 要了解厂商的技术支持能力，响应速度怎么样，能不能及时解决问题，有没有社区或者文档可以参考。
  • 在使用的时候，要做好日志记录，尤其是自定义代码的部分，要打详细的日志，方便出问题的时候排查。
  • 要做好测试，充分测试各种场景，尽量在上线前发现问题，避免上线后出问题。
  • 遇到平台的bug，要及时联系厂商技术支持，同时做好 workaround（临时解决方案），避免影响项目进度。

八、坑七：版本升级和维护的坑

这是我踩的第七个坑，低代码平台的版本升级和维护，也有很多坑。

低代码平台是厂商维护的，会不定期升级版本，增加新功能，修复bug。但升级有时候也会带来问题，比如升级后之前做的应用不能用了，或者某个功能变了，需要重新调整。而且，平台的升级时间是厂商决定的，你不能控制，有时候正在项目关键期，平台升级了，导致应用出问题，很被动。

我遇到的具体问题有：

  • 平台自动升级了一个版本，升级后发现某个表单组件的行为变了，之前做的表单不能用了，只能紧急修改，影响了项目进度。
  • 平台升级后，自定义的JavaScript代码有兼容性问题，部分功能不能用了，花了很多时间调试修复。
  • 想回退到旧版本，发现平台不支持回退，只能用新版本，很被动。
  • 平台的某个功能，在新版本里被移除了或者改名了，之前的文档和教程都过时了，找不到相关的资料，只能自己摸索。

这些升级和维护的问题，会增加系统的维护成本，也会带来不确定性。

经验和建议：

  • 选型的时候，要了解平台的升级策略，是自动升级还是手动升级，能不能选择版本，升级频率怎么样，有没有版本回退机制。
  • 要了解平台的版本兼容性，升级后会不会影响已有的应用，厂商有没有做兼容性保证。
  • 平台升级的时候，要先在测试环境验证，确认没有问题再升级生产环境，不要直接升级生产环境。
  • 要关注平台的升级公告和文档，了解新版本的变化，提前做好准备。
  • 重要的系统，要做好备份，万一升级出问题，能快速恢复。

九、低代码平台的正确使用姿势

说了这么多坑，不是说低代码平台不好，而是说低代码平台不是银弹，要用对地方，用对方法，才能发挥它的优势，避免踩坑。

根据我的经验，低代码平台的正确使用姿势是：

1. 选对场景

低代码平台适合做：

  • 内部管理系统、OA、审批流程
  • 简单的CRUD系统、数据录入系统
  • 数据报表、仪表盘、可视化展示
  • 快速原型验证、MVP
  • 标准化、结构化、业务逻辑不太复杂的系统

不适合做：

  • 业务逻辑复杂、需要大量定制的系统
  • 高并发、高性能的系统
  • 对数据安全和权限要求极高的系统
  • 交互复杂、需要深度定制UI的系统
  • 核心的、重要的、不能被绑定的系统

2. 选对平台

选型的时候，要重点评估：

  • 定制化能力：支持不支持自定义代码、自定义组件、自定义API
  • 性能：数据量大了之后性能怎么样，有没有优化手段
  • 权限和安全：权限控制够不够灵活，安全机制完不完善
  • 开放性：能不能导出数据和应用，能不能和其他系统灵活集成
  • 调试和排错：有没有完善的日志和调试工具
  • 厂商实力：厂商稳不稳定，技术支持好不好
  • 定价：定价模式合不合理，会不会突然涨价

不要只看宣传和demo，要实际做一个原型验证，看看能不能满足需求，性能怎么样，再决定。

3. 用对方法

  • 不要为了用低代码而用低代码，要根据实际需求选择合适的技术方案。
  • 可以采用混合架构，简单的、标准化的部分用低代码，复杂的、核心的部分用传统开发，两者结合。
  • 做好设计，即使是低代码平台，也要做好数据结构设计、权限设计、流程设计，不要因为是低代码就随便做。
  • 做好测试和文档，低代码平台做的系统也要充分测试，也要写文档，方便后续维护。
  • 做好备份和预案，定期导出数据备份，了解迁移方案，万一需要迁移，能把损失降到最低。

十、写在最后

低代码平台，是一个好东西，用对了，确实能提高开发效率，降低开发成本，快速交付项目。但它不是银弹，不是什么系统都能做，也不是用了就一定能提高效率，用不好的话，反而会踩很多坑，甚至不如传统开发。

这两年用低代码平台，踩了不少坑，也积累了一些经验，最大的感受就是：要理性看待低代码平台，不要神化它，也不要贬低它，要根据实际需求，选择合适的场景和平台，用正确的方法去使用，才能发挥它的优势，避免踩坑。

最后，希望这篇文章能给正在考虑用低代码平台，或者正在用低代码平台的朋友一些参考，少走一些弯路。也欢迎大家在评论区分享自己用低代码平台的经验和踩过的坑，一起交流学习。