低代码爆发踩坑记：那些让我熬夜的问题

低代码是近年来最火的技术方向之一，各种低代码平台层出不穷。我们公司也在2020年引入了低代码平台，希望能提高开发效率。但是在实际使用过程中，我们踩了很多坑，有些问题甚至让我熬了好几个通宵才解决。本文记录了我们使用低代码平台过程中遇到的典型问题和解决过程，包括平台选型、定制开发、性能问题、数据集成、运维部署等方面。如果你也在考虑引入低代码平台，希望这篇文章能帮你少踩一些坑。

一、为什么引入低代码

先说说我们为什么要引入低代码平台吧。

我们公司是一家中型企业，业务发展很快，IT部门的需求排期经常排不过来。业务部门提一个需求，往往要等一两个月才能开发完成，业务部门很不满意。

这时候低代码进入了我们的视野。低代码平台的宣传很诱人：不需要写代码或者只需要写很少的代码，通过拖拽的方式就能快速搭建应用，开发效率可以提升5到10倍。业务人员自己就能搭建简单的应用，不需要依赖IT部门。

领导听了很心动，让我们IT部门调研一下低代码平台，看看能不能引入。

我们调研了市面上主流的低代码平台，包括国外的OutSystems、Mendix，国内的宜搭、明道云、氚云、简道云等。每个平台都各有特点，价格也不一样。

最后我们选择了一家国内的低代码平台，主要是因为它的价格比较合理，功能比较全面，而且支持私有化部署，数据安全有保障。

刚开始用的时候确实很兴奋，简单的表单和流程，拖拖拽拽几个小时就能做出来，比传统开发快太多了。但是用了一段时间之后，各种问题就开始暴露了，有些问题甚至让我熬了好几个通宵。

下面就说说我们遇到的那些坑。

二、平台选型的坑

第一个大坑是平台选型。我们在选型的时候，只关注了功能是否齐全、价格是否合理，但是忽略了一些重要的因素，导致后面出了很多问题。

坑1：只看演示，不看实际开发

很多低代码平台的演示都做得非常漂亮，各种功能应有尽有，看起来什么都能做。但是实际用起来才发现，演示中的功能很多都是花架子，真正用的时候各种限制。

比如演示的时候，平台展示了一个很复杂的审批流程，看起来很强大。但是实际用的时候才发现，这个流程只支持固定的审批人，不支持动态的审批人，也不支持复杂的条件分支。我们的业务流程比较复杂，根本满足不了。

所以选型的时候，不能只看销售的演示，一定要拿自己的真实业务场景去试。找一两个最复杂的需求，在平台上实际做一下，看看能不能实现，实现起来是否顺畅。只有真实场景的验证才靠谱。

坑2：忽略了定制能力

低代码平台虽然能快速搭建应用，但是每个企业的业务都有自己的特殊性，总会有一些平台标准功能满足不了的需求，这时候就需要定制开发。

我们选型的时候，觉得平台功能已经很全了，应该不需要太多定制。但是实际用起来才发现，需要定制的地方太多了。比如和我们现有系统的对接、特殊的业务逻辑、个性化的界面等，这些都需要定制开发。

而我们选的这个平台，定制能力比较弱。虽然支持写代码，但是只能用平台提供的脚本语言，API也很有限，很多想做的事情做不了。有些功能只能靠平台厂商来做定制，价格很贵，周期也很长。

所以选型的时候，一定要重点考察平台的定制能力。支持哪些编程语言，API是否完善，能不能调用外部接口，能不能自定义组件，这些都要了解清楚。定制能力弱的平台，前期用起来快，但是后期会遇到很多瓶颈。

坑3：没有考虑长期成本

低代码平台的收费模式很多，有的按用户数收费，有的按应用数收费，有的按服务器收费，有的是一次性买断。我们选型的时候只看了首期的费用，没有考虑长期的成本。

我们选的平台是按用户数收费的，刚开始用户不多，费用还可以接受。但是用了一年之后，用户数翻了几倍，每年的服务费也翻了几倍，成本越来越高。而且如果以后想换平台，数据迁移也是一个大问题，可能会被平台绑定。

所以选型的时候，要算清楚长期的成本。用户数增长之后费用会是多少，定制开发的费用是多少，升级维护的费用是多少，数据能不能导出，能不能方便地迁移到其他平台。这些都要考虑清楚。

三、定制开发的坑

选好平台之后，就开始用了。在定制开发的过程中，我们又遇到了很多坑。

坑4：平台的脚本语言太弱

我们选的平台有自己的脚本语言，用来写业务逻辑。但是这个脚本语言功能很弱，很多常用的功能都没有。

比如不支持复杂的数据结构，只有简单的数组和对象。不支持模块化，所有代码都写在一个文件里，代码多了之后很难维护。调试功能也很差，只能打日志，不能断点调试，出了问题很难排查。

有一次我们要实现一个比较复杂的计算逻辑，用平台的脚本语言写了好几百行代码，调试了很久才调通。如果用Java或者Python来写，可能几十行就搞定了。

后来我们想了一个办法，把复杂的业务逻辑放到外部的微服务里，低代码平台只做前端展示和简单的流程控制，通过API调用外部的微服务来处理复杂逻辑。这样虽然解决了问题，但是架构变复杂了，维护成本也高了。

所以如果你的业务逻辑比较复杂，一定要选脚本语言强大的平台，或者支持用主流编程语言（Java、JavaScript、Python等）开发的平台。

坑5：组件不够用，自定义组件难

低代码平台通常会提供很多现成的组件，比如表单组件、表格组件、图表组件等。但是实际业务中，总会需要一些特殊的组件。

比如我们需要一个可以编辑的表格组件，支持单元格编辑、批量粘贴、数据校验等功能。平台自带的表格组件功能很简单，满足不了需求。我们想自己开发一个自定义组件，但是平台的自定义组件开发文档很不完善，开发门槛很高，而且开发出来的组件在平台里用起来有各种兼容性问题。

最后我们只能妥协，用平台自带的组件，改了业务流程来适应组件的功能。虽然能用，但是用户体验打了折扣。

所以选型的时候，要看看平台的组件库是否丰富，自定义组件是否方便。如果业务需要很多特殊的界面组件，一定要选组件生态好的平台。

坑6：版本管理和协作困难

传统的软件开发有Git等版本管理工具，可以方便地管理代码版本、多人协作、代码审查。但是低代码平台的版本管理和协作功能普遍比较弱。

我们用的平台，应用的配置都是存在平台的数据库里，没有版本管理的概念。改了配置之后，如果想回退到之前的版本，非常困难。多人同时修改同一个应用的时候，还会出现配置冲突的问题，一个人的修改可能会覆盖另一个人的修改。

有一次，两个同事同时修改一个应用，结果一个人的修改被覆盖了，而且找不回来了，只能重新做，浪费了很多时间。

后来我们只能制定规范，同一个应用同一时间只允许一个人修改，修改完之后导出备份。这样虽然避免了冲突，但是开发效率大大降低了。

所以选型的时候，要看看平台的版本管理和多人协作功能是否完善。如果团队比较大，需要多人协作开发，这一点尤其重要。

四、性能问题的坑

低代码平台用起来方便，但是性能问题也是一个大坑。

坑7：数据量大了之后很卡

低代码平台做的应用，在数据量小的时候跑得很流畅。但是数据量大了之后，就会变得很卡。

我们有一个应用，数据量到了几十万条之后，列表页加载要十几秒，查询也要好几秒，用户体验很差。我们排查了很久，发现是平台自动生成的SQL效率很低，没有建合适的索引，而且每次查询都会把所有字段都查出来，不管用不用。

我们想优化SQL，但是平台不支持直接写SQL，只能通过平台的配置来调整。我们加了索引，限制了查询字段，做了分页，但是效果还是不理想。最后只能把这个应用迁移到了传统开发的系统上。

所以如果你的应用数据量很大（比如超过10万条），一定要在选型的时候做性能测试，看看平台在大数据量下的表现。不要只看小数据量下的演示。

坑8：并发量高了之后扛不住

低代码平台通常是多租户架构，多个应用共享一套系统。在并发量不高的时候没问题，但是并发量高了之后，整个平台都会变慢。

我们有一次搞活动，某个应用的访问量突然增大，结果不仅这个应用变慢了，平台上的其他应用也跟着变慢了。因为平台的资源是共享的，一个应用占用了太多资源，其他应用就会受影响。

而且平台的扩展性也不好，不能单独给某个应用扩容，只能整体扩容，成本很高。

所以如果你的应用有高并发的需求，低代码平台可能不太适合。低代码更适合内部管理系统、工作流系统这类并发量不高的应用。

坑9：页面加载慢

低代码平台的页面通常是动态渲染的，页面加载的时候要拉取很多配置，然后动态生成页面。所以页面的首屏加载时间通常比传统开发的页面要长。

尤其是在网络不好的情况下，页面可能要好几秒才能加载出来，用户体验不好。我们做了很多优化，比如开启缓存、压缩资源、使用CDN等，但是效果有限。

所以如果你的应用对页面加载速度要求很高，低代码平台可能满足不了。

五、数据集成的坑

企业里通常已经有很多系统了，低代码平台做的应用需要和现有系统做数据集成，这也是一个大坑。

坑10：API不够完善

低代码平台通常会提供API，用来和外部系统对接。但是很多平台的API不够完善，只能做简单的数据读写，复杂的操作支持不了。

我们需要把低代码平台的数据同步到现有的ERP系统中，但是平台的API不支持批量同步，只能一条一条地调用，效率很低。而且API的权限控制也很粗，不能精细地控制每个接口的权限。

最后我们只能直接读平台的数据库，自己写同步程序。但是直接读数据库有风险，平台升级之后表结构可能会变，同步程序就会出问题。

所以选型的时候，要仔细考察平台的API是否完善，是否支持批量操作，是否有详细的API文档，是否支持webhook等事件通知机制。

坑11：数据迁移困难

用了低代码平台之后，数据都存在平台的数据库里。如果以后想换平台，或者想把数据导出来做分析，会非常困难。

平台的数据表结构很复杂，一个简单的表单，背后可能对应着好几张表，数据之间的关系也很复杂。想把数据完整地导出来，需要搞清楚平台的表结构，工作量很大。

我们就遇到过这个问题，想把一个应用的数据迁移到另一个系统，花了好几天才搞清楚表结构，写了迁移脚本，还花了很多时间验证数据的正确性。

所以选型的时候，要看看平台是否提供方便的数据导出功能，是否支持标准的数据格式，是否有数据迁移的工具。不要被平台绑定了，想走走不了。

六、运维部署的坑

低代码平台的运维部署也有很多坑。

坑12：升级有风险

低代码平台会不断升级，增加新功能，修复bug。但是升级有时候会带来新的问题。

我们有一次升级平台版本之后，发现几个之前正常的应用出了问题，有的页面显示不正常，有的流程走不通了。因为升级之后平台的一些机制变了，导致老应用不兼容。我们紧急回滚了版本，然后逐个排查问题，花了好几天才修复完。

所以升级平台版本的时候，一定要先在测试环境验证，确认所有应用都正常之后，再升级生产环境。而且升级之前一定要做好备份，出了问题可以及时回滚。

坑13：私有化部署运维复杂

我们选的是私有化部署，数据存在自己的服务器上，安全可控。但是私有化部署的运维比较复杂。

平台依赖很多组件，比如数据库、缓存、消息队列、搜索引擎等，部署和维护这些组件需要专业的运维人员。平台升级的时候，这些依赖组件也要跟着升级，很麻烦。

而且平台出了问题，排查起来也很困难，因为平台是黑盒的，我们看不到内部的实现，只能看日志，很多问题还得找厂商的技术支持。

所以如果选择私有化部署，一定要确保自己有足够的运维能力，或者厂商能提供及时的技术支持。否则出了问题会很被动。

坑14：备份和容灾

低代码平台上跑着很多应用，数据很重要，一定要做好备份和容灾。

我们刚开始的时候没有太重视备份，结果有一次服务器出了故障，数据丢了一部分，虽然最后恢复了，但是吓出了一身冷汗。从那以后，我们做了完善的备份方案，每天全量备份，实时同步到备份服务器，定期做恢复演练。

所以不管用什么平台，备份和容灾都是必须的，不能因为是低代码平台就忽视。

七、低代码到底值不值得用

说了这么多坑，可能有人会问，低代码到底值不值得用？

我的答案是：值得用，但是要选对场景，选对平台。

低代码适合的场景：

• 内部管理系统，比如OA、CRM、项目管理等
• 工作流和审批类应用
• 简单的数据录入和展示应用
• 原型验证和MVP开发
• 业务人员自己搭建的简单应用

低代码不适合的场景：

• 高并发、高性能要求的应用
• 大数据量、复杂查询的应用
• 业务逻辑非常复杂的应用
• 对用户体验要求极高的面向消费者的应用
• 需要深度定制和灵活扩展的应用

选对了场景，低代码确实能大大提高开发效率，降低开发成本。我们公司用低代码做了几十个内部管理应用，大部分都很好用，开发效率比传统开发高了很多。

但是对于不适合的场景，不要勉强用低代码，否则后期会遇到很多问题，反而得不偿失。

八、我的建议

最后给正在考虑引入低代码的朋友一些建议。

第一，明确需求和场景。在引入低代码之前，先想清楚你要用它来做什么，你的业务场景是什么样的，数据量多大，并发量多高，需要哪些定制。根据需求来选平台，不要盲目跟风。

第二，充分调研和试用。不要只听销售的介绍，要自己去试用。拿真实的业务场景去试，看看能不能实现，实现起来顺不顺畅。最好能试用一两个月，深入了解平台的能力和限制。

第三，重视定制能力和扩展性。低代码平台不是万能的，总会有需要定制的地方。一定要选定制能力强、扩展性好的平台，否则后期会很被动。

第四，算清楚成本。不要只看首期的费用，要算清楚长期的成本，包括License费用、定制费用、运维费用、升级费用等。还要考虑如果以后想换平台，迁移的成本是多少。

第五，从小处着手。不要一开始就把所有系统都迁到低代码平台上。先从一个简单的、非核心的应用开始，积累经验，验证平台的能力。用好了再逐步推广。

第六，IT部门要转型。引入低代码之后，IT部门的角色会发生变化。不再是所有需求都自己写代码，而是要负责平台的运维、治理、培训，以及复杂需求的定制开发。IT部门要提前做好转型的准备。

九、写在最后

低代码是一个好东西，它让应用开发变得更简单，让更多的人能参与到应用开发中来。但是低代码不是银弹，它有自己的适用范围和局限性。

我们在使用低代码的过程中踩了很多坑，有些坑让我熬了好几个通宵。但是这些坑也让我们对低代码有了更深刻的理解，让我们知道了什么场景适合用低代码，什么场景不适合，怎么选平台，怎么避坑。

现在低代码行业还在快速发展，平台的能力也在不断增强。相信未来低代码会越来越成熟，能解决的问题会越来越多。但是在现阶段，我们还是要理性看待低代码，不要神化它，也不要否定它，根据自己的实际情况做出合理的选择。

希望我们的踩坑经历能给你一些参考，让你在引入低代码的时候少走一些弯路，少熬一些夜。

用一句话结束本文："低代码不是不写代码，而是把代码写在更合适的地方。"愿每一个企业都能找到适合自己的数字化之路。