本文共 6036 字，大约阅读时间需要 20 分钟。

前言

我们都知道Springboot框架遵循着“约定大于配置”的设计原则，极大地简化了项目的配置，使得开发人员有更多的精力投入到业务逻辑的开发中。而注解机制很好的说明了这一点，但是这也很容易使得开发人员很迷糊这些注解的使用，尤其对于入门的同学就更加不知所云了。这里总结了一些，希望对大家有用。

注解优势

• 直接纯Java 代码编写，无需配置繁杂的XML文件
• 在配置中也可享受面向对象带来的好处
• 类型安全对重构可以提供良好的支持
• 减少复杂配置文件的同时亦能享受到 spring IoC 容器提供的功能

Springboot注解

项目配置注解

@Configuration

相当于传统的xml配置文件，如果有些第三方库需要用到xml文件，建议仍然通过@Configuration类作为项目的配置主类——可以使用@ImportResource注解加载xml配置文件。

@MapperScan

它和@mapper注解是一样的作用，不同的地方是扫描入口不一样。@mapper需要加在每一个mapper接口类上面。所以大多数情况下，都是在规划好工程目录之后，通过@MapperScan注解配置路径完成mapper接口的注入。

同时@MapperScan是Springboot支持mybatis组件的一个注解，通过此注解指定mybatis接口类的路径，即可完成对mybatis接口的扫描。

@SpringBootApplication

该注解等同于@Configuration、@EnableAutoConfiguration、@ComponentScan 三个注解：

• @Configuration：标注当前类是配置类，这个注解继承自@Configuration。并会将当前类内声明的一个或多个以@Bean注解标记的方法的实例纳入到spring容器中，并且实例名就是方法名。

• @EnableAutoConfiguration：自动配置的注解，这个注解会根据我们添加的组件jar来完成一些默认配置，我们做微服时会添加spring-boot-starter-web这个组件jar的pom依赖，这样配置会默认配置springmvc 和tomcat。

• @ComponentScan：扫描当前包及其子包下被@Component、@Controller、@Service、@Repository注解标记的类并纳入到Spring容器中进行管理。等价于context:component-scan的xml配置文件中的配置项。

@ServletComponentScan

在SpringBootApplication上使用@ServletComponentScan注解后，Servlet、Filter、Listener可以直接通过@WebServlet、@WebFilter、@WebListener注解自动注册，这样通过注解servlet、拦截器和监视器的功能而无需其他代码。

资源注入注解

• @ImportResource：用来加载xml配置文件。

• @Import：用来导入其他配置类。

@PropertySource：导入property的配置文件 @PropertySource用来指定文件路径，相当于使用Spring的标签来完成配置项的引入。

控制层注解

@RestController

用于标注控制层组件(如struts中的action)，@ResponseBody和@Controller的合集。

• @ResponseBody：表示该方法的返回结果直接写入HTTP response body中，一般在异步获取数据时使用，用于构建RESTful的api。在使用@RequestMapping后，返回值通常解析为跳转路径，加上@esponsebody后返回结果不会被解析为跳转路径，而是直接写入HTTP response body中。比如异步获取json数据，加上@Responsebody后，会直接返回json数据。该注解一般会配合@RequestMapping一起使用。

• @Controller：用于定义控制器类，在spring项目中由控制器负责将用户发来的URL请求转发到对应的服务接口（service层），一般这个注解在类中，通常方法需要配合注解@RequestMapping。

@RequestMapping

此注解可以用在class和method上，用来映射web请求到某一个handler类或者handler方法上。当此注解用在Class上时，就创造了一个基础url，其所有的方法上的@RequestMapping都是在此url之上的。可以使用其method属性来限制请求匹配的http method。Spring4.3后推出了一系列的RESTful的注解：

@CrossOrigin

@CrossOrigin(origins = “”, maxAge = 1000) 这个注解主要是为了解决跨域访问的问题。这个注解可以为整个controller配置启用跨域，也可以在方法级别启用。

@CrossOrigin(maxAge = 3600)@RestController@RequestMapping("/users")public class AccountController {

   @CrossOrigin(origins = "http://baidu.com")
@RequestMapping("/login")
public Result userLogin() {

   // ...
}}

@EnablCaching

这个注解Spring framework中的注解驱动的缓存管理功能。自spring版本3.1起加入了该注解。其作用相当于spring配置文件中的cache manager标签。

@RequestParam

此注解用在请求handler方法的参数上，用于将http请求参数的值绑定到参数上。

@RequestMapping("/user")
@ResponseBody
public String getUserId(@RequestParam("id") int Id) {

   return "Id = " + Id;
}

@PathVariable

路径变量注解，@RequestMapping中用{}来定义url部分的变量名。

@RequestMapping(value="/{activityId}",method=RequestMethod.GET)public Result
   
     quesryOtherActivity(@PathVariable("activityId") Long activityId){

    
 return otherActivityManageBiz.queryOtherActivity(activityId);}
   

@CookieValue

此注解用在@RequestMapping声明的方法的参数上，可以把HTTP cookie中相应名称的cookie绑定上去。

@ReuestMapping("/cookieValue")
  public void getCookieValue(@CookieValue("JSESSIONID") String cookie){
   }

服务层注解

@Autowired

该注解用于Bean的field、setter方法以及构造方法上，显式地声明依赖。根据type来autowiring。当在field上使用此注解，并且使用属性来传递值时，Spring会自动把值赋给此field。也可以将此注解用于私有属性(不推荐)。

@Service

这个注解用来标记业务层的组件，我们会将业务逻辑处理的类都会加上这个注解交给spring容器。事务的切面也会配置在这一层。当然这个注解不是一定要用。有个泛指组件的注解，当我们不能确定具体作用的时候，可以用泛指组件的注解托付给spring容器。

@Resource

@Resource和@Autowired一样都可以用来装配bean，都可以标注字段上，或者方法上。@resource注解不是spring提供的，是属于J2EE规范的注解。

持久层注解

@Transactional

通过这个注解可以声明事务，可以添加在类上或者方法上。

在spring boot中 不用再单独配置事务管理，一般情况是我们会在servcie层添加了事务注解，即可开启事务。要注意的是，事务的开启只能在public 方法上。并且主要事务切面的回滚条件。正常我们配置rollbackfor exception时 ，如果在方法里捕获了异常就会导致事务切面配置的失效。

@Repository

@Repository注解类作为DAO对象，管理操作数据库的对象。

JPA注解

• @Entity@Table(name=”“)：表明这是一个实体类。一般用于jpa这两个注解一般一块使用，但是如果表名和实体类名相同的话，@Table可以省略

• @Id：表示该属性为主键。

• @GeneratedValue:@GeneratedValue(strategy=GenerationType.SEQUENCE,generator=“repair_seq”)：表示主键生成策略是sequence（可以为Auto、IDENTITY、native等，Auto表示可在多个数据库间切换），指定sequence的名字是repair_seq。

• @Basic：@Basic(fetch=FetchType.LAZY)：标记可以指定实体属性的加载方式

• @Column：如果字段名与列名相同，则可以省略。

• @Transient：表示该属性并非一个到数据库表的字段的映射,ORM框架将忽略该属性。如果一个属性并非数据库表的字段映射,就务必将其标示为@Transient,否则,ORM框架默认其注解为@Basic。@Basic(fetch=FetchType.LAZY)：标记可以指定实体属性的加载方式

• @MappedSuperClass：用在确定是父类的entity上。父类的属性子类可以继承。

• @NoRepositoryBean：一般用作父类的repository，有这个注解，spring不会去实例化该repository。

Java对象与JSON转化注解

• @JsonSerialize：作用在类或字段上，转化java对象到json格式（需自定义转化类继承JsonSerializer）

• @JsonDeserialize：作用在类或字段上，转化json格式到java对象（需自定义转化类继承JsonDeserializer）

• @JsonIgnore：在json序列化时将java bean中的一些属性忽略掉，序列化和反序列化都受影响

• @JsonProperty：作用在属性上，把属性名称序列化为另一个名称（trueName属性序列化为name）

• @JsonIgnoreProperties(ignoreUnknown = true)：作用在类上，忽略掉json数据里包含了实体类没有的字段

• @JsonFormat(pattern=“yyyy-MM-dd HH:mm:ss”,timezone=“GMT+8”)

将Date属性转换为String类型， timezone解决（相差8小时）

Lombok注解

• @Getter：注解在属性上；为属性提供 setting 方法

• @Setter：注解在属性上，为属性提供 getting 方法

• @Data：注解在类上，提供类所有属性的 getting 和 setting 方法，此外还提供了equals、canEqual、hashCode、toString 方法

• @Log4j2：注解在类上，为类提供一个 属性名为log 的 log4j 日志对象，和@Log4j注解类似

• @NoArgsConstructor：注解在类上，为类提供一个无参的构造方法

• @AllArgsConstructor：注解在类上，为类提供一个全参的构造方法

• @EqualsAndHashCode：默认情况下，会使用所有非瞬态(non-transient)和非静态(non-static)字段来生成equals和hascode方法，也可以指定具体使用哪些属性。

• @toString：生成toString方法，默认情况下，会输出类名、所有属性，属性会按照顺序输出，以逗号分割。

• @val：注解在属性上，如果注解了，就是设置为final类型，可查看源码的注释知道

• @NonNull：注解在属性上，如果注解了，就必须不能为Null

其他注解

全局异常处理注解

• @ExceptionHandler：用在方法上面表示遇到 ExceptionHandler 异常就执行以下方法(Exception.class)。

• @ControllerAdvice：包含@Component都可以被扫描到，并统一处理异常。

任务执行与调度注解

• @Scheduled：此注解使用在方法上，声明此方法被定时调度。使用了此注解的方法返回类型需要是Void，并且不能接受任何参数。

• @Async：此注解使用在方法上，声明此方法会在一个单独的线程中执行。不同于Scheduled注解，此注解可以接受参数。

测试注解

• @ContextConfiguration：此注解使用在Class上，声明测试使用的配置文件，此外，也可以指定加载上下文的类。

• @SpringBootTest：一般情况下，使用@SpringBootTest后，Spring将加载所有被管理的bean，基本等同于启动了整个服务，此时便可以开始功能测试。

总结

虽然Spring为了方面我们的开发，提供了许多的简单且很方便的注解，比如@Autowired, @Aspect相关的注解等等。它会让我们的业务代码条理清晰，更加简洁，而Springboot作为Spring框架的扩展，显然是继承了这一点。

可是，当我们对Springboot/Spring源码或者其他依赖这两者框架的项目源码进行分析时，都发现，在它们的源码里很少对这些注解进行使用。反之，它们更喜欢InitializingBean、DisposableBean、DefaultPointcutAdvisor等等具有相同功能的接口或类来代替Spring的注解。

同时，我们知道注解往往是通过反射的方式去实现的，在性能方面还是没有直接实现方式效率高。因此，开发中更倾向于哪种方式，根据需求所取噢，我个人比较倾向于注解方式。

转载地址：https://blog.csdn.net/weixin_43452424/article/details/113247166 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！