之所以没有引入完整版，一方面完整代码，代码量较多，放在这里会造成主题的偏移。另一方面，完整代码涉及内部的一些配置服务，不方便泄露。
五，扩展 1.核心属性解释message：异常消息。在校验失败时，返回的message。通常会将校验失败时的异常消息，甚至是异常类型等放在这里（异常堆栈，是可以通过校验失败时抛出的BindException获取）。
groups：分组信息。通过该属性，进行分组校验。详见中级应用：分组信息部分。
payload：有效负载。用于保存一些关键信息。
其实上述三个核心属性，最为神秘的，就是payload属性。一方面，这个属性用得最少，绝大部分人都不会使用。另一方面，国内的百度很难找到这方面资料。
我在百度的前两页，都看不到几个相关的解释。即使有解释，也只是一句干巴巴的有效负载（其实就是翻译过来，具体功能和这个没太大关系）。百度中只有两条博客，提到payload可以作为用户校验，以及元数据。而一些Validation框架的教学视频，也大多一笔带过。最后还是在谷歌上找到较为全面的解释。。。
2.payload的实践应用我之前使用Validation框架，也没有使用这个注解。直到在蚂蚁某项目推进数据校验规范时，才去深入了解它。还有一个比较重要的原因，当时一方面需要在message中保存自定义的异常信息，另一方面需要保存错误类型的Code（系统有一个专门的异常Enum），从而对接阿里内部的国际化文案平台-美杜莎（特意查了一些，外网是有资料的。囧）。
那么需要保存的信息就不止两处。如果通过Json配合BO的方式，就有些复杂化了，而且显得比较重（尤其是有更好的方案）。前期不了解payload的情况下，就通过BindExcpetion的解析，获取所需的核心信息，放弃非核心的信息。那么在了解payload后，问题就简单了。直接通过payload配合对应Payload接口的子接口，可以保存所需的信息。
之后有机会，可以考虑写一篇博客，来谈谈有关payload的实践应用。
3.BindException的解析先上图，可以看到BindException继承Exception，实现了BindingResult接口。
Exception，相信大家都熟悉，那么就直接上BindingResult接口吧。
至于最终效果如何，可以看下图。