在学生管理系统里，其中会有学生信息采集的功能。程序结构不外乎下面的分层实现方式。
开发出来这个功能，我觉得大家都易如反掌了。
当然易如反掌。
OK，我要说的是数据校验，以最简单的非空校验（例如：学生姓名不可为空）来说：
首先，前端页面的表单要校验，为空则不允许提交，非空则调用后端api接口来post数据。
其次，后端程序的controller里要校验，为空则直接返回错误提示，非空则调用StudentService类。
再次，StudentService类要校验，为空则直接返回错误提示，非空则在其他校验通过后，进行数据的持久化。
上面的“再次”，在单体应用内不做校验也可————而一旦是在RPC调用的情况下，是必须要做的。
那么，聪明的你，有没有，或者曾经有没有，忽视上面的几处校验呢？
你也许会说 No, of course not. ————肯定会做校验呀。
你也许还会说 But why？————为什么要这么多处校验呢？一个地儿校验住不就完了吗？
First，为什么前端要校验？
–> 前端页面校验不通过时，则直接在页面提示给用户了，好处：①响应快，因为无须调用后端api，也减少了网络通信；②用户体验会好一些。
Second，前端已经校验了，为什么后端还要校验？
–> 正常情况下是不需要后端再校验了。非正常情况下呢？例如，前端没拦住，再例如，请求不是前端发过来的…
Third，为什么service类还要校验？
–> 上面说了，如果是单体应用，你不校验也行。而如果是局域网RPC服务之间调用的话，你还真要加上这个校验。也是为了防止非正常情况的。
在实际企业应用开发中，因为非正常情况的概率性事件存在，所以，我们需要“重复地”来做这些校验。类似的需要多处“重复”做的校验包括：数据合法性校验、数据重复校验、幂等校验（幂等控制）、数据唯一性校验（数据防重控制）。
你也许会继续追问：哪有那么多非正常情况呀？？？？
你可以不“重复”做这些校验，而simply依靠请求链路里的only一个节点的校验来cover。那么，你这种“半裸奔”的系统没出现问题，只能说明你比较幸运。一直没出现问题，说明你一直比较幸运。
最近我们系统碰巧又出现了这样的事故。一个中台dubbo服务提供了数据的新增接口，供下游业务线调用。系统运行了大半年也没出现问题，而最近却翻车了。一个业务线在特定的分支逻辑里缺乏有效的防重控制，致使在业务高峰期不停地重复刷这个接口（传递同样的数据），而这个dubbo接口里没有做业务防重。瞬时的高频调用，不仅让dubbo服务出现故障，还造成了大量的重复数据。随之而来的是运营的催促，客户的投诉，我们在处理重复数据时，耗费了大量的人力和时间成本。这一张多米诺骨牌，让我们付出了惨痛的代价。
我是因为遇到了这么一个事故才写这个blog吗？
不是！许多大的事故往往就是类似小疏忽导致的。我遇到的这样的事故简直太多了。
你没有遇到这样的事故吗？
我不信！So，一番碎碎念，愿小伙伴们别再为这样的疏忽而翻车。
