controlleradvice注解作用,对处理请求过程中产生的异常处理

controlleradvice注解作用,对处理请求过程中产生的异常处理详细介绍

本文目录一览： 取代码表异常怎么解决

上面的示例，还只是比较简单的方法，复杂一些的可能会有更多的try catch代码块。这将会严重影响代码的可读性、“美观性”。 所以如果是我的话，我肯定偏向于第二种，我可以把更多的精力放在业务代码的开发，同时代码也会变得更加简洁。 既然业务代码不显式地对异常进行捕获、处理，而异常肯定还是处理的，不然系统岂不是动不动就崩溃了，所以必须得有其他地方捕获并处理这些异常。那么问题来了，如何优雅的处理各种异常？?
基础知识点认识：
下面我们先认识两个注解@RestControllerAdvice和@ExceptionHandler
@RestControllerAdvice注解定义全局异常处理类，此注解通过对异常的拦截实现的统一异常返回处理。
@ExceptionHandler 一个异常拦截器（处理器），指定某个或某些异常后，会捕获到相应的异常。
使用 @ControllerAdvice + @ExceptionHandler 进行全局的 Controller 层异常处理，只要设计得当，就再也不用在 Controller 层进行 try-catch 了！而且@Validated 校验器注解的异常，也可以一起处理，减少模板代码，减少编码量，提升扩展性和可维护性。
异常按阶段分类
异常按阶段分可分为Controller前的异常和service层异

注解记录-)@ControllerAdvice下的@ExceptionHandler和@Aspect下的@AfterThrowing

之前记录了@AfterThrowing，当切面的类或者方法有异常时，今天看到@ExceptionHandler，对于 两者的优先级存在疑问 ，遂记录。
先记录@ExceptionHandler的作用以及使用场景。 1、如果单使用@ExceptionHandler，只能在当前Controller中处理异常。但当配合@ControllerAdvice一起使用的时候，就可以在任意地方使用。 2、@ExceptionHandler和@ControllerAdvice能够集中异常，使异常处理与业务逻辑分离。
大概就像下面这样的例子吧
优先级的话，运行程序截图就能说明问题。

结论：AfterThrowing 优先于 ExceptionHandler。
web中常见的通过回调的方式实现的aop有Filter（过滤器）和Interceptor（拦截器）。详情看这位大佬链接即可，每个步骤非常详细。 https://www.cnblogs.com/dugqing/p/8906013.html

如果不用异常处理机制,还有什么办法

加注解。在JAVA中没有完善的异常处理机制后果就是程序崩盘，如果有些时候不能用异常处理机制，还有一种办法就是加注解，在类的签名加上注解@ControllerAdvice，就可以统一对不同阶段的、不同异常进行处理了。

对处理请求过程中产生的异常处理

????????在处理请求的过程中可能产生异常，如果这个异常表明这次请求不会得到正常的处理，那么应当向用户告知。Spring已经内置了一些规则，当在处理请求的过程抛出如下异常，那么就会自动的设置响应状态码。可以通过在Mapping Request的方法中直接抛出这些异常来测试是否会自动设置响应状态码，返回响应。

这些内置的映射非常有用，但是对于其他异常就无能为力了。如果要把自定义的异常也映射到响应状态码，这个非常简单只需要在自定义的异常类上添加注解：@ResponseStatus，设置这个注解的value属性。值域是枚举类HttpStatus中包含的值。

? ? ? ? 如果并不想简单的只是简单的给出一个表示请求处理失败（状态码揭示了这一点）的响应，那么可以通过在一个Controller类中定义被@ExceptionHandler注解的方法。

? ? ? ? 在一个Controller类中添加ExceptionHandler方法，ExceptionHandler方法只会在该Controller类中有效，对于其他的Controller类无效，如果要定义一个ExceptionHandler方法使得能够“应付”任何一个Controller的任何一个处理器方法抛出的对应的异常，这需要定义了一个ControllerAdvice类。ControllerAdvice类是一个被@ControllerAdvice注解的类，@ControllerAdvice已经包含@Component注解。之后在ControllerAdvice类中定义ExceptionHandler方法就可以了。

如何重构出这么优雅后台 API 接口

Hello，早上好，我是阿粉~
最近偶然间在看到 Spring 官方文档的时候，新学到一个注解 @ControllerAdvice ，并且成功使用这个注解重构我们项目的对外 API 接口，去除繁琐的重复代码，使其开发更加优雅。
展示具体重构代码之前，我们先来看下原先对外 API 接口是如何开发的。
这个 API 接口主要是用来与我们 APP 交互，这个过程我们统一定义一个交互协议，APP 端与后台 API 接口统一都使用 JSON 格式。
另外后台 API 接口对 APP 返回时，统一一些错误码，APP 端需要根据相应错误码，在页面弹出一些提示。
下面展示一个查询用户信息返回的接口数据：
code 代表对外的错误码， msg 代表错误信息， result 代表具体返回信息。
前端 APP 获取这个返回信息，首先判断接口返回 code 是否为 「000000」 ，如果是代表查询成功，然后获取 result 信息作出相应的展示。否则，直接弹出相应的错误信息。
下面我们来看下，重构之前的，后台 API 层的如何编码。
上面的代码其实很简单，内部统一封装了一个工具类 APIResult ，然后用其包装具体的结果。
除了这个以外，还定义一个异常对象 APPException ，用来统一包装内部的各种异常。
上面的代码很简单，但是呢可以说比较繁琐，重复代码也比较多，每个接口都需要使用 try...catch 包装，然后使用 APIResult 包括正常的返回信息与错误信息。
第二呢，接口对象只能返回 APIResult ，真实业务对象只能隐藏在 APIResult 中。这样不太优雅，另外不能很直观知道真实业务对象。
下面我们开始重构上面的代码，主要目的是去除重复的那一坨 try...catch 代码。
这次重构我们需要使用Spring 注解 @ControllerAdvice 以及 ResponseBodyAdvice ，我们先来看下重构的代码。
首先我们需要实现 ResponseBodyAdvice ，实现我们自己的处理类。
实现上面的接口，我们就可以在 beforeBodyWrite 方法里，修改返回结果了。
上面代码中，只是简单使用 APIResult 包装了返回结果，然后返回。其实我们还可以在此增加一些额外逻辑，比如说如接口返回信息由加密的需求，我们可以在这一层统一加密。
另外，这里判断一下 body 是否 APIResult 类，如果是就直接返回，不做修改。
这么做一来兼容之前的老接口，这是因为默认情况下，我们自己实现的 CustomResponseAdvice 类，将会对所有的 Controller 生效。
如果不做判断，以前的老接返回就会被包装了两层 APIResul ,影响 APP 解析。
除此之外，如果大家担心这个修改对以前的老接口有影响的话，可以使用下面的方式，只对指定的方法生效。
首先自定义一个注解，比如说：
然后将其标注在需要改动的方法中，然后我们在 ResponseBodyAdvice#supports 中判断具体方法上有没有自定义注解 CustomResponse ，如果存在，返回 true ，这就代表最后将会修改返回类。如果不存在，则返回 false ，那么就会跟以前流程一样。
上面的代码重构之后，将重复代码抽取了出来，整体的代码就剩下我们的业务逻辑，这样就变得非常简洁优雅。
不过，上面的重构的代码，还是存在问题，主要是异常的处理。
如果上面的业务代码抛出了异常，那么接口将会返回堆栈错误信息，而不是我们定义的错误信息。所以下面我们这个，再次优化一下。
这次我们主要需要使用 @ExceptionHandler 注解，这个注解需要与 @ControllerAdvice 一起使用。
使用这个 @ExceptionHandler ，将会拦截相应的异常，然后将会调用的相应方法处理异常。这里我们就使用 APIResult 包装一些错误信息返回。
我们可以使用 @ControllerAdvice 加 ResponseBodyAdvice 拦截返回结果，统一做出一些修改。这样就可以使用的业务代码非常简洁，优雅。
另外，针对业务代码的中，我们可以使用 @ExceptionHandler 注解，统一做一个全局异常处理，这样就可以无缝的跟 ResponseBodyAdvice 结合。
不过这里需要一点，我们实现的 ResponseBodyAdvice 类，一定需要跟 @ControllerAdvice 配合一起使用哦，至于具体原因，下篇文章阿粉分析原来的时候，再具体解释哦。敬请期待哦~

瞧瞧人家用SpringBoot写的后端API接口，那叫一个优雅

假设实现一个注册用户的功能，在controller 层，他会先进行校验参数，如下：
以上代码有什么问题嘛？ 其实没什么问题，就是校验有点辣眼睛 。正常的添加用户业务还没写，参数校验就一大堆啦。假设后来，又接了一个需求：编辑用户信息。实现编辑用户信息前，也是先校验信息，如下：
我们可以使用注解的方式，来进行参数校验，这样代码更加简洁，也方便统一管理。实际上， spring boot 有个 validation 的组件，我们可以拿来即用。引入这个包即可：
引入包后，参数校验就非常简洁啦，如下：
然后在 UserParam 参数对象中，加入 @Validated 注解哈，把错误信息接收到 BindingResult 对象，代码如下：
如果你在你们项目代码中，看到controller 层报文返回结果，有这样的：
也有这样的：
显然，如果接口返回结果不统一，前端处理就不方便，我们代码也不好维护。再比如有的人喜欢用 Result 处理结果， 有点人 喜欢用 Response 处理结果，可以想象一下，这些代码有多乱。
所以作为后端开发，我们项目的响应结果，需要 统一标准的返回格式 。一般一个标准的响应报文对象，都有哪些属性呢？
响应状态码一般用枚举表示哈：
因为返回的数据类型不是确定的，我们可以使用泛型，如下：
有了统一的响应体，我们就可以优化一下controller 层的代码啦：
日常开发中，我们一般都是自定义统一的异常类，如下：
在controller 层，很可能会有类似代码：
这块代码，没什么问题哈，但是如果 try...catch 太多，不是很优雅。
可以借助注解 @RestControllerAdvice ，让代码更优雅。 @RestControllerAdvice 是一个应用于 Controller 层的切面注解，它一般配合 @ExceptionHandler 注解一起使用，作为项目的全局异常处理。我们来看下demo代码哈。
还是原来的 UserController ，和一个会抛出异常的userService的方法，如下：
我们再定义一个全局异常处理器，用 @RestControllerAdvice 注解，如下：
我们有想要拦截的异常类型，比如想拦截 BizException 类型，就新增一个方法，使用 @ExceptionHandler 注解修饰，如下：

Spring Boot中Controller的统一异常处理

我们在做Web应用的时候，请求处理过程中发生错误是非常常见的情况。Spring Boot提供了一个默认的映射： /error ，当处理中抛出异常之后，会转到该请求中处理，并且该请求有一个全局的错误页面用来展示异常内容。
虽然，Spring Boot中实现了默认的 error 映射，但是在实际应用中，上面你的错误页面对用户来说 并不够友好 ，我们通常需要去实现我们自己的异常提示。
下面我们以之前的Web应用例子为基础，进行统一异常处理的改造。
通过使用 @ControllerAdvice 定义统一的异常处理类，而不是在每个Controller中逐个定义。 @ExceptionHandler 用来定义函数针对的异常类型，最后将Exception对象和请求URL映射到error.html中。
在templates目录下创建error.html，将请求的URL和Exception对象的message输出。
启动该应用，访问： http://localhost:8080/exception ，可以看到如下错误提示页面。
通过实现上述内容之后，我们只需要在Controller中抛出Exception，当然我们可能会有多种不同的Exception。然后在 @ControllerAdvice 类中，根据抛出的具体Exception类型匹配 @ExceptionHandler 中配置的异常类型来匹配错误映射和处理。
在上述例子中，通过 @ControllerAdvice 统一定义不同Exception映射到不同错误处理页面。而当我们要实现RESTful API时，返回的错误是JSON格式的数据，而不是HTML页面，这时候我们也能轻松支持。
本质上，只需在 @ExceptionHandler 之后加入 @ResponseBody ，就能让处理函数return的内容转换为JSON格式。
下面以一个具体示例来实现返回JSON格式的异常处理。
code：消息类型，message：消息内容，url：请求的url，data：请求返回的数据
至此，已完成在Spring Boot中创建统一的异常处理，实际实现还是依靠Spring MVC的注解，更多更深入的使用可参考Spring MVC的文档。

spring常用注解

一、组件注解
1、 @Component(“xxx”)
指定某个类是容器的bean， @Component(value="xx") 相当于 ，其中 value 可以不写。
用于标注类为spring容器bean的注解有四个， 主要用于区别不同的组件类，提高代码的可读性：
a、 @Component, 用于标注一个普通的bean
b、 @Controller 用于标注一个控制器类（控制层 controller）
c、 @Service 用于标注业务逻辑类（业务逻辑层 service）
d、 @Repository 用于标注DAO数据访问类 （数据访问层 dao）
对于上面四种注解的解析可能是相同的，尽量使用不同的注解提高代码可读性。
注解用于修饰类，当不写value属性值时，默认值为类名首字母小写。
2、 @Scope(“prototype”)
该注解和 @Component 这一类注解联合使用，用于标记该类的作用域，默认 singleton 。 也可以和 @Bean 一起使用，此时 @Scope 修饰一个方法。关于@Bean稍后有说明
3、 @Lazy（true）
指定bean是否延时初始化，相当于 ，默认false。@Lazy可以和@Component这一类注解联合使用修饰类，也可以和@Bean一起使用修饰方法
注 ：此处初始化不是指不执行 init-method ，而是不创建bean实例和依赖注入。只有当该bean（被@Lazy修饰的类或方法）被其他bean引用（可以是自动注入的方式）或者执行getBean方法获取，才会真正的创建该bean实例，其实这也是BeanFactory的执行方式。
4、 @DepondsOn({“aa”，“bb”})
该注解也是配合 @Component 这类注解使用，用于强制初始化其他bean
上面的代码指定，初始化bean “userAction"之前需要先初始化“aa”和“bb”两个bean,但是使用了@Lazy(true)所以spring容器初始化时不会初始化"userAction” bean。
5、 @PostConstructor和@PreDestroy
@PostConstructor 和 @PreDestroy 这两个注解是j2ee规范下的注解。这两个注解用于修饰方法，spring用这两个注解管理容器中spring生命周期行为。
a、 @PostConstructor 从名字可以看出构造器之后调用,相当于 。就是在依赖注入之后执行
b、 @PreDestroy 容器销毁之前bean调用的方法，相当于
6、 @Resource（name=“xx”）
@Resource 可以修饰成员变量也可以修饰set方法。当修饰成员变量时可以不写set方法，此时spring会直接使用j2ee规范的Field注入。
@Resource有两个比较重要的属性，name和type
a、 如果指定了name和type，则从Spring容器中找到唯一匹配的bean进行装配，找不到则抛出异常;
b、 如果指定了name，则从spring容器查找名称（id）匹配的bean进行装配，找不到则抛出异常;
c、 如果指定了type，则从spring容器中找到类型匹配的唯一bean进行装配，找不到或者找到多个，都会抛出异常;
d、 如果既没有指定name，又没有指定type，则自动按照byName方式进行装配
如果没有写name属性值时
a、 修饰成员变量，此时name为成员变量名称
b、 修饰set方法，此时name 为set方法的去掉set后首字母小写得到的字符串
7、 @Autowired（required=false）
@Autowired可以修饰构造器，成员变量，set方法，普通方法。@Autowired默认使用byType方式自动装配。required标记该类型的bean是否是必须的，默认为必须存在（true）。
可以配合 @Qualifier(value="xx") ,实现按beanName注入：
a、 required=true(默认），为true时，从spring容器查找和指定类型匹配的bean，匹配不到或匹配多个则抛出异常
b、 使用 @Qualifier（"xx"） ,则会从spring容器匹配类型和 id 一致的bean，匹配不到则抛出异常
@Autowired会根据修饰的成员选取不同的类型：
a、 修饰成员变量。该类型为成员变量类型
b、 修饰方法，构造器。注入类型为参数的数据类型，当然可以有多个参数
8、demo
业务逻辑层：
数据访问层：
测试类：
输出结果：
可以看到虽然UserDao 使用@Lazy，但是还是在spring容器初始化的时候还是创建了UserDao实例。原因很简单，因为在UserService中需要注入UserDao，所以在此时创建的UserDao实例也属于延时初始化。
在上面我们还使用了两个接口InitializingBean 和DisposableBean，这两个接口用于管理 singleton 作用域的bean的生命周期，类似init-method和destroy-method。不同之处就是调用的循序不一致：
a、 初始化调用顺序 ：@PostConstructor > InitializingBean > init-method 用于指定bean依赖注入后的行为
b、 销毁调用顺序 @PreDestroy > DisposableBean > destroy-method 用于定制bean销毁之前的行为
该注解是AspectJ中的注解，并不是spring提供的，所以还需要导入aspectjweaver.jar，aspectjrt.jar，除此之外还需要依赖aopalliance.jar
依赖包：
UserDao.java
配置文件 applicationContext.xml：
测试类：
1、 @Aspect
修饰Java类，指定该类为切面类。当spring容器检测到某个bean被@Aspect修饰时，spring容器不会对该bean做增强处理（bean后处理器增强，代理增强）
2、 @Before
修饰方法，before增强处理。用于对目标方法（切入点表达式表示方法）执行前做增强处理。可以用于权限检查，登陆检查。
常用属性：
value： 指定切入点表达式 或者引用一个切入点
对com.example.aop 包下所有的类的所有方法做 before增强处理：
结果：
如果同一条切入点表达式被使用多次，可以使用更友好的方式。定义一个切入点：
增强方法可以接受一个JoinPoint 类型的参数，用于获取被执行目标方法的一下属性。
结果：
3、 @AfterReturning
修饰方法，afterreturning增强处理。目标方法正常结束后做增强处理。
常用属性：
a、 pointcut/value：指定切入点表达式
b、 returning：指定一个参数名，用于接受目标方法正常结束时返回的值。参数名称需要在增强方法中定义同名的参数。
注意：
a、 如果使用了returning 。那么增强方法中的数据类型必须是返回结果的类型或者父类型，否则不会调用该增强处理。
b、 使用了returning 还可以用来 修改返回结果 。
以上面的例子来说，目标方法返回结果类型应该满足下面的条件
修改返回值：
结果：
可以看到 AfterReturning 修改了返回结果。
4、 @AfterThrowing
修饰方法，afterthrowing增强处理。当目标程序方法抛出 异常或者异常无法捕获时，做增强处理。
常用属性：
a、 pointcut/value ：指定切入点表达式
b、 throwing：指定一个形参，在增强方法中定义同名形参，用于访问目标方法抛出的异常
参数类型必须是 Throwable 的子类，同样也会有上面@AfterReturning 参数类型匹配的问题。
5、 @After
修饰方法 ，after增强处理。无论方法是否正常结束，都会调用该增强处理（@After= @AfterReturning+@AfterThrowing）。但是该增强方式无法获取目标方法的返回结果，也获取目标方法抛出的异常。所以一般用于进行释放资源，功能类似于 finally。
常用属性：
a、 value ：指定切入点表达式
结果：
从上面的结果来看 After 增加处理 ，因为不能接受返回结果作为参数，所以不能修改返回结果。
6、 @Around
修饰方法， around增强处理。该处理可以目标方法执行之前和执行之后织入增强处理（@Before+@AfterReturning）。
Around增强处理通常需要在线程安全的环境下使用，如果@Before和@AfterReturning可以处理就没必要使用@Around。
常用属性：
a、 value ：指定切入点表达式
当定义一个Aound增前处理时，增强方法第一形参需要时ProceedingJoinPoint类型。ProceedingJoinPoint有一个Object proceed()方法，用于执行目标方法。当然也可以为目标方法传递数组参数，来修改目前方法的传入参数。
around小结：
a、 Around增强处理通常需要 在线程安全 的环境下使用
b、 调用 proceed()可以获取返回结果，所以可以修改目标方法的返回值
c、 proceed(Object[] var1) 可以修改入参，修改目标方法的入参
d、 可以进行目标方法执行之前和执行之后织入增强处理
around 和 afterReturning 都可以修改返回结果。不过两者的原理不同：
a、 around：可以任意修改，或者返回不相关的值。这个返回值完全可以自主控制
b、 afterReturning，通过方法参数 ，使用对象引用的方式来修改对象。修改对象引用地址那么修改时无效的
除此之外从输出结果来看，增强处理是有序的：
around 和 afterReturning小结：
a、 只有 around 和 afterReturning 可以获取并修改返回结果。需要注意两种方式修改的区别。
b、 around 需要线程安全
c、 虽然增强处理都需要 切入点表达式，并不是都支持 pointcut 属性，所以最好都是用value 属性指定。当注解只需要value属性时，value可以省略
7、 @Pointcut
修饰方法，定义一个切入点表达式用于被其他增强调用。使用该方式定义切入点方便管理，易复用。
切入点方法定义和测试方法定义类似，具有以下特点：
a、 无返回值 （void）
b、 无参数
c、 方法体为空
d、 方法名就是切入点名称
e、 方法名不能为 execution
切入点表达式
切入点表达式可以通过 && 、 || 、 ! 连接
1）、execution 表达式：
2）、within 表达式：
a、匹配指定类下的所有方法。
b、匹配执行包及其子包下所有类的所有方法。
所以within可以看做execution的简写，不需要指定返回类型、方法名、参数（ 最小作用单位是类 ）
3）、 @annotation：匹配使用指定注解修饰的目标方法；
匹配使用@CustomMethodAnnotation注解的目标方法。
4）、 @within: 用于匹配使用指定注解修饰的类下的所有方法
within 作用范围是类，@within的作用范围与其一致。不同的是@within 指定的不是类而是注解
匹配使用@ResponseBody 注解的类 下的所有方法。
AOP小结：
1）、 Around增强处理通常需要 在线程安全 的环境下使用
2）、 使用 around 和 afterReturning 可以获取并修改返回结果
3）、 增强处理指定 切入点表达式时，最好使用value 属性
4）、 切入点 名称（方法名）不能为 execution
5）、 AfterReturning 指定了 returning 属性接受目标方法返回结果，注意 参数类型需要和返回结果类型一致（满足 resutType instanceof argsType ）
增强方式的顺序：
1、 @Bean(name=“xxx”)
修饰方法，该方法的返回值为spring容器中管理的bean。当然该注解和上面的@Component效果一样，主要用于做区分。
@Bean 通常使用在 @Configuration 修饰的配置类中，该注解功能相当于 元素
常用的属性：
a、 name：bean id 。name可以省略，省略时bean名称为方法名。也可以指定多个名称（逗号隔开）。
b、 autowire： 是否自动注入，默认Autowire.NO
c、 initMethod：bean的初始化方法。在依赖注入之后执行
d、 destroyMethod: spring容器关闭时bean调用的方法 当然 @Bean 还可以配合 @Scope 指定bean的作用域
2、 @ConfigurationProperties
用于从属性文件中获取值 application.properties 或者 application.yml 。当然了 如果在配置文件中引入其他配置文件，也可以获取到属性值。
包含的属性：
a、 value | prefix 两者互为别名。指定前缀，默认为""
b、 ignoreUnknownFields：默认为true。是否忽略未知字段，当实体中的字段在配置文件中不存在时，是忽略还是抛出异常
c、 ignoreInvalidFields： 默认false。 是否忽略不合法的字段，此处的不合法是指类型不合适，配置文件中存在改配置但是无法转化为指定的字段类型。
Mybatis属性配置
application.properties：
ConfigurationProperties 可以配置前缀，然后会根据实体的变量名拼接前缀，去配置文件中查询配置。
3、 @Configuration
修饰一个Java类，被修饰的类相当于一个xml配置文件。功能类似于 。在springboot中大量使用了该注解，该注解提供了一种使用Java类方式配置bean。
可以发现 @Configuration使用了@Component 注解修饰。
实例 ：
配置Mybatis会话工厂
4、 @Import
功能和 类似，修饰Java类，用于向当前类导入其他配置类。 可以导入多个配置文件，通常用于导入不在包扫描范围内的配置文件。可以被扫描的配置类可以直接访问，没有必要使用@Import 导入。
比如 SpringBoot的启动类指定的包扫描路径为 com.example
数据库的配置文件在 com包下。
在MyBatisConfig 中引入 DataSourceConfig， 就会解析DataSourceConfig。将解析出的Bean交给容器管理
5、 @ImportResource
修饰Java类，用于向类引入xml配置文件。
用于导入包含bean定义的配置文件，功能和 类似。默认情况下可以处理后缀为 .groovy 和.xml 的配置文件
6、 @Value("${expression}")
修饰成员变量或者 方法、构造器的参数，用于属性值注入（在配置文件中配置的值）。
注意: @Value不能对 static 属性注入。
如果的确需要注入到静态变量，可以通过以下方式间接进行注入：
1）、设置一个私有静态 实例
2）、通过构造函数或者 @PostConstruct 注解为 静态实例 赋值，指向本身（this）
3）、对成员属性注入内容
4）、提供静态方法，使用静态实例获取成员属性
7、@PropertySource(value=“classpath:jdbc.properties”)
该注解用来加载属性文件。
常用属性：
a、 ignoreResourceNotFound： 当资源文件找不到的时候是否会忽略该配置，而不是抛出错误。一般用于可选项
b、 encoding ： 资源文件使用什么编码方式
c、 value ： 指定属性文件位置。可以配置多个属性文件，不可以使用通配符。
在 PropertySource 中可以指定多个路径，并且会将属性文件中的值加载到 Environment 中。
@ConfigurationProperties 和 @PropertySource
它们的使用有一些差异：
1）、 @PropertySource 使用该注解加载的是 相对独立的属性文件，可以同时加载多个文件 （xxx.properties），而且 不支持自动注入 ， 不支持前缀注入
2）、 @ConfigurationProperties 用于加载配置文件（application.properties | application.yml）。该注解功能更强大：
a、 支持前缀注入 （ prefix ）
b、 相同属性名的自动注入
c、 $("") 支持EL表达式注入
应用实例：
在以往的开发中通常会将数据库连接信息存放在单独的属性文件中（jdbc.properties）。而在spring boot 中我们会将数据库的信息存放在配置文件中，这会极大便利开发工作。
jdbc.properties：
可以通过 @Value 注解将配置文件的值注入到实体类中
也可以注入Environment ，通过Environment 获取值
1、 @ResponseBody
控制器方法返回值会使用 HttpMessageConverter 进行数据格式化，转化为JSON字符串。
同样的 ResponseBodyAdvice: 针对使用@ResponseBody的注解的类，方法做增强处理。
2、 @RestController
@RestController = @Controller + @ResponseBody ， 所以通常直接使用@RestController 注解
3、 @RequestBody
从Reuqest请求体中获取内容，绑定到方法的指定参数上。 SpringMVC 使用HttpMessageConverter 接口将请求体中的数据转化为方法参数类型。
SpringMVC 给用户对参数的处理提供了很大支配权。 我们可以使用 接口RequestBodyAdvice 来实现对参数进行拦截处理。
注意
1）、 RequestBodyAdvice : 针对所有以@RequestBody的参数做处理
2）、 自定义的处理对象类上必须得加上@ControllerAdvice注解!
利用此功能我们可以做以下处理工作：
1）、参数做解密处理。
2）、修改接受的参数数据。
4、 @RequestParam
从Request请求中获取指定的参数。
可以设置的属性：
1）、 required ： 默认为true 参数必须存在 。参数不存在时抛出异常(MissingServletRequestParameterException). 提示信息
2）、 defaultValue ： 设置参数默认值。 当参数没有提供或者为空值时生效, 包含隐式定义 required=false
3）、 name | value ， 互为别名的属性， 绑定请求中的参数名。 request.getParameter(name);
5、 @RequestMapping
用于设置 请求 和 Method 的映射关系。指明何种请求可以和方法匹配
可配置属性值：
1）、 path、value、 name, 互为别名，设置可以处理的url。
2）、 consumes，字符串数组。 指定可以处理的 媒资类型，仅当请求头中的 Content-Type 与其中一种媒体类型匹配时，才会映射请求。所以该配置会缩小可匹配的请求。 当url 匹配但是consumes不匹配时， 状态码415。 不设置的话，表示不限制媒资类型，参数的具体使用何种方式解析，SpringMVC会选择合适的处理器处理。
3）、 produces，字符串数组。 生成的媒资类型，该属性会影响实际的输出类型。和consumes一样，改配置会缩小匹配的范围。 只有当请求头中的 Accept 与 配置的任意一个媒资类型匹配时，才会映射请求。 当url 匹配与consumes不匹配时， 状态码406 。 比如：为了生成UTF-8编码的JSON响应，应使用 MediaType.APPLICATION_JSON_UTF8_VALUE。

spring mvc 怎么做全局异常处理

1、通过 @ControllerAdvice 对类进行注解。
2、可以使用 @ExceptionHandler、 @InitBinder、 @ModelAttribute 注解到方法上。
3、@ExceptionHandler：可以用于捕获所有的控制器里面的异常。