最近低代码很火，各种低代码平台层出不穷，号称"不用写代码就能做应用"。我也跟风试了几个低代码平台，从入门到放弃，经历了不少坑。今天分享一下我的真实体验，低代码到底好不好用，适合什么场景，又有哪些坑。

先说说背景。我是一个前端开发者，平时工作中经常要做一些管理后台、表单页面、数据展示页面。这些页面有很多重复的工作，比如写表单、写表格、写增删改查，很枯燥，也很浪费时间。所以，当低代码平台火起来的时候，我很感兴趣，觉得它可能能帮我提高效率，减少重复劳动。

于是，我花了大概一个月的时间，试用了市面上几个比较主流的低代码平台，包括国外的和国内的，有开源的也有商业的。我试着用这些平台做了几个小应用，包括一个简单的任务管理系统、一个表单收集工具、一个数据看板。在这个过程中，我体验到了低代码的便利，也遇到了很多问题和坑。

今天就把我的经历和感受记录下来，分享给大家。

一、低代码为什么火了？

在说我的经历之前，先说说低代码为什么突然火了。

低代码（Low-Code）的概念其实很早就有了，最早可以追溯到上世纪的快速应用开发（RAD）工具。但最近几年，低代码突然爆发了，主要有以下几个原因：

1. 企业数字化转型的需求

现在很多企业都在做数字化转型，需要大量的应用来支撑业务。但传统的软件开发方式，周期长、成本高、人才稀缺，满足不了企业快速增长的需求。低代码平台号称能让非专业开发者也能快速搭建应用，正好契合了企业的需求。

2. 云原生和前端技术的发展

低代码平台的发展，离不开云原生和前端技术的进步。现在的前端框架（React、Vue等）、组件库、可视化编辑器、云服务、容器化等技术，为低代码平台提供了技术基础。低代码平台可以利用这些技术，提供可视化的拖拽编辑、一键部署、云端运行等能力。

3. 资本的推动

低代码是一个很大的市场，吸引了大量资本的投入。很多低代码公司获得了巨额融资，然后用这些钱来做产品、做市场、做生态，推动了整个行业的发展。

4. "全民开发"的概念

低代码平台主打"全民开发"的概念，号称让业务人员也能自己做应用，不需要依赖IT部门。这个概念很吸引人，很多企业都希望能让业务人员自己解决一些简单的需求，减轻IT部门的压力。

在这些因素的推动下，低代码突然就火了，各种平台层出不穷，各种概念满天飞。作为一个开发者，我也很好奇，低代码到底能不能真的提高效率，能不能替代传统的开发方式。于是，我开始了我的低代码试用之旅。

二、入门：低代码确实很方便

刚开始用低代码平台的时候，我确实被它的便利惊艳到了。

我试用的第一个平台，是一个国外的低代码平台，主打可视化拖拽搭建应用。我注册了一个账号，然后跟着教程，试着做一个简单的任务管理应用。

整个过程非常简单：

  1. 创建一个新应用，选择一个模板（任务管理模板）
  2. 在可视化编辑器里，拖拽组件来搭建页面，比如表单、表格、按钮、图表等
  3. 配置数据模型，定义数据表和字段
  4. 配置业务逻辑，比如点击按钮之后做什么操作，数据怎么流转
  5. 一键发布，平台会自动部署到云端，生成一个可以访问的URL

整个过程，我几乎没有写一行代码，只用了大概一个小时，就做出了一个可以用的任务管理应用，有任务列表、新建任务、编辑任务、删除任务、任务状态管理、简单的数据统计等功能。

说实话，那一刻我是很震撼的。如果用传统的开发方式，做这样一个应用，至少需要一两天的时间，要写前端页面、写后端接口、写数据库、部署上线。但用低代码平台，一个小时就搞定了，而且界面还挺好看，功能也挺完整。

然后我又试了几个其他的低代码平台，有国内的也有国外的，有做通用应用的，也有做专门领域的（比如表单、流程、BI等）。整体体验都差不多，核心都是可视化拖拽、配置化、一键部署，确实很方便，能快速做出简单的应用。

那段时间，我甚至觉得，低代码可能真的会改变软件开发的方式，以后很多应用都不需要专业开发者来做了，业务人员自己就能搞定。我甚至开始担心，作为一个前端开发者，以后会不会失业。

但随着使用的深入，我慢慢发现，低代码并没有想象中那么美好，它有很多局限性和坑。

三、遇到的坑：低代码不是万能的

用了一段时间之后，我开始遇到各种问题，这些问题让我对低代码的看法发生了改变。

坑1：简单的应用很方便，复杂的应用很痛苦

低代码平台做简单的应用确实很方便，比如表单收集、简单的增删改查、数据展示等，拖拽几下就搞定了。但一旦应用变得复杂，比如有复杂的业务逻辑、复杂的页面交互、复杂的数据关系，低代码平台就变得很痛苦了。

比如，我试着用低代码平台做一个稍微复杂一点的审批流程，有多级审批、条件分支、会签、或签、退回、撤回等功能。我发现，低代码平台的流程配置器根本满足不了我的需求，很多复杂的逻辑无法通过配置来实现，只能写自定义代码。但写自定义代码又很麻烦，因为平台有自己的一套API和限制，不能像普通开发那样自由地写代码，调试也很困难。

再比如，我想做一个自定义的图表，平台自带的图表组件满足不了我的需求，我需要用ECharts自己写。但在低代码平台里，插入自定义代码很麻烦，要写在特定的地方，还要遵守平台的规范，而且和平台自带的组件交互也很麻烦。

总之，简单的应用，低代码确实很快；但复杂的应用，低代码反而比传统开发更慢、更痛苦，因为你要在平台的限制里想办法实现需求，很多时候是"带着镣铐跳舞"。

坑2：自定义能力有限，遇到平台不支持的功能就抓瞎

低代码平台为了降低使用门槛，会做很多封装和限制，很多底层的东西是不开放的。这就导致，当你需要实现一些平台不支持的功能时，就会很抓瞎。

比如，我想给应用加一个自定义的登录方式，用企业的SSO登录。但平台只支持自带的用户系统和几种固定的第三方登录，不支持自定义SSO。我研究了很久，发现根本无法实现，除非用平台的企业版，而且还要额外付费，找平台的技术支持来定制。

再比如，我想对数据做一些复杂的查询和统计，平台自带的查询功能满足不了，我需要写SQL。但平台不允许直接写SQL，只能用平台提供的查询构建器，功能很有限。最后，我只能把数据导出来，在外面做统计，很麻烦。

还有，我想自定义页面的样式，做一些特殊的交互效果，但平台的样式定制能力很有限，很多CSS属性不能改，很多动画效果做不了。虽然有些平台支持写自定义CSS，但也有很多限制，不能完全自由地定制。

这些问题，在传统开发中都不是问题，因为你可以完全控制代码，想怎么写就怎么写。但在低代码平台里，你被平台限制住了，很多事情做不了，或者要花很大的代价才能做。

坑3：数据和应用被平台绑定，迁移困难

低代码平台一般都是SaaS模式，你的应用和数据都在平台的服务器上。这就导致，你被平台绑定了，如果以后想换平台，或者想把应用迁到自己的服务器上，会非常困难。

比如，我用某个低代码平台做了一个应用，用了一段时间之后，发现这个平台满足不了我的需求了，想换一个平台。但我发现，我的数据模型、页面配置、业务逻辑，都是平台特有的格式，无法导出成通用的格式，也无法直接导入到其他平台。我只能重新在新平台上做一遍，数据也要手动迁移，很麻烦。

而且，有些平台甚至不允许你导出完整的数据，或者导出的数据格式很奇怪，很难处理。这就意味着，一旦你用了某个低代码平台，你就被它绑定了，很难脱身。如果平台涨价了、停止服务了、或者被收购了，你就会很被动。

这一点，对于企业来说尤其重要。企业的数据是核心资产，如果被低代码平台绑定了，以后想迁移就很困难，而且数据安全也有隐患。

坑4：性能问题，复杂应用会卡

低代码平台为了实现可视化和配置化，会做很多通用的封装，这些封装会带来一些性能开销。简单的应用可能感觉不到，但复杂的应用，尤其是数据量大、页面复杂的应用，就会明显感觉到卡顿。

比如，我做了一个数据表格，有几千条数据，页面上还有很多其他组件。我发现，页面加载很慢，滚动的时候也会卡，操作响应也有延迟。而如果用传统的开发方式，做同样的页面，性能会好很多，因为可以做针对性的优化，比如虚拟滚动、懒加载、分页等。

低代码平台虽然也会做一些性能优化，但因为是通用的，无法针对每个应用做针对性的优化，所以复杂应用的性能往往不如传统开发的好。

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

在传统开发中，我们有Git来做版本管理，有各种协作工具来支持团队协作。但在低代码平台里，版本管理和协作功能往往很弱。

比如，我和同事一起在低代码平台上做一个应用，我们发现很难同时编辑，因为平台不支持多人同时编辑同一个页面，容易冲突。而且，版本管理功能很弱，只能保存几个历史版本，不能像Git那样做分支、合并、diff等。如果改坏了，想回滚到某个版本，也很麻烦。

对于个人开发者或者小团队来说，这些问题可能还能忍受。但对于大团队来说，协作和版本管理是刚需，低代码平台在这方面的不足，会严重影响开发效率。

坑6：学习成本并不低，而且学了只能用在一个平台上

很多人以为低代码不需要学习，拿到手就会用。但实际上，低代码平台也有学习成本，尤其是复杂一点的平台，要学的东西并不少。你需要学习平台的组件、数据模型、逻辑配置、API、部署方式等，还要了解平台的限制和最佳实践。

而且，更坑的是，你在一个低代码平台上学到的东西，只能用在这个平台上，换一个平台就完全没用了。因为每个低代码平台的概念、API、配置方式都不一样，通用性很差。不像传统的编程技能，你学会了JavaScript、React、Node.js，可以在任何项目中使用，换工作也能用。

所以，如果你花了很多时间学习某个低代码平台，以后换了平台，或者平台不行了，你学到的东西就白费了。这对于个人的职业发展来说，是一个很大的风险。

四、放弃：低代码不适合我的场景

用了一个月之后，我最终还是放弃了用低代码平台来做我的主要工作。原因主要有以下几点：

1. 我的工作场景比较复杂

我平时做的项目，大部分是企业级的管理后台和Web应用，业务逻辑比较复杂，页面交互也比较多，对自定义能力和性能要求比较高。这些场景，低代码平台很难满足，用低代码反而效率更低。

2. 我需要完全的控制权

作为一个开发者，我习惯了完全控制代码，想怎么写就怎么写，想怎么优化就怎么优化。但在低代码平台里，我被平台限制住了，很多事情做不了，这种感觉很不舒服。

3. 数据安全和迁移的考虑

我做的很多项目，数据都是比较敏感的，我不希望把数据放在第三方平台上。而且，我也不希望被平台绑定，以后想迁移都困难。

4. 职业发展的考虑

作为一个开发者，我希望我的技能是可迁移的，是有长期价值的。如果我花很多时间去学某个低代码平台，以后这个平台不行了，我的技能就白费了。而传统的编程技能，是有长期价值的，不管技术怎么变，编程的基础能力都是有用的。

所以，最终我还是放弃了用低代码平台来做主要工作，回到了传统的开发方式。但我并不是说低代码完全没用，它在某些场景下还是很有价值的。

五、低代码适合什么场景？

虽然我放弃了用低代码做主要工作，但我并不否认低代码的价值。低代码在某些场景下，确实能大大提高效率，是很有用的工具。我觉得低代码适合以下场景：

1. 简单的内部工具和表单

比如，简单的信息收集表单、问卷调查、请假申请、报销申请、简单的任务管理等。这些应用逻辑简单，不需要太多个性化，用低代码平台很快就能做出来，而且业务人员自己就能做，不需要占用开发者的时间。

2. MVP和原型验证

如果你想快速验证一个想法，做一个最小可行产品（MVP）或者原型，低代码平台是很好的选择。你可以用低代码平台快速做出一个可以用的原型，给用户试用，收集反馈，验证想法是否可行。如果验证通过了，再考虑用传统方式重新开发；如果验证不通过，损失也不大。

3. 中小企业的简单应用

对于中小企业来说，可能没有专业的开发团队，或者开发资源很有限。这时候，用低代码平台来做一些简单的应用，比如客户管理、订单管理、库存管理等，是一个不错的选择。成本低，见效快，不需要专业的开发人员。

4. 业务人员的自助开发

很多时候，业务人员有一些简单的需求，比如做一个数据统计表、一个简单的流程审批，这些需求如果找IT部门做，可能要排很久的队。这时候，业务人员可以自己用低代码平台来做，快速满足自己的需求，不需要依赖IT部门。

5. 非核心系统和临时应用

对于一些非核心的系统，或者临时用一段时间的应用，用低代码平台来做是很合适的。比如，某个活动的报名系统、某个项目的临时协作工具，这些应用用的时间不长，不需要太复杂，用低代码快速做一个就好。

六、低代码不适合什么场景？

相应地，低代码也不适合以下场景：

1. 复杂的企业级应用

业务逻辑复杂、页面交互复杂、数据关系复杂的企业级应用，不适合用低代码。因为低代码平台的自定义能力有限，复杂的逻辑很难实现，而且性能也可能跟不上。

2. 对性能要求高的应用

如果应用对性能要求很高，比如大数据量的处理、高并发的访问、复杂的计算等，不适合用低代码。因为低代码平台有很多通用封装，性能开销比较大，无法做针对性的优化。

3. 需要完全自定义的应用

如果应用需要高度自定义的界面、交互、逻辑，不适合用低代码。因为低代码平台的定制能力有限，很多个性化的需求无法满足。

4. 核心业务系统

企业的核心业务系统，比如ERP、CRM、核心交易系统等，不适合用低代码。因为这些系统很重要，对稳定性、安全性、可扩展性要求很高，而且需要长期维护和迭代。用低代码平台做核心系统，风险太大，而且被平台绑定之后，以后想迁移都困难。

5. 需要深度集成的系统

如果系统需要和很多其他系统做深度集成，比如调用各种第三方API、对接各种内部系统、复杂的数据同步等，不适合用低代码。因为低代码平台的集成能力有限，复杂的集成很难实现。

七、对低代码未来的看法

虽然我自己放弃了用低代码做主要工作，但我对低代码的未来还是比较看好的。我觉得低代码不会取代专业开发者，但它会成为软件开发的一个重要补充，会在很多场景下发挥作用。

未来，低代码可能会朝着以下几个方向发展：

1. 更强大的自定义能力

现在的低代码平台，自定义能力还比较有限。未来，低代码平台可能会提供更强大的自定义能力，比如支持更灵活的代码插入、更开放的API、更丰富的组件市场，让开发者可以在平台的基础上做更复杂的定制。

2. 更好的开发者体验

现在的低代码平台，主要是面向业务人员的，对专业开发者不够友好。未来，可能会出现更多面向专业开发者的低代码平台，或者低代码平台会增加更多开发者友好的功能，比如Git集成、本地开发、调试工具、CI/CD等，让专业开发者也能高效地使用低代码平台。

3. AI和低代码的结合

AI技术的发展，可能会给低代码带来革命性的变化。未来，你可能只需要用自然语言描述你想要的应用，AI就能自动帮你生成应用，包括页面、数据模型、业务逻辑等。这会大大降低应用开发的门槛，让更多人能做应用。

4. 更开放的生态和标准

现在的低代码平台，都是各自为政，没有统一的标准，数据和应用很难迁移。未来，可能会出现更开放的生态和标准，比如统一的应用描述格式、统一的组件标准、数据导出导入标准等，让应用可以在不同平台之间迁移，减少平台绑定的风险。

5. 低代码和传统开发的融合

未来，低代码和传统开发可能会越来越融合，而不是互相替代。比如，一个应用的大部分简单功能用低代码来做，复杂的核心功能用传统代码来写，两者结合起来，各取所长。这样既能提高开发效率，又能保证灵活性和性能。

八、写在最后

回顾我的低代码试用之旅，从最开始的惊艳，到后来的遇到各种坑，再到最终的放弃，我对低代码有了更全面、更理性的认识。

低代码不是银弹，它不能解决所有问题，也不能取代专业开发者。它有它的优势，也有它的局限性。在合适的场景下，它能大大提高效率；但在不合适的场景下，它反而会成为负担。

作为一个开发者，我们应该理性看待低代码，不要盲目跟风，也不要一味排斥。我们应该了解低代码的优势和局限性，在合适的场景下使用它，把它作为我们工具箱中的一个工具，来提高我们的工作效率。

同时，我们也不应该担心低代码会取代我们。因为低代码能做的，只是那些简单的、重复的工作，而复杂的、有创造性的工作，还是需要专业开发者来做。而且，随着低代码的普及，开发者可以从重复劳动中解放出来，去做更有价值、更有创造性的工作。

最后，想说的是，技术在不断发展，新的工具和平台层出不穷。作为开发者，我们应该保持开放的心态，去学习和了解新技术，同时也要保持理性，不要盲目跟风。选择适合自己的工具，解决实际的问题，才是最重要的。

希望我的这些经历和思考，能对大家有所帮助。如果有什么不同的看法，欢迎在评论区交流。