一个请求入参 req 引发的魔法攻击

项目场景

月初检修上线后没几天，隔壁项目组的同事，反馈说出现了生产问题，调用我们这边的接口报错。

问题描述

看到这个问题的第一眼，什么鬼，请求参数错误？

但是看到 “操作用户信息为空” 这个提示的时候，心里咯噔一下。
这个是我们这边封装的的一个基类，用户从前台请求的时候都会自动带上。
基类里面的用户信息字段，是加了 @NotNull 注解的。
只要外层加了 @Valid 注解就会进行必填的校验。

---

原因分析

罪魁祸首竟然是这个？！一个同事加了一个基类的继承。然后没有考虑到有其他项目 or 第三方的调用，而且还有必填校验。

据我了解，隔壁组的请求是没有封装这几基类的。
所以，引用到这个 req 的好几个接口都中枪了。

---

解决方案

1. 评估影响范围，在其他项目组进行修改，或者我们项目组进行代码回滚和对应的修改。
2. 新建一个 req，不要动原来的 req 了。

经验教训

1. 评估改动的影响范围，有多少地方引用了这个 req。特别注意，继承的基类里面有 @NotNull 类似的校验注解。
2. 有人说，不知道其他项目引用了。这种情况也挺常见，一开始接口我自己用，后面其他项目组也用到了。这个时候，规范的命名（external 加类似这种前后缀进行标识），或者必要的注释就很重要了，让其他修改这块代码的人，一眼就知道它的影响范围。
3. 开闭原则：对拓展开放，对修改关闭。