无代码平台这两年很火，我们公司也引入了一个无代码平台，让业务人员自己搭建应用。但是有一天，无代码平台上的一个应用出了Bug，导致业务无法正常进行。这个Bug非常诡异，我排查了整整一夜才找到原因。本文记录了这次故障的完整排查过程，包括问题的现象、排查的思路、遇到的困难、最终的原因，以及我们总结的经验教训。如果你也在用无代码平台，希望这篇文章能给你一些参考。

一、背景：我们的无代码平台使用情况

先说说我们公司使用无代码平台的背景吧。

我们公司是一家中型企业，业务部门很多，每个部门都有各种管理需求。以前这些需求都要找IT部门开发，但是IT部门的排期很长，业务部门等不及。

后来我们引入了一个无代码平台，让业务人员自己通过拖拽的方式搭建简单的管理应用，比如数据录入、审批流程、报表展示等。这样简单的需求业务部门自己就能搞定，不需要找IT部门，大大提高了效率。

IT部门负责无代码平台的运维和技术支持，业务人员在使用过程中遇到技术问题，或者需要做一些复杂的定制，就找IT部门帮忙。

用了一段时间之后，无代码平台上已经有几十个应用了，覆盖了各个部门的各种业务场景。大部分应用都运行得很稳定，但是偶尔也会出一些问题。

这次出问题的是销售部门的一个客户管理应用。这个应用是销售部门自己搭建的，用来管理客户信息、跟进记录、订单数据等。销售部门每天都要用这个应用，是一个比较核心的业务系统。

二、故障发生：一个周四的晚上

那是一个周四的晚上，我本来已经下班了，正在家里吃饭。突然接到了销售部门负责人的电话，说客户管理应用出问题了，所有销售都无法正常使用，让我赶紧看看。

我赶紧打开电脑，远程连接到公司的系统，开始排查问题。

问题现象

销售部门反馈的问题是：在客户管理应用中，点击"保存"按钮的时候，有时候能保存成功，有时候保存失败，而且没有任何错误提示，就是点击之后没反应。

这个问题不是必现的，大概有30%的概率会出现。而且不是所有用户都遇到，有的用户遇到的多，有的用户一次都没遇到。

这种非必现的问题最头疼了，因为很难稳定复现，排查起来很困难。

初步判断

我首先想到的可能是网络问题，或者是浏览器兼容性问题。因为无代码平台的应用是Web应用，网络不好或者浏览器不兼容都可能导致保存失败。

但是销售部门说，他们用的都是公司统一配置的电脑和浏览器，网络也是公司内网，以前一直没问题，就今天晚上突然出现的。而且有的用户在同一个办公室，网络环境一样，但是有的遇到问题有的不遇到，所以应该不是网络或浏览器的问题。

我又想到可能是无代码平台的服务出问题了。我登录到无代码平台的管理后台，看了一下服务状态，显示一切正常，没有报错，CPU、内存、磁盘都正常。其他应用也都正常，只有这个客户管理应用有问题。

这就更奇怪了，如果是平台的问题，应该所有应用都受影响才对。为什么只有这一个应用有问题呢？

三、排查过程：漫长的一夜

接下来就是漫长的排查过程了，我从晚上8点一直排查到第二天早上6点，整整一夜。

第一步：查看平台日志

我首先查看了无代码平台的日志，看看保存操作的时候有没有报错。

但是日志里什么都没有，没有错误，没有异常，甚至连保存操作的请求记录都没有。这说明保存请求根本没有到达服务器，或者在到达服务器之前就失败了。

这就排除了服务器端的问题，问题应该出在前端，也就是浏览器端。

第二步：检查前端代码

无代码平台的应用是平台自动生成的前端代码，业务人员不需要写代码。但是作为IT支持，我可以查看平台生成的前端代码。

我打开浏览器的开发者工具，查看保存按钮的点击事件。发现保存按钮绑定了一个JavaScript函数，这个函数会收集表单数据，然后通过AJAX请求发送到服务器。

我仔细看了这个函数的代码，逻辑看起来是正常的，没有明显的问题。但是我注意到一个细节：这个函数在发送请求之前，会先做一个数据校验，如果校验不通过，就直接返回，不发送请求。

会不会是数据校验出了问题？比如某些数据不符合校验规则，导致校验不通过，函数直接返回了，所以没有发送请求，也没有错误提示？

第三步：调试数据校验

我在数据校验的地方加了断点，然后让销售同事操作，复现问题。

复现了几次之后，我发现了一个规律：当某个字段的值包含特殊字符的时候，校验就会失败。具体来说，是客户名称这个字段，如果包含单引号（'），校验就会失败。

但是奇怪的是，平台的校验规则里并没有限制单引号啊。为什么单引号会导致校验失败呢？

我继续深入调试，发现校验函数在处理客户名称的时候，会把客户名称拼接到一个SQL查询语句中，用来检查客户名称是否重复。如果客户名称包含单引号，就会导致SQL语句语法错误，校验函数抛出异常，但是这个异常被捕获了，没有任何提示，函数直接返回了。

原来如此！问题出在SQL注入上。无代码平台生成的校验代码，直接把用户输入拼接到SQL语句中，没有做参数化处理，导致用户输入单引号的时候，SQL语句出错，校验失败，保存操作中断。

但是等等，这不对啊。如果是SQL注入的问题，应该一直都有问题才对，为什么以前没问题，今天才出现呢？

第四步：为什么今天才出现

这个问题让我困惑了很久。如果代码一直是这样的，那以前用户输入单引号的时候也应该出问题啊。为什么以前没人反馈呢？

我问了销售部门，他们说以前客户名称里也有带单引号的，比如一些外资企业的名称，以前都能正常保存，就今天不行。

这就更奇怪了，同样的代码，同样的输入，为什么以前没问题，今天就有问题了？

我开始怀疑是不是平台今天更新了。我查了一下平台的更新记录，发现今天下午平台自动更新了一个小版本。更新说明里写的是"修复了一些已知问题，提升了系统稳定性"，没有提到具体改了什么。

会不会是这次更新导致的问题？

我联系了无代码平台的技术支持，问他们今天的更新改了什么。他们查了之后告诉我，今天的更新修改了数据校验模块的代码，优化了校验逻辑，提升了校验性能。

我让他们把修改前后的代码对比一下，看看具体改了什么。他们发来了对比，我一看就明白了。

原来，在更新之前，校验函数中检查客户名称重复的SQL查询，用的是参数化查询，所以单引号不会有问题。但是更新之后，可能是为了提升性能，他们把参数化查询改成了字符串拼接，结果就引入了SQL注入的问题。

这就是为什么以前没问题，今天更新之后才出问题。平台的一次"优化"，反而引入了一个严重的Bug。

第五步：临时解决方案

找到原因之后，已经是凌晨3点多了。我赶紧想办法解决问题。

最直接的解决方案是让平台回滚到上一个版本，但是平台技术支持说回滚需要时间，而且可能影响其他应用，不能马上回滚。

那只能先想一个临时解决方案了。我想到的办法是，在客户名称字段加一个输入校验，禁止输入单引号。这样用户就无法输入单引号，也就不会触发这个Bug了。

但是这样会影响业务，因为有些客户名称确实包含单引号。不过现在是紧急情况，先保证系统能用，后面再想更好的解决方案。

我在无代码平台上给客户名称字段加了一个正则校验，禁止输入单引号和其他特殊字符。然后通知销售部门，暂时不要在客户名称中使用单引号，如果有需要，先用其他字符代替，等问题修复之后再改回来。

做完这些，已经是凌晨5点多了。我测试了一下，保存功能恢复正常了，虽然不能输入单引号，但是至少能用了。

第六步：最终修复

第二天上午，无代码平台的技术支持修复了这个Bug，重新发布了一个版本，把SQL查询改回了参数化查询。我测试了一下，单引号的问题解决了，然后把我加的输入校验去掉了，系统恢复了正常。

这次故障从发生到完全修复，持续了将近20个小时，其中我排查了整整一夜。虽然最终解决了，但是给销售部门的工作造成了不小的影响，也让我对无代码平台的可靠性产生了一些担忧。

四、根本原因分析

故障解决之后，我们做了一次深入的根本原因分析。

直接原因：无代码平台的一次更新，把数据校验中的参数化SQL查询改成了字符串拼接，导致用户输入单引号时SQL语句出错，保存操作失败。

为什么会发生这种低级错误：平台开发团队在优化代码的时候，没有充分测试，只测试了正常的输入，没有测试特殊字符的情况。而且他们的代码审查流程可能也有问题，这么明显的SQL注入问题，应该在代码审查的时候就能发现。

为什么我们没有及时发现：因为这个问题不是必现的，只有当用户输入包含单引号的时候才会触发。而我们的测试用例中没有覆盖这种情况，所以在平台更新之后的测试中没有发现这个问题。

为什么排查了这么久：主要有几个原因。第一，问题不是必现的，复现困难。第二，无代码平台是黑盒的，我们看不到平台的内部代码，只能从外部排查。第三，平台的日志不够完善，前端的错误没有被记录下来，导致我们一开始找不到方向。第四，平台更新没有通知我们，我们不知道平台更新了，走了很多弯路。

五、我们采取的改进措施

这次故障给我们敲响了警钟。我们采取了一系列改进措施，防止类似的问题再次发生。

1. 建立平台更新通知机制

我们和无代码平台厂商约定，以后平台的任何更新，都必须提前通知我们，并且提供详细的更新说明，包括改了什么、可能影响什么、需要我们做什么测试。更新之后，我们会先在测试环境验证，确认没有问题之后再更新生产环境。

2. 加强应用测试

我们对无代码平台上的核心应用，建立了完整的测试用例，包括正常情况、边界情况、异常情况。每次平台更新之后，都会用这些测试用例做回归测试，确保应用正常运行。

测试用例中特别加入了特殊字符的测试，比如单引号、双引号、斜杠、HTML标签等，防止类似的注入问题。

3. 完善监控和告警

我们加强了对无代码平台应用的监控，包括页面可用性、接口响应时间、错误率等。发现异常及时告警，不用等用户反馈才知道出了问题。

我们还在关键应用中加入了前端错误监控，捕获JavaScript错误和AJAX请求失败，这样前端出问题的时候也能及时发现。

4. 制定应急预案

我们制定了无代码平台故障的应急预案，包括常见问题的排查步骤、临时解决方案、联系人等。出了问题之后，按照应急预案快速处理，减少故障影响时间。

5. 评估核心应用的迁移

对于特别核心的业务应用，我们开始评估是否要从无代码平台迁移到传统开发的系统上。无代码平台虽然方便，但是可控性差，出了问题排查困难，对于核心业务来说风险太大。

当然，迁移需要成本，我们会根据应用的重要性和复杂度来决定是否迁移。

六、无代码平台的坑

经过这次故障，我对无代码平台有了更深刻的认识。无代码平台确实能提高效率，但是也有很多坑。

坑1：黑盒问题

无代码平台对于使用方来说是黑盒的，你看不到平台的内部实现，出了问题很难排查。你只能从外部现象来推断问题原因，排查效率很低。

这次故障如果是我们自己开发的系统，我可能一两个小时就能定位到问题。但是因为是无代码平台，我看不到代码，只能一点点试，排查了整整一夜。

坑2：平台更新的风险

无代码平台通常是SaaS服务，平台会不定期更新。这些更新可能会引入新的Bug，影响你的应用。而且你无法控制平台的更新，只能被动接受。

虽然平台厂商会说更新是兼容的、不会影响现有应用，但是实际上每次更新都可能有意外。这次故障就是一个典型的例子。

坑3：定制能力有限

无代码平台虽然能快速搭建应用，但是定制能力有限。遇到复杂的业务逻辑，或者特殊的需求，平台可能满足不了。这时候你要么改业务流程来适应平台，要么找厂商做定制，成本很高。

坑4：数据安全和可控性

无代码平台上的数据都存在平台的服务器上，你对数据的可控性比较差。虽然平台厂商会说数据是安全的，但是你无法完全确认。对于敏感数据，使用无代码平台要谨慎。

坑5：厂商绑定

用了无代码平台之后，你的应用和数据都在平台上，想迁移到其他平台或者自己开发，成本很高。这就是厂商绑定，一旦用了，就很难离开。

七、无代码平台到底还能不能用

说了这么多坑，可能有人会问，无代码平台到底还能不能用？

我的答案是：能用，但是要选对场景，做好风险控制。

无代码平台适合的场景：

  • 简单的、非核心的管理应用
  • 快速原型验证
  • 业务部门自己使用的小工具
  • 需求变化快、生命周期短的应用

无代码平台不适合的场景：

  • 核心业务系统
  • 对稳定性要求极高的应用
  • 业务逻辑复杂的应用
  • 对数据安全要求极高的应用
  • 需要深度定制的应用

选对了场景，无代码平台确实能大大提高效率，降低开发成本。但是对于不适合的场景，不要勉强用无代码平台，否则后期会遇到很多问题。

而且，使用无代码平台的时候，一定要做好风险控制。比如选择靠谱的厂商、建立更新通知机制、加强测试、完善监控、制定应急预案等。

八、写在最后

这次无代码平台的故障，让我排查了整整一夜，至今记忆犹新。它让我对无代码平台有了更深刻的认识，也让我们团队在无代码平台的使用和管理上更加成熟。

无代码是一个好东西，它让应用开发变得更简单，让业务人员也能参与到应用开发中来。但是无代码不是银弹，它有自己的局限性和风险。我们在享受无代码带来的便利的同时，也要认识到它的不足，做好风险控制。

技术的发展总是伴随着新的问题和挑战。无代码也是如此。作为技术人员，我们的职责就是在新技术带来的便利和风险之间找到平衡，让技术更好地为业务服务。

希望我们的这次故障经历能给正在使用或者准备使用无代码平台的朋友一些参考。如果你也遇到过类似的问题，欢迎在评论区交流讨论。

最后用一句话结束本文："任何技术都有坑，关键是你有没有踩过，以及踩过之后有没有长记性。"愿每一个技术人都能在踩坑中成长，在解决问题中进步。