1. 项目缘起为什么我们需要一份“活的”注解手册干了这么多年Java从刚毕业时对着Override一脸懵到现在能对着Spring Boot里那一堆RestController、Autowired、Transactional如数家珍我越来越觉得注解这东西真是Java开发者绕不开的“必修课”。它不像语法基础学一遍就完事了注解更像是一个不断进化的生态。从JDK内置的寥寥几个到Spring全家桶铺天盖地的各种再到Lombok、MyBatis-Plus这些工具库带来的“魔法”注解的应用场景和复杂度都在指数级增长。我见过不少同事包括曾经的我自己对待注解的态度很“实用主义”用到哪个查哪个百度一下复制粘贴跑通就行。这当然没问题项目初期能快速推进。但问题往往在后面当Transactional的事务不生效时当Autowired注入失败报NoSuchBeanDefinitionException时当Lombok的Data和JPA的Entity在序列化时产生冲突时那种面对着一堆符号却不知从何下手的无力感非常折磨人。更别提面试了“Spring常用注解有哪些”这种问题背后面试官想听的绝不是你罗列名字而是你对它们生命周期、生效时机、组合使用的理解。所以大概两年前我开始有意识地整理自己的“注解知识库”。它不是一份静态的文档而是一个随着我遇到新问题、学习新技术、复习老知识而不断增补的“个人复习笔记”。今天分享的就是这份笔记的骨架和部分核心内容。我希望它不仅仅是一份列表更能成为一份带有“为什么”和“踩坑记”的实战指南。无论你是正在苦啃“Java八股文”准备面试的新手还是被RunWith、SneakyThrows这些“偏门”注解困扰的中级开发者或许都能在这里找到一些线索和启发。2. 注解的本质超越“标签”的元编程利器在深入具体注解之前我们必须先统一认知注解Annotation到底是什么很多初学者会把它理解为“标签”或“注释”这只说对了一小部分。更准确地说注解是Java提供的一种元数据形式它提供了一种在代码层面之外为程序元素类、方法、变量、参数等附加结构化信息的能力并且这些信息在编译时、类加载时或运行时可以被读取和处理。2.1 注解的底层机制与生命周期理解注解核心在于理解它的三个元注解Target,Retention,DocumentedInherited相对少用。这是所有自定义注解的基石。Target定义了注解可以应用在哪里。这是防止注解被滥用的第一道关卡。比如你把一个本该用于方法的注解用在了类上IDE会直接报错。它的取值ElementType包括TYPE类、接口、枚举FIELD字段包括枚举常量METHOD方法PARAMETER形参CONSTRUCTOR构造器LOCAL_VARIABLE局部变量ANNOTATION_TYPE注解类型PACKAGE包TYPE_PARAMETER类型参数泛型JDK 1.8TYPE_USE类型使用任何用到类型的地方JDK 1.8Retention定义了注解信息的保留策略即注解的生命周期。这是理解注解何时起效的关键。RetentionPolicy.SOURCE仅存在于源代码中编译后就被丢弃。典型代表是Override、SuppressWarnings。它们的作用是给编译器和开发者看不影响运行时。RetentionPolicy.CLASS被编译到.class文件中但不会被JVM加载到运行时。这是默认策略一些字节码处理工具如AspectJ的某些编译时织入会用到。RetentionPolicy.RUNTIME不仅存在于.class文件中还会被JVM加载因此在运行时可以通过反射机制读取。Spring、JPA等框架中绝大多数注解都是RUNTIME级别的因为框架需要在运行时根据这些注解来动态装配Bean、管理事务等。一个常见的误区认为注解本身能“做事”。其实注解本身是“被动”的它只是一段信息。真正“做事”的是读取并处理这些注解的代码。对于SOURCE级别的注解处理者是编译器对于RUNTIME级别的注解处理者是通过反射getAnnotation读取它们的框架或工具代码。2.2 自定义注解从理解到创造当你理解了元注解再看任何一个框架提供的注解都能一眼看穿它的基本设计意图。比如AutowiredTarget({ElementType.CONSTRUCTOR, ElementType.METHOD, ElementType.PARAMETER, ElementType.FIELD, ElementType.ANNOTATION_TYPE})Retention(RetentionPolicy.RUNTIME)。这意味着它可以用在构造器、方法等很多地方并且需要在运行时被Spring容器读取。Transactional同样是RUNTIME级别Spring在运行时通过AOP代理读取该注解的属性如propagation,isolation来管理事务边界。自己动手定义一个简单的注解是加深理解的最好方式。例如定义一个用于记录方法执行时间的注解Target(ElementType.METHOD) // 只能用在方法上 Retention(RetentionPolicy.RUNTIME) // 运行时保留方便我们通过AOP处理 public interface TimeMonitor { String value() default ; // 可以定义一个可选的描述信息 TimeUnit unit() default TimeUnit.MILLISECONDS; // 指定时间单位 }定义好后它自己不会做任何事。你需要一个“注解处理器”比如一个Spring AOP的切面Aspect Component public class TimeMonitorAspect { private static final Logger logger LoggerFactory.getLogger(TimeMonitorAspect.class); Around(annotation(monitor)) // 切入点是带有TimeMonitor注解的方法 public Object around(ProceedingJoinPoint joinPoint, TimeMonitor monitor) throws Throwable { long start System.nanoTime(); Object result joinPoint.proceed(); // 执行原方法 long end System.nanoTime(); long duration monitor.unit().convert(end - start, TimeUnit.NANOSECONDS); logger.info(方法 [{}] 执行耗时: {}{}, joinPoint.getSignature(), duration, monitor.unit()); return result; } }这个过程清晰地展示了注解的工作流声明Definition - 使用Usage - 处理Processing。绝大多数框架注解都是这个模式的复杂化、规模化应用。3. JDK内置注解被忽视的基石提到JDK注解很多人只能想到Override。其实它们虽然少但个个精悍是编写健壮、清晰代码的基础。3.1Override不仅仅是“重写”它的核心作用是声明性检查。编译器会检查该方法是否真的重写了父类或接口中的方法。如果没有则报编译错误。这能有效防止因拼写错误或签名不一致导致的“自以为重写”的bug。一个进阶用法在实现接口的默认方法Java 8时虽然从语法上不是必须的但显式地加上Override是一个好习惯能让代码意图更清晰。public interface MyInterface { default void defaultMethod() { System.out.println(默认实现); } } public class MyClass implements MyInterface { Override // 虽然不是必须但推荐加上 public void defaultMethod() { MyInterface.super.defaultMethod(); // 可以调用接口的默认实现 System.out.println(子类增强); } }3.2Deprecated优雅的API退役指南标记某个元素类、方法、字段已过时不推荐使用。编译器会在使用处产生警告。关键点在于forRemoval和since属性forRemoval true表示该API在未来的版本中一定会被删除警告级别通常更高。since指明从哪个版本开始被弃用便于追溯。最佳实践使用Deprecated时务必在JavaDoc中使用deprecated标签说明弃用的原因和替代方案。这是对API使用者最基本的尊重。/** * 旧的计算方式效率较低。 * deprecated 自 2.0 版本起请使用更高效的 {link #newCalculate(int)} 方法。 * param input 输入参数 * return 计算结果 */ Deprecated(since 2.0, forRemoval false) public int oldCalculate(int input) { // ... 旧逻辑 } public int newCalculate(int input) { // ... 新逻辑 }3.3SuppressWarnings与编译器警告的博弈用于抑制编译器产生的特定警告。这是一个需要慎用的注解因为警告通常是潜在问题的信号。理想情况是修复问题根源而非压制警告。常用参数值unchecked抑制泛型未检查转换的警告在使用原始类型或强制转换时常见。deprecation抑制使用Deprecated元素的警告。rawtypes抑制使用原始类型的警告。all抑制所有警告非常不推荐。使用原则作用域最小化尽量用在最内层的代码块如单个变量、方法而不是整个类。添加注释说明在压制警告的地方用注释写明理由例如“此处已知类型安全但API限制必须如此转换”。public void processList(List rawList) { SuppressWarnings(unchecked) // 注释已知传入的rawList实际为ListString ListString stringList (ListString) rawList; // ... 处理stringList }3.4FunctionalInterface函数式编程的契约Java 8引入用于标记一个接口是函数式接口即只包含一个抽象方法的接口。编译器会强制检查如果接口不符合函数式接口的定义有多个抽象方法则会报错。这增强了Lambda表达式使用的安全性和意图的明确性。FunctionalInterface // 加上它编译器会帮我们检查 public interface MyCalculator { int calculate(int a, int b); // 唯一的抽象方法 // 可以有多个默认方法或静态方法 default void printResult(int result) { System.out.println(Result: result); } } // 如果没有FunctionalInterface即使多了一个抽象方法编译也能通过但用Lambda时会出错。3.5SafeVarargs与堆污染警告应用于方法或构造器该方法的最后一个参数是可变参数T...且该方法内部不会对泛型可变参数数组进行不安全的操作如存储非T类型的对象用于抑制“堆污染”警告。堆污染是指将一个非泛型的对象赋值给一个泛型变量导致运行时ClassCastException。使用条件苛刻通常只有像java.util.Arrays.asList(T... a)、java.util.Collections.addAll(Collection? super T c, T... elements)这种完全确定类型安全的方法才适用。个人建议除非你在编写非常基础的泛型工具库否则很少需要自己使用这个注解。4. Spring核心注解IoC与AOP的骨架Spring的注解体系庞大但核心围绕两个概念控制反转IoC和面向切面编程AOP。4.1 模式注解Stereotype AnnotationsBean的声明这些注解用于标记一个类告诉Spring“请将我纳入你的容器进行管理”。它们本质上是Component的特化具有更明确的语义。Component万金油泛指任何Spring管理的组件。Service用于标记业务逻辑层Service层的类。语义上表示“这里是一个服务”。Repository用于标记数据访问层DAO层的类。它有一个额外的好处会自动将平台特定的持久化异常如SQLException转换为Spring的统一DataAccessException。这是使用Repository而非Component的一个重要理由。Controller用于标记Web控制层MVC中的Controller的类。Spring MVC会扫描它来处理HTTP请求。RestControllerSpring 4.0引入是Controller和ResponseBody的组合注解。标记的类所有方法默认返回JSON/XML等数据而非视图名。这是构建RESTful API的首选。Configuration这是一个特殊的注解它标记的类表示这是一个Spring配置类其内部通常包含Bean注解的方法用于显式定义Bean。它本身也被Component元注解标注所以Configuration类本身也是一个Bean。4.2 依赖注入注解组装你的应用AutowiredSpring提供的依赖注入注解。默认按类型byType自动装配。它的注入方式有三种构造器注入推荐Spring 4.3以后如果类只有一个构造器Autowired可以省略。这是目前最推崇的方式因为它保证了依赖不可变且便于测试。Setter方法注入。字段注入Field Injection最简洁但也是最不推荐的方式因为它让类对Spring容器产生了强依赖不利于单元测试必须通过反射设置私有字段。常见问题当存在多个同类型Bean时会抛出NoUniqueBeanDefinitionException。此时需要配合Qualifier注解指定Bean的名称。ResourceJSR-250标准注解功能与Autowired类似。主要区别在于默认的匹配策略Autowired默认按类型Resource默认按名称byName如果找不到再按类型。它有一个name属性用于精确指定Bean名。在一些非Spring的Java EE环境中更通用。关于Resource与构造器注入的效率这是一个在热词中看到的有趣问题。从性能角度讲在应用启动、Bean创建和依赖注入阶段两者效率差异微乎其微不应成为选型依据。选型应基于设计原则强推构造器注入可省略Autowired以保证不可变性和可测试性如果必须使用字段/Setter注入在纯Spring环境下用Autowired语义更清晰在需要与JSR-250标准兼容或习惯按名注入的场景用Resource。InjectJSR-330标准注解功能与Autowired几乎完全一样需要额外的依赖如javax.inject。在Spring中可以把它看作是Autowired的标准替代品但不如Autowired功能丰富例如不支持requiredfalse。Value用于注入外部配置properties/yml的值或SpEL表达式结果。它是将配置与代码连接起来的桥梁。Value(${server.port}) // 注入配置文件中的值 private int port; Value(#{systemProperties[user.home]}) // SpEL表达式 private String userHome; Value(默认值) // 直接注入字符串 private String defaultValue;4.3 配置与Bean定义注解Bean用在Configuration类的方法上方法名默认即为Bean的名称返回值类型即为Bean的类型。用于定义那些无法通过Component扫描的Bean如第三方库的类、需要复杂初始化逻辑的Bean。Configuration public class AppConfig { Bean public MyService myService() { return new MyServiceImpl(someDependency()); // 可以调用其他Bean方法 } Bean(name dataSource) // 指定Bean名称 public DataSource dataSource() { // 创建并配置DataSource } }Scope定义Bean的作用域。常用的有singleton默认容器中只有一个实例。prototype每次请求都创建一个新实例。request、session、applicationWeb作用域。Profile指定Bean在哪个环境配置激活时才被注册。是实现“环境隔离”的利器。Configuration Profile(dev) // 仅在dev环境生效 public class DevConfig { /* ... */ } Bean Profile(prod) // 这个Bean仅在prod环境生效 public DataSource prodDataSource() { /* ... */ }Primary当存在多个同类型Bean时标记为首选BeanAutowired会优先注入它。Lazy延迟初始化。标记为Lazy的Bean只有在第一次被请求时才会创建。注意与RequiredArgsConstructor的冲突热词中提到Lombok的RequiredArgsConstructor会在编译时生成一个包含所有final字段的构造器。如果某个final字段对应的Bean被标记为LazySpring需要在构造器注入时提供该Bean但Lazy又要求延迟创建这就产生了矛盾。解决方案是不要在final字段上使用Lazy或者不使用RequiredArgsConstructor改为手动编写构造器并在参数上使用Lazy。// 错误示例Lombok生成的构造器无法处理字段上的Lazy Component RequiredArgsConstructor public class MyService { Lazy private final HeavyBean heavyBean; // 冲突 } // 正确做法手动编写构造器 Component public class MyService { private final HeavyBean heavyBean; public MyService(Lazy HeavyBean heavyBean) { // 参数上使用Lazy this.heavyBean heavyBean; } }4.4 AOP与事务注解Transactional声明式事务管理的核心。标注在类或方法上。它是通过Spring AOP代理实现的因此要理解其生效条件方法必须是public。protected、private、包可见方法上的Transactional无效因为Spring的AOP代理默认使用JDK动态代理或CGLIB无法拦截这些方法。必须通过代理对象调用。在同一个类中一个非事务方法A调用同一个类中的事务方法B事务是不会生效的因为A调用B是this.B()绕过了代理。这是最常见的坑。默认只对RuntimeException和Error回滚。受检异常Exception不会触发回滚。可以通过rollbackFor属性指定。传播行为Propagation是关键REQUIRED默认有则加入无则新建、REQUIRES_NEW新建事务挂起当前、NESTED嵌套事务、SUPPORTS、NOT_SUPPORTED、MANDATORY、NEVER。理解它们对设计复杂业务逻辑至关重要。EnableAspectJAutoProxy在Configuration类上使用启用Spring对AspectJ切面注解的支持。有了它Aspect、Before、After、Around等注解才能工作。Aspect标记一个类是切面Aspect其中包含通知Advice和切点Pointcut。Pointcut声明一个可重用的切点表达式。Aspect Component public class LoggingAspect { Pointcut(execution(* com.example.service.*.*(..))) public void serviceLayer() {} Before(serviceLayer()) public void logBefore(JoinPoint joinPoint) { // 记录方法调用前日志 } }4.5 Spring MVC注解RequestMapping映射HTTP请求到处理器方法。可以定义在类路径前缀和方法上。有更具体的派生注解GetMapping,PostMapping,PutMapping,DeleteMapping,PatchMapping。RequestParam绑定请求参数到方法参数。可以指定默认值defaultValue和是否必需required。PathVariable绑定URI模板变量到方法参数。RequestBody将请求体如JSON绑定到方法参数通常配合RestController使用。ResponseBody将方法返回值直接写入HTTP响应体。RestControllerAdvice/ControllerAdvice全局异常处理、数据绑定、数据预处理。可以定义ExceptionHandler、ModelAttribute、InitBinder等方法作用于所有Controller。CookieValue,RequestHeader获取Cookie和请求头信息。CrossOrigin处理跨域请求CORS。5. 常用工具库注解提升开发效率5.1 Lombok代码生成器Lombok通过在编译时使用注解处理器生成代码如getter、setter、构造器极大减少了样板代码。但务必确保你的IDE安装了Lombok插件并且构建工具Maven/Gradle配置了Lombok依赖否则会看到“找不到getter/setter”的编译错误或警告如热词中提到的“you aren‘t using a compiler supported by lombok”。Data最常用的注解是Getter、Setter、ToString、EqualsAndHashCode和RequiredArgsConstructor的集合。注意它为所有非静态、非final字段生成setter如果你有字段不希望被修改请单独使用Getter。Getter/Setter生成getter/setter。NoArgsConstructor生成无参构造器。AllArgsConstructor生成全参构造器。RequiredArgsConstructor生成包含所有final字段和标记了NonNull的字段的构造器。注意与Lazy的冲突问题前文已述。ToString生成toString()方法可通过exclude排除字段。EqualsAndHashCode生成equals()和hashCode()方法。Builder实现建造者模式非常方便地创建不可变对象。Slf4j/Log4j2自动注入一个日志对象log。SneakyThrows这个注解比较“神奇”它允许你在方法上不声明受检异常却可以抛出它们。Lombok会在编译时生成一个try-catch块将受检异常包装成RuntimeException抛出。慎用因为它破坏了Java的异常检查机制除非你非常清楚自己在做什么例如在Lambda表达式中处理受检异常。SneakyThrows(IOException.class) public void readFile() { Files.readAllBytes(Paths.get(file.txt)); // 本应抛出IOException } // 编译后相当于 public void readFile() { try { Files.readAllBytes(Paths.get(file.txt)); } catch (IOException e) { throw Lombok.sneakyThrow(e); // 一个特殊方法骗过编译器 } }5.2 持久层框架注解JPA (Jakarta Persistence) / Hibernate:Entity标记类为JPA实体对应数据库表。Table指定实体对应的表名。Id标记主键。GeneratedValue指定主键生成策略。Column映射字段到列。OneToMany,ManyToOne,ManyToMany,OneToOne定义实体关联关系。Transient标记字段不持久化到数据库。CreationTimestamp,UpdateTimestamp(Hibernate特有)自动管理创建/更新时间。MyBatis-Plus:TableName指定实体对应的表名。TableId标记主键并可指定类型如IdType.AUTO。TableField映射字段可指定是否为主键exist、字段填充策略fill等。Version乐观锁注解。InterceptorIgnore忽略某些拦截器如多租户插件热词中提到的“基于mybatis-plus的多租户注解实现”通常需要配合此注解或自定义注解来忽略某些不需要租户隔离的操作。5.3 测试相关注解JUnit 5:Test标记测试方法。BeforeEach/AfterEach每个测试方法前后执行。BeforeAll/AfterAll所有测试方法前后执行静态方法。DisplayName为测试类或方法设置显示名称。Disabled禁用测试。ParameterizedTest参数化测试。Spring Boot Test:SpringBootTest启动完整的Spring应用上下文进行集成测试。WebMvcTest专注于Web MVC层的测试不会加载完整的上下文如Service, Repository。DataJpaTest专注于JPA层的测试使用内存数据库。MockBean将Mock对象添加到Spring应用上下文。TestConfiguration用于测试的额外配置。RunWith(JUnit 4) /ExtendWith(JUnit 5)这是热词中的一个问题。RunWith是JUnit 4的注解用于指定测试运行器。在Spring Boot测试中常见的是RunWith(SpringRunner.class)它负责加载Spring的测试上下文。在JUnit 5中它被ExtendWith(SpringExtension.class)取代。SpringBootTest已经集成了ExtendWith所以通常不需要显式写出。6. 注解的“坑”与最佳实践注解用好了事半功倍用不好就是埋雷。下面是一些我踩过或见过的典型问题。6.1 失效场景深度剖析Transactional失效自调用问题同一个类中非事务方法A调用事务方法B。解决将方法B移到另一个Service或使用AopContext.currentProxy()获取代理对象再调用不优雅或使用AspectJ的编译时织入LTW。异常被捕获事务方法内部捕获了异常并未重新抛出事务管理器感知不到异常不会回滚。非RuntimeException抛出了受检异常但未在Transactional中通过rollbackFor指定。方法非public。数据库引擎不支持事务如MySQL的MyISAM引擎。Autowired注入失败NoSuchBeanDefinitionException最常见。检查类是否被Component或其派生注解标记包路径是否在ComponentScan的扫描范围内。多个同类型Bean使用Qualifier或Primary解决。循环依赖Circular DependencyA依赖BB也依赖A。Spring通过三级缓存能解决构造器注入之外的循环依赖但这是糟糕设计的信号应通过重构引入第三方类、使用Lazy、改为Setter注入来避免。Lombok注解不生效IDE未安装插件这是报“cannot find symbol getter/setter”的主要原因。构建工具未配置注解处理器确保Maven的lombok依赖范围是provided并且编译器插件如maven-compiler-plugin配置正确。与其他注解处理器冲突例如MapStruct。需要在Maven中明确指定注解处理器的执行顺序。6.2 组合注解与元注解的理解Spring中很多注解都是“组合注解”Composed Annotation。例如RestControllerControllerResponseBody。理解这一点有助于你阅读源码和自定义注解。你可以定义自己的组合注解来简化代码。例如你系统中所有API都需要ApiOperationSwagger和统一的RequestMapping前缀Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) RequestMapping(value /api/v1, method RequestMethod.GET) // 元注解 ApiOperation(value 查询接口) // 元注解 public interface MyApiGet { String value() default ; // 可以覆盖RequestMapping的路径 } // 使用 MyApiGet(/users) public ListUser getUsers() { ... } // 等价于 GetMapping(/api/v1/users) ApiOperation(查询用户列表) public ListUser getUsers() { ... }6.3 性能与设计考量反射开销RUNTIME级别的注解依赖反射读取。虽然Spring等框架对反射结果有缓存但在极端高性能场景大量使用注解仍需留意。不过对于绝大多数业务系统这个开销可以忽略不计。注解的滥用避免为了用注解而用注解。如果一个简单的命名约定或设计模式就能清晰表达意图可能比加一个晦涩的注解更好。注解增加了代码的“魔法”属性会让新读者更难理解。保持注解的简洁性自定义注解时属性不宜过多语义要明确。一个注解只做一件事。7. 自定义注解实战实现一个简易审计日志让我们综合运用以上知识实现一个简单的审计日志注解记录敏感操作的执行者、时间和内容。第一步定义注解Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface AuditLog { String module(); // 操作模块如“用户管理” String operation(); // 操作类型如“删除用户” boolean recordParams() default true; // 是否记录方法参数 }第二步实现切面处理器Aspect Component Slf4j public class AuditLogAspect { // 注入获取当前用户的服务需要你自行实现如从SecurityContext获取 Autowired private CurrentUserService currentUserService; Around(annotation(auditLog)) public Object around(ProceedingJoinPoint joinPoint, AuditLog auditLog) throws Throwable { String username currentUserService.getCurrentUsername(); String methodName joinPoint.getSignature().toShortString(); Object[] args joinPoint.getArgs(); // 记录操作开始 log.info([审计开始] 用户[{}], 模块[{}], 操作[{}], 方法[{}], username, auditLog.module(), auditLog.operation(), methodName); if (auditLog.recordParams()) { log.info([审计参数] {}, Arrays.toString(args)); } long startTime System.currentTimeMillis(); Object result; try { result joinPoint.proceed(); // 执行原方法 } catch (Throwable e) { log.error([审计异常] 用户[{}], 操作[{}] 失败异常{}, username, auditLog.operation(), e.getMessage()); throw e; // 异常继续抛出 } finally { long endTime System.currentTimeMillis(); log.info([审计结束] 用户[{}], 操作[{}], 耗时[{}ms], username, auditLog.operation(), (endTime - startTime)); } return result; } }第三步在Service方法上使用Service public class UserService { AuditLog(module 用户管理, operation 删除用户) public void deleteUser(Long userId) { // ... 删除用户逻辑 } }这个简单的例子展示了从注解定义、到AOP处理、再到实际应用的全过程。你可以根据需要扩展它比如将日志存入数据库或者通过Around中的JoinPoint对象获取更丰富的信息如被注解方法所属的类、注解本身的属性等。注解的世界浩如烟海这份笔记也只是我个人在学习和项目中积累的一部分。它的价值不在于“全”而在于“活”——我会持续把遇到的新注解、新用法、新坑记录进来并反复回顾那些核心注解的原理。希望这份不断生长的“注解地图”也能帮助你在Java开发的路上走得更稳、更远。记住理解一个注解永远不要停留在“怎么用”多问一句“它为什么能工作”很多问题就迎刃而解了。