在学生管理系统里，其中会有学生信息采集的功能。程序结构不外乎下面的分层实现方式。

开发出来这个功能，我觉得大家都易如反掌了。

当然易如反掌。

OK，我要说的是数据校验，以最简单的非空校验（例如：学生姓名不可为空）来说：

首先，前端页面的表单要校验，为空则不允许提交，非空则调用后端api接口来post数据。

其次，后端程序的controller里要校验，为空则直接返回错误提示，非空则调用StudentService类。

再次，StudentService类要校验，为空则直接返回错误提示，非空则在其他校验通过后，进行数据的持久化。

上面的“再次”，在单体应用内不做校验也可————而一旦是在RPC调用的情况下，是必须要做的。

那么，聪明的你，有没有，或者曾经有没有，忽视上面的几处校验呢？

你也许会说No. ————肯定会做校验呀。

你也许还会说but why？————为什么要这么多处校验呢？一个地儿校验住不就完了吗？

First，为什么前端要校验？

--> 前端页面校验不通过时，则直接在页面提示给用户了，好处：①响应快，因为无须调用后端api，也减少了网络通信；②用户体验会好一些。

Second，前端已经校验了，为什么后端还要校验？

--> 正常情况下是不需要后端再校验了。非正常情况下呢？例如，前端没拦住，再例如，请求不是前端发过来的...

Third，为什么service类还要校验？

--> 上面说了，如果是单体应用，你不校验也行。而如果是局域网RPC服务之间调用的话，你还真要加上这个校验。也是为了防止非正常情况的。

多次一举？

实际企业应用开发中，类似的需要多处“重复”做的校验包括：数据合法性校验、数据重复校验、幂等校验（幂等控制）、数据唯一性校验（数据防重控制）。

你可以不“重复”做这些校验，而simply依靠请求链路里的only一个节点的校验来cover。在这种情况下，你的系统没出现问题，只能说明你比较幸运。一直没出现问题，说明你一直比较幸运。

最近我们系统是出现了这样的事故。一个中台dubbo服务提供了数据的新增接口，供下游业务线调用。系统运行了大半年也没出现问题，而最近却翻车了。一个业务线在特定的分支逻辑里缺乏有效的防重控制，致使在业务高峰期不停地重复刷这个接口（传递同样的数据），而这个dubbo接口里没有做业务防重。瞬时的高频调用，不仅让dubbo服务出现故障，还造成了大量的重复数据。随之而来的是运营的催促，客户的投诉，我们在处理重复数据时，耗费了大量的人力和时间成本。这一张多米诺骨牌，让我们付出了惨痛的代价。

我是因为遇到了这么一个事故才写这个blog吗？

不是！许多大的事故往往就是类似小疏忽导致的。我遇到的这样的事故简直太多了。

你没有遇到这样的事故吗？

我不信！

So，苦口婆心一番，愿小伙伴们别再为这样的疏忽而翻车。