最近在撸代码时，发现了调用批量处理接口很容易超时。原因很简单：接口参数没有限制，数量一旦多了，接口处理事务时间就增长，导致调用方超时。
又回去翻了一下《阿里巴巴java开发手册》，里面刚好有对接口入参保护，原文如下：
【推荐】接口入参保护，这种场景最常见的是用于做批量操作的接口。
【参考】下列情形，需要进行参数校验： 1） 调用频次低的方法。 2） 执行时间开销很大的方法。此情形中，参数校验时间几乎可以忽略不计，但如果因为参 数错误导致中间执行回退，或者错误，那得不偿失。 3） 需要极高稳定性和可用性的方法。 4） 对外提供的开放接口，不管是 RPC/API/HTTP 接口。 5） 敏感权限入口。
【参考】下列情形，不需要进行参数校验： 1） 极有可能被循环调用的方法。但在方法说明里必须注明外部参数检查要求。 2） 底层调用频度比较高的方法。毕竟是像纯净水过滤的最后一道，参数错误不太可能到底 层才会暴露问题。一般 DAO 层与 Service 层都在同一个应用中，部署在同一台服务器中，所 以 DAO 的参数校验，可以省略。 3） 被声明成 private 只会被自己代码所调用的方法，如果能够确定调用方法的代码传入参 数已经做过检查或者肯定不会有问题，此时可以不校验参数。
工作中很少提到“入参保护”这个词，更多的是“参数校验”的说法；谈下个人对接口入参保护的理解：
1、接口入参保护，“保护”的是服务端应用，即接口提供方，最常见的做法就是校验入参的有效值范围和设置批量操作白名单；
比如，接口入参中包含日期时，校验日期必须在N天范围内，或者请求返回的记录总数必须在X条以内（比如10W条，否则缩小请求查询的记录范围），或者请求返回的记录必须分页查询返回；
开发手册中，尤其提到的场景就是批量操作，因为批量操作非常耗时耗资源（服务端），批量操作的批量数应该有上限，而不是无限的。假如客户端请求一次批量操作10W笔转账订单，服务器应该果断拒绝，很不是的忠实执行，会对服务端造成严重影响的批量请求，服务器端应做好保护性编程，必要时应直接失败，并在Result中返回明确的errorCode和errorMsg;
而且，对应批量操作，实际应用中还会配置批量操作白名单！
2、入参保护，一般都是通过卫语句实现：if（请求记录>10000条） return；直接返回。
