在传统的web项目中，防止重复提交，通常做法是：后端生成一个唯一的提交令牌（uuid），并存储在服务端。页面提交请求携带这个提交令牌，后端验证并在第一次验证后删除该令牌，保证提交请求的唯一性。

多环境是最常见的配置隔离方式之一，可以根据不同的运行环境提供不同的配置信息来应对不同的业务场景，在SpringBoot内支持了多种配置隔离的方式，可以激活单个或者多个配置文件。

SpringBoot在项目启动时如果遇到异常并不能友好的打印出具体的堆栈错误信息，我们只能查看到简单的错误消息，以致于并不能及时解决发生的问题，针对这个问题SpringBoot提供了故障分析仪的概念（failure-analyzer），内部根据不同类型的异常提供了一些实现，我们如果想自定义该怎么去做？

在之前项目中我们想要读取MongoDB内的内容需要使用MongoDBTemplate来完成数据的CRUD，那如果我们想要通过RestController的形式获取MongoDB内的数据就更麻烦了，还需要自行去创建对应的控制器，然后使用MongoDBTemplate从MongoDB内读取出数据后返回给前端。

MongoDB在企业级项目中一般用于存储文档信息、图片资源等，MongoDB的内容完全是以 JSON字符串的形式进行存储的，所以我们在获取数据时通过简单的 反序列化就可以完成与项目内的实体类转换，不过这个过程是自动的，不需要我们手动进行反序列化处理。

初升级SpringBoot2.0版本，在已经使用SpringBoot1.x的系统内还是存在一些兼容性的问题，有很多变化！！！也存在一些过时的方法、配置文件信息以及类，我们在之前版本的SpringBoot1.x中可以使用WebMvcConfigurerAdapter抽象类来处理SpringMVC相关的配置，由于SpringBoot2.0版本最低支持 JDK1.8环境，在JDK1.8引入了特殊的关键字default，该关键字配置在interface接口的方法时子类可以不去实现该方法，相当于抽象类内已经实现的接口方法。

在我们平时的项目研发过程中，异常一般都是程序员最为头疼的问题，异常的抛出、捕获、处理等既涉及事务回滚，还会涉及返回前端消息提醒信息。那么我们怎么设计可以解决上面的两个的痛点呢？我们可不可以统一处理业务逻辑然后给出前端对应的异常提醒内容呢？

本章内容比较偏向系统设计方面，简单的封装就可以应用到系统中使用，从而提高我们的编码效率以及代码的可读性。统一资源在系统内是不可避免的模块，资源分类也有很多种，比较常见如：图片资源、文本资源、视频资源等，那么资源统一处理的好处是什么呢？大家有可能会有疑问，我把资源存放到业务表内岂不更好吗？这样查询起来也方便，并不需要关联资源信息表！当然设计不分好坏，只有更适合、更简单！接下来带着疑问进入本章的内容。