企业官网建设流程全解析

1. 为什么Spring最核心的不是IoC，而是这套组件思维

先聊一个可能颠覆认知的观点：很多人在学Spring时盯着IoC、AOP、事务这些名词死磕，但真正把Spring用明白的标志，是你搞清楚“组件”这两个字意味着什么。Spring框架的所有能力，本质上都是在管理“组件”的生命周期和它们之间的关系。所谓组件（Bean），就是你项目里那些由Spring容器创建并维护的对象——Service、Mapper、Controller、配置类、工具类，凡是交给容器管的，都算。而“注解”，则是你告诉容器“这个类是组件、那个方法要怎么处理”的声明方式。

把这两个词放在一起看，Spring的开发模式就变得非常清晰：你用注解声明意图，容器负责执行。这种模式带来的最大好处是解耦。以前你写代码，new一个对象、手动set依赖、自己管生命周期，代码里全是创建逻辑；现在你只需要在类上标一个@Component，在字段上标一个@Autowired，剩下的交给容器。代码的职责只剩业务本身，对象怎么来、什么时候销毁，都不是你操心的事。

这篇文章要聊的，就是Spring组件体系里最核心的注解、它们的原理、以及我在实际项目中踩过的那些坑。适合刚学完Spring基础语法、准备真正上手项目的同学，也适合用Spring写了一阵子代码但对“为什么这么做”还一知半解的开发者。我会尽量把每个注解背后的设计意图讲清楚，因为理解意图比记住用法重要得多。

2. 组件扫描与注册：容器是怎么知道“谁是组件”的

2.1 没有注解的年代，人是怎么被逼疯的

先花一点时间回忆历史，不然你不会理解注解到底解决了什么问题。Spring早期版本（2.x之前）是纯XML配置驱动的。你要让一个类变成容器管理的组件，得先写一个类，然后在applicationContext.xml里加上一行：

<bean id="userService" class="com.example.service.UserService"/>

如果这个Bean还有依赖，还得继续配：

<bean id="userService" class="com.example.service.UserService"> <property name="userDao" ref="userDao"/> </bean>

一个几十个类的模块，XML文件轻松超过几百行。每次新增一个类，都要同步改XML；每次改依赖关系，都要在两个文件之间跳来跳去。最崩溃的是，一旦XML里某个类名拼错，启动时才会报错，排查成本非常高。

后来Spring引入了注解（大概2.5版本开始支持），但你仍然需要手动在XML里逐个声明：

<bean class="com.example.service.UserService"/> <bean class="com.example.dao.UserDao"/> <bean class="com.example.controller.UserController"/>

其实省不了多少事。直到<context:component-scan>出现，这个问题才真正解决——你只需要告诉Spring“去这个包下面扫”，它会把符合条件的类全部自动注册为Bean。这就是组件扫描的雏形，也是@Component系列注解登场的背景。

2.2 组件注册注解家族：不只是@Component

@Component是最基础的组件注解，但它不是一个孤家寡人，而是一个家族的“父辈”。在这个家族里，最常用的是这四个：

从功能上讲，这四个注解的作用对容器来说完全一样——它们都会被识别为“需要注册的Bean”。区别在于语义上和额外行为上。@Repository会被Spring的持久化异常转换机制识别，把底层数据库异常统一翻译成Spring的DataAccessException体系；@Controller则额外支持@RequestMapping等方法映射注解的解析。@Service和@Component在行为上几乎无差别，纯粹是开发者用语义做自我约束。

这就产生了一个实际决策问题：到底用哪个？我的建议很简单——分层明确的项目，按层选：Controller层用@Controller，Service层用@Service，DAO层用@Repository，层层对应的好处是代码阅读成本低，团队协作时扫一眼注解就知道类的职责。工具类、配置类、第三方适配类，没有明确归属的，一律用@Component。别为了省事全用@Component，短期是省了，长期代码的可读性和可维护性会打折扣。

2.3 手动注册的另一条路：@Configuration + @Bean

组件扫描解决的是“我写好的类自动注册”，但现实中有一类Beans是无法用扫描搞定的——第三方库的对象。比如你引入了一个Redis客户端、一个消息队列的ConnectionFactory、一个模板引擎，这些类的源码不是你的，你不能往它们头上加@Component。此时就需要手动注册：

@Configuration public class RedisConfig { @Bean public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) { RedisTemplate<String, Object> template = new RedisTemplate<>(); template.setConnectionFactory(factory); // 设置序列化器... return template; } }

@Configuration本身也是@Component的衍生注解，所以配置类也会被扫描注册。@Bean则声明在方法上，告诉容器“这个方法的返回值需要注册为一个Bean”，方法名的默认行为是Bean的名称。

这里有个经典问题：@Configuration和@Component都能让配置类生效，但Spring内部对二者的处理不同。@Configuration类会被CGLIB代理，确保其中的@Bean方法单例语义正确——你在一个方法里调用另一个@Bean方法时，拿到的是容器里的同一个实例，而不是new出来的新对象。如果你把@Configuration误写成@Component，代理就失效了，可能出现单例Bean被多次创建的问题。实际开发中我强烈建议：配置类永远用@Configuration，不要用@Component代替。

3. 依赖注入的核心：@Autowired的解析过程与使用禁忌

3.1 自动装配到底是怎么找到Bean的

@Autowired是Spring容器里使用频率最高的注解，它做的事情只有一件：把容器中已经注册好的Bean，注入到当前需要它的地方。但“找到合适的Bean”这个过程，远比看起来复杂。Spring在解析@Autowired时，遵循一个严格的查找顺序：

第一，按照类型（byType）查找。容器里有没有这个类型的Bean？如果有且只有一个，直接注入。这是最常见的场景，比如你定义一个UserService userService，容器里恰好只有一个UserService类型的Bean，完事儿。

第二，如果按类型找到了多个，就按名称（byName）匹配。Spring会拿字段名去跟Bean的名称做比对。你写private UserService userService;，容器里有userService和userService2两个Bean，它会选择名为userService的那个。这就是为什么字段名最好跟类名默认生成的Bean名称一致——不一致会引发歧义甚至报错。

第三，如果按名称也没匹配上，报NoUniqueBeanDefinitionException。这是Spring实战中最常见的报错之一，提示你找到了多个同类型的Bean，但不知道该用哪个。

第四，如果按类型一个都没找到，会分两种情况：如果@Autowired的required属性默认是true，直接报NoSuchBeanDefinitionException；如果设置成required = false，则注入null，相当于“可选的依赖”。

这个解析顺序，我建议每个用到Spring的人都背下来。很多依赖注入问题，追根到底都是对这个顺序理解不透彻导致的。

3.2 解决歧义的三件套：@Primary、@Qualifier、@Resource

上面说了，多个同类型Bean时可能报错。但容器有多个同类型Bean这件事本身不是错误——比如你有两个DataSource，一个连主库、一个连报表库；有两个RestTemplate，一个带超时配置、一个不带。这时候就需要显式指定到底注入哪个。

@Primary是最简单的方案。在其中一个Bean上标注，表示“默认优先级”。这样按类型查找时，Spring会优先选择这个Bean。注意@Primary适合“有明确默认选择”的场景，两个Bean的权重天然不相等时用。

@Qualifier则是精确点名。它既可以用在注入点：

@Autowired @Qualifier("reportDataSource") private DataSource dataSource;

也可以用在@Bean方法上，给Bean起一个更明确的名字：

@Bean @Qualifier("reportDataSource") public DataSource reportDataSource() { ... }

这里的逻辑是：如果字段名和Bean名不一致，或者你压根不想依赖字段名来匹配，就用@Qualifier("beanName")强制指定。我个人的习惯是，在写注入代码时，优先保证字段名和数据源的语义一致；只有出现多实例歧义时，才引入@Qualifier。这样代码看起来最自然，不会出现用@Qualifier("a")指着字段b的奇怪场面。

@Resource是JDK自带的注解，Spring也支持它。它的查找顺序正好相反——先按名称匹配，再按类型匹配。如果你需要“按名字精确拿一个Bean”，@Resource(name = "xxx")会比@Qualifier更直白。但要注意，@Resource不支持required属性，也就是说不存在“找不到就注入null”的写法。

3.3 循环依赖与三级缓存：为什么报错，什么时候是安全的

“循环依赖”是Spring面试和实战中都绕不开的话题。最典型的场景：ServiceA依赖ServiceB，ServiceB又依赖ServiceA，两个对象互相引用。如果Spring在创建ServiceA时发现需要ServiceB，于是转而创建ServiceB，ServiceB创建时又需要ServiceA——而ServiceA还没创建完，这就陷入了死锁。

Spring解决这个问题用了一套叫“三级缓存”的机制。记住三个Map：一级缓存singletonObjects存放完整创建好的成品Bean；二级缓存earlySingletonObjects存放“提前暴露的半成品Bean”，也就是实例已经new出来了、但属性还没有完全填充完的对象；三级缓存singletonFactories存放ObjectFactory，也就是“能生产这个半成品”的工厂。

解决思路是：在ServiceA实例化完成、属性填充之前，Spring先把一个“半成品的ServiceA”通过三级缓存暴露出去；ServiceB创建时发现自己需要ServiceA，就能从缓存里拿到这个半成品，先注入进去完成自己的创建；ServiceB创建完了，回头再让ServiceA把缺的属性补上。这样就打破了死循环。

但有几个前提让这个机制并不通用：只对单例（Singleton）作用域有效，prototype作用域直接不支持循环依赖；只对字段/setter注入有效，构造器注入因为发生在实例化阶段，Bean还没暴露缓存就已经排队等着了，天然无法处理循环依赖。所以实际项目中如果遇到构造器注入导致的循环依赖，报错信息会非常明确，最好的解法不是“绕过”，而是重构设计——比如把一个Service里依赖对方的逻辑抽出去，由第三个Service统一编排。

我自己有一个经验：代码里出现循环依赖时，不管Spring能不能处理，都应该警觉。它大概率说明你的类职责划分出了问题——两个Service互相调用彼此的公共方法，往往是“分层的边界被打破了”。Spring的三级缓存是保命机制，不是设计护栏。

3.4 @Autowired加到哪：字段、setter、还是构造器

@Autowired可以放在三种位置，各有取舍。

放在字段上是最常见的写法，代码最简洁：

@Service public class OrderService { @Autowired private OrderDao orderDao; }

但坏处也很明显：外部无法直接看到依赖关系，单元测试时不通过Spring容器就很难注入mock对象；字段被直接反射注入，对封装是一种破坏。

放在setter方法上：

@Autowired public void setOrderDao(OrderDao orderDao) { this.orderDao = orderDao; }

允许你在注入时附加逻辑，比如校验非空、设置默认值。但这种写法在SpringBoot时代比较少见，一般用于需要“注入后处理”的场景。

放在构造器上，在Spring 4.3之后的版本，如果你的类只有一个构造器，甚至可以不写@Autowired，容器会自动使用这个构造器：

@Service public class OrderService { private final OrderDao orderDao; public OrderService(OrderDao orderDao) { this.orderDao = orderDao; } }

这种写法的最大好处是依赖关系清晰——所有依赖在对象创建时就必须提供，没有“先创建再慢慢塞属性”的过程。final字段还能享受不可变性的保护。这也是Spring官方推荐的写法。我在新项目里基本全部使用构造器注入，既利于测试，也逼着自己在设计时想清楚“这个类到底依赖什么”。

4. 从组件到能力：条件装配、配置绑定与扩展注解

4.1 条件装配：让容器里的组件按环境“活”起来

Spring Boot自动配置的神奇之处，很大程度上建立在条件注解之上。@Conditional系列注解解决的问题是：这个Bean到底该不该注册？要不要注册不是拍脑袋决定的，而是看当前的环境条件是否成立。

最常用的几个：

@ConditionalOnProperty是最容易理解的——某个配置项存不存在、值是不是符合预期，决定Bean是否注册：

@Component @ConditionalOnProperty(name = "app.cache.enabled", havingValue = "true") public class CacheService { // 只有当app.cache.enabled=true时才注册 }

@ConditionalOnClass和@ConditionalOnMissingClass判断classpath里有没有某个类。这个注解是Spring Boot自动配置的核心机制——比如classpath里有了HikariDataSource才会装配数据源，没有就跳过。再比如你自定义了一个配置类，希望“项目里没有这个类时才加载我的Bean”，就可以用@ConditionalOnMissingClass。

@ConditionalOnBean和@ConditionalOnMissingBean判断容器里有没有某个Bean。这个要小心用，因为Bean的注册顺序会影响判断结果。在自动配置类里使用@ConditionalOnMissingBean来允许用户覆盖默认Bean，是常见的标准做法。

这些条件注解组合起来，能让一套代码适配多环境。比如开发环境内存缓存、生产环境Redis缓存，同一个CacheManagerBean，用@ConditionalOnProperty切换，配置文件一改就生效。这种“声明式控制注册”的能力，是注解时代真正的红利。

4.2 从组件到配置属性：@ConfigurationProperties的强绑定

Spring Boot里有一类特殊的“组件”：配置属性类。它们不承载业务逻辑，只负责把application.yml里的配置项结构化地绑定到一个Java对象上。

@Component @ConfigurationProperties(prefix = "aliyun.oss") @Data public class OssProperties { private String endpoint; private String accessKeyId; private String accessKeySecret; private String bucketName; }

使用时直接注入这个类，就能以类型安全的方式读取配置。这比@Value("${aliyun.oss.endpoint}")逐个注入清爽得多。配置项一多，@Value写法代码立刻膨胀；而@ConfigurationProperties天然支持嵌套属性、列表、Map等复杂结构，还支持数据校验（配合@Validated）。

有一个细节值得注意：如果同时使用了@ConfigurationProperties和@Value绑定同一个配置路径，可能会出现不同绑定器对宽松绑定规则（如endpoint匹配end-point、accessKeyId匹配access-key-id）的理解差异。所以建议一个前缀的配置只走一种绑定方式，别混用。

4.3 组件扫描之外的扩展点：@Import、@ImportResource、@ComponentScan的精确控制

@Import是配置类里一个被低估的注解。它的作用是把一个普通的类注册为Bean，或者把一个配置类及其所有Bean引入当前容器。在组件扫描覆盖不到的包里，或者你只想按需引入某个模块时，@Import非常实用：

@Configuration @Import({RabbitMqConfig.class, ShardingConfig.class}) public class ModuleConfig { }

相比@ComponentScan("com.example.xxx")去扫一整个包，@Import精确到类，控制粒度更细，也不会误扫到不相干的Bean。

@ComponentScan配合excludeFilters和includeFilters可以实现对扫描范围的精细控制。比如：

@Configuration @ComponentScan( basePackages = "com.example", excludeFilters = @ComponentScan.Filter(type = FilterType.REGEX, pattern = "com\\.example\\.legacy\\..*") ) public class AppConfig { }

这个场景适合模块迁移期：老代码留在legacy包里，新代码正常扫描，两边互不干扰。还有一种常见用法是排除某个标注了@Deprecated的Bean，避免它进入容器。

5. 让组件产生行为：AOP注解与声明式事务

5.1 怎么用注解开启AOP并实现日志记录

AOP（面向切面编程）是Spring组件体系里最能体现“注解声明能力”的部分。它的核心思想是：在不修改业务代码的情况下，把通用逻辑（日志、鉴权、性能监控）横切进去。Spring AOP基于代理实现，入口就是@Aspect系列注解。

最经典的入门案例是日志记录。先定义一个切面：

@Aspect @Component public class OperationLogAspect { @Around("@annotation(log)") public Object recordLog(ProceedingJoinPoint pjp, OperationLog log) throws Throwable { String method = pjp.getSignature().getDeclaringTypeName() + "." + pjp.getSignature().getName(); long start = System.currentTimeMillis(); Object result; try { result = pjp.proceed(); } catch (Throwable e) { // saveErrorLog(method, pjp.getArgs(), e); throw e; } System.out.println("方法[" + method + "]执行耗时: " + (System.currentTimeMillis() - start) + "ms"); return result; } }

再定义注解：

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface OperationLog { String value() default ""; }

业务方法上只要加一行@OperationLog("创建订单")，日志逻辑就自动织入。这里有两个关键点：

第一，注解必须标注@Retention(RetentionPolicy.RUNTIME)。如果保留策略是SOURCE或CLASS，运行时反射拿不到注解，@Around("@annotation(log)")就匹配不到。这是很多初学者AOP死活不生效的原因之一。

第二，AOP调用必须通过代理对象完成。同类内部方法调用（this调用）不会经过Spring生成的代理对象，切面逻辑根本不会执行。比如类A的方法x调用方法y，y上加了@OperationLog，但y是通过this.y()调用的——代理失效，日志不打印。解决办法是把自己的代理对象注入进来，或者把y单独拆到另一个Bean里。

还要看看AOP的通知类型：@Before、@AfterReturning、@AfterThrowing、@After、@Around。@Around最强大，它控制了整个方法执行的全程，前置、后置、异常、耗时都可以在这里统一处理。其它通知类型各有专注，组合使用时要注意执行顺序。我的经验是，除非确实只需要一个极细的点，否则大部分场景直接用@Around就够了，它最不容易产生“顺序不符合预期”的困惑。

5.2 事务注解：@Transactional用得不对，数据就悄悄错了

@Transactional是声明式事务的入口，不加它代码也能跑，加了它数据才不容易乱。它的工作原理同样建立在Spring AOP之上——Spring会为标注了@Transactional的Bean生成代理对象，在方法调用前开启事务，方法正常返回后提交，抛出异常则回滚。

但“抛出异常就回滚”有一个非常容易踩的坑：默认只回滚RuntimeException和Error，检查型异常（Exception及其子类）默认不回滚。举例来说：

@Transactional public void createOrder(OrderDO order) { orderDao.insert(order); try { stockService.deduct(order.getProductId(), order.getCount()); } catch (Exception e) { throw new BusinessException("库存不足", e); } }

如果BusinessException是自定义的检查型异常，默认情况下事务不会回滚，订单已经写进去了，库存却没扣——对账的时候就成了黑盒问题。解决方式是显式指定回滚规则：

@Transactional(rollbackFor = Exception.class)

这是我在review代码时最常要求别人改的一行。凡是自己抛出来的业务异常都希望回滚的，就统一加上rollbackFor = Exception.class，简单粗暴不出错。

@Transactional还有几个名称叫“事务失效”的场景，我整理成了一张排查表：

这张表里的每一条我都实际遇到过。尤其是“同类内部调用”和“异常被吞”这两项，出现频率最高，而且排查起来都是“表面看不出问题，实际数据不一致”的隐蔽bug。

5.3 用注解组合“干净”的事务边界

在微服务或复杂业务里，事务边界设计比事务代码本身更重要。我的实践原则是三条：

事务注解只加在一个入口方法上，不要在多个内部方法上重复加。比如下单操作会调用扣库存、生成订单号、发消息，这些内部方法如果每个都标@Transactional，事务传播行为配置错误就会产生意外的“多次提交/回滚”问题。通常把事务加在业务入口方法上，内部方法只做一件事。

查询方法不需要加事务。除非要保证“读到的数据一定是某个时刻提交的”（比如用REQUIRES_NEW读历史快照），否则加了事务纯属浪费数据库连接，还拉长事务持有时间。

异步方法加事务要非常谨慎。@Async方法和@Transactional在同一个类组合时，实际上事务和异步都在代理层面处理，经常出现“事务还没提交，异步任务已经开始执行读取老数据”的情况。解决思路是先同步提交事务，再触发异步任务，或者让异步任务内部自己开新事务。

6. 手写一个最简单的Spring容器，理解组件注册的全流程

6.1 从零搭建：扫描、注册、注入，拢共不到200行

如果你觉得上面讲的都是“框架行为”，不妨动手写一个迷你版Spring容器。这个练习能帮你把组件扫描、Bean注册、依赖注入这几个概念真正串起来。手写Spring的核心就三步：扫描路径、反射实例化、按类型注入。

第一步，定义核心注解：

@Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) public @interface MyComponent { String value() default ""; } @Target(ElementType.FIELD) @Retention(RetentionPolicy.RUNTIME) public @interface MyAutowired { }

第二步，写容器类。用ClassPathBeanDefinitionScanner或者自己遍历classpath下的class文件，找到所有标了@MyComponent的类。这里为了演示，我直接用Class.forName配合全局扫描：

public class MiniApplicationContext { private final Map<String, Object> singletonMap = new ConcurrentHashMap<>(); public void scan(String basePackage) throws Exception { String path = basePackage.replace('.', '/'); ClassLoader classLoader = Thread.currentThread().getContextClassLoader(); var urls = classLoader.getResources(path); while (urls.hasMoreElements()) { var url = urls.nextElement(); File file = new File(url.toURI()); for (File classFile : file.listFiles(f -> f.getName().endsWith(".class"))) { String className = basePackage + "." + classFile.getName().replace(".class", ""); Class<?> clazz = Class.forName(className); if (clazz.isAnnotationPresent(MyComponent.class)) { String beanName = clazz.getAnnotation(MyComponent.class).value(); if (beanName.isEmpty()) { beanName = lowerFirst(clazz.getSimpleName()); } singletonMap.put(beanName, clazz.getDeclaredConstructor().newInstance()); } } } injectDependencies(); } private void injectDependencies() throws Exception { for (Object bean : singletonMap.values()) { for (Field field : bean.getClass().getDeclaredFields()) { if (field.isAnnotationPresent(MyAutowired.class)) { field.setAccessible(true); // 按类型匹配，简化处理：遍历已有Bean找类型一致的那个 Object dependency = singletonMap.values().stream() .filter(v -> field.getType().isInstance(v)) .findFirst() .orElseThrow(() -> new RuntimeException("找不到依赖: " + field.getName())); field.set(bean, dependency); } } } } private String lowerFirst(String name) { return Character.toLowerCase(name.charAt(0)) + name.substring(1); } }

第三步，写两个互相协作的类测试验证：

@MyComponent public class UserService { @MyAutowired private UserDao userDao; public void sayHello() { userDao.hello(); } } @MyComponent public class UserDao { public void hello() { System.out.println("UserDao say hello"); } } public class Main { public static void main(String[] args) throws Exception { MiniApplicationContext ctx = new MiniApplicationContext(); ctx.scan("com.demo"); UserService userService = (UserService) ctx.singletonMap.get("userService"); userService.sayHello(); } }

就这么简单，几十行代码实现了一个“能跑”的容器。当然真实Spring的复杂度远不止这些——它有复杂的Bean生命周期回调、作用域管理、循环依赖三级缓存、代理生成、条件装配……但核心骨架就是这些。你把这段代码跑通了再去回看Spring源码，很多之前看不懂的类名（比如BeanPostProcessor、SingletonBeanRegistry）会立刻变得亲切。

6.2 手写Spring给我带来的三个认知升级

第一个认知：为什么Spring喜欢“约定优于配置”。因为容器扫描的粒度是“包路径 + 注解”，约定意味着不用写冗长的配置文件，扫到就管，扫不到就不管。项目里组件不生效时，第一反应该是“它有没有在扫描路径里”，而不是去翻配置。

第二个认知：为什么Spring推荐构造器注入而不是字段注入。从我的迷你容器实现就能看出来，字段注入需要反射暴力改写实例属性，对象在构造时并不满足依赖完整性；构造器注入则强制依赖在new的时候就必须给齐，对象状态天然完整。反射带来的性能开销和安全风险，相比之下字段注入的“方便”并不划算。

第三个认知：理解Bean的生命周期对排查问题有巨大帮助。实例化、属性填充、初始化（@PostConstruct）、使用、销毁（@PreDestroy），这个顺序写代码时一定要心里有数。比如@PostConstruct里调用了注入的属性，属性还没填充就会抛空指针——排查的时候，先定位当前是在“属性填充”前还是后，思路一下就通了。

7. 高频实战问题与排查速查表

7.1 最常见的五个报错场景与解法

组件相关的问题，翻来覆去就那么几类。我把这几年见到的高频场景整理成一张速查表，放在这里供大家定位思路：

另外要留意“注入的Bean是null却没有报错”这种问题，通常不是容器报错了，而是代码根本没走Spring代理——比如直接new了一个Service，它的@Autowired字段当然全是null。这也是为什么我一直坚持“业务类不允许手动new，必须从容器里获取”。

7.2 关于注解失效与类代理的几个冷门提醒

Spring在运行时对@Configuration类、@Transactional方法、AOP切面都会生成代理对象。代理有两种：JDK动态代理（基于接口）和CGLIB代理（基于继承）。默认情况下Spring Boot 2.x+强制使用CGLIB，好处是代理不要求目标类实现接口。但CGLIB有个天生的限制：final类无法被继承、final方法无法被重写，因此标了@Transactional或参与AOP的类和方法，不要加final修饰符。

还有一个词容易被忽略：注解的@Inherited元注解。如果你自定义了一个注解，希望子类也能“继承”到这个注解，需要标@Inherited。否则子类继承父类时，注解不跟着走，AOP或切面匹配就会失效。这个坑在我做基类控制器、基类Service时踩过。

排查AOP不生效还有一个经典确认手段：启动日志里看有没有Creating shared instance of singleton bean后面跟代理信息，或者直接打印Bean的class名——如果显示$$EnhancerBySpringCGLIB$$字符串，说明代理生效了；如果显示的是原生类的全限定名，说明你的调用路径根本没走代理。

8. 从Spring到Spring Boot：组件注解在自动配置里的角色

到了Spring Boot时代，组件和注解的玩法又进阶了一步。@SpringBootApplication是一个组合注解，它由@SpringBootConfiguration、@EnableAutoConfiguration和@ComponentScan三个核心注解组成。这三个注解三个职责：标记配置入口、启用自动配置、指定组件扫描路径。

自动配置的底层机制，是@EnableAutoConfiguration通过META-INF/spring.factories或META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件加载了所有AutoConfiguration类。这些类几乎都是@Configuration+@ConditionalOnClass/@ConditionalOnMissingBean的组合体。你引入spring-boot-starter-web，classpath里有了DispatcherServlet，自动配置类就生效，自动装配一套Web MVC环境；你引入MyBatis的starter，数据源配置类才被激活。

理解这一层后有两件事会有质的提升：

第一，遇到“我引入了依赖为什么没生效”的问题，会本能地去看条件是否满足——classpath里有对应类吗？配置项满足havingValue吗？容器里有没有已有的同类型Bean？

第二，写自定义starter时思路清晰了。一个标准的starter由两部分组成：自动配置类（@AutoConfiguration+ 条件注解组合）+ 配置属性类（@ConfigurationProperties）。你只需要规定好“使用者引入依赖后，默认提供什么Bean，允许怎么覆盖”，一年下来你会发现团队项目的集成成本大幅下降。

更直白的例子是spring.factories文件里最常见的EnableAutoConfiguration配置项。当你有多个内外部配置类需要精确控制加载顺序时，还可以在配置类上使用@AutoConfigureOrder或@AutoConfigureAfter微调顺序，避免某些Bean在依赖条件未满足时急于注册。

随着你对“自动配置”的认识越深，你越会发现Spring Boot不是在“隐藏细节”，而是在“把常见的容器组合模式固化成约定”。组件和注解的关系从来没有变——注解声明意图，容器负责实现。Spring Boot只是把这个过程的“选择条件”变得更智能。

有一个我自己特别欣赏的实践：把“组件是否生效”的条件引到配置中心里。例如使用@ConditionalOnProperty配合配置中心的动态开关，可以做到灰度发布某些功能组件——不重启服务，只刷新配置，某个功能组件就切换实施路径。但这要求条件里不依赖@ConfigurationProperties的静态绑定，否则动态刷新会打折扣。

回到更基础的开发层面，我见过很多团队在纠结“为什么我的Spring Boot项目扫描不到自建包里的组件”。问题的根因往往是：主启动类所在的包和自建包的层级关系不对。@SpringBootApplication默认只扫描启动类所在包及其子包。如果你的启动类写在com.example.admin，而业务组件在com.example.business，那扫描范围就不覆盖business、下面的@Component、@Service都是废的。解决方法是显式加上scanBasePackages = {"com.example"}，同时检查启动类的包层级。

8.1 自定义一个简单的starter组件

为了把自动配置讲得更具体，我分享一个实际项目里写过的“通用敏感词过滤starter”的骨架。它麻雀虽小，五脏俱全：

第一步，定义配置属性类：

@ConfigurationProperties(prefix = "app.sensitive") public class SensitiveProperties { private boolean enabled = true; private List<String> words = new ArrayList<>(); // getters/setters 省略 }

第二步，定义自动配置类：

@AutoConfiguration @ConditionalOnProperty(prefix = "app.sensitive", name = "enabled", havingValue = "true", matchIfMissing = true) @EnableConfigurationProperties(SensitiveProperties.class) public class SensitiveAutoConfiguration { @Bean @ConditionalOnMissingBean public SensitiveFilter sensitiveFilter(SensitiveProperties props) { return new SensitiveFilter(props.getWords()); } }

第三步，在META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports里写一行：

com.example.starter.sensitive.SensitiveAutoConfiguration

这样业务项目引入这个starter依赖后，只要配置了app.sensitive.words，容器里自动就有了SensitiveFilter；如果用户自己定义了一个SensitiveFilter，自动配置会通过@ConditionalOnMissingBean自动退让。这套机制保证了“约定可用，自定义优先”，不做任何侵入。

我在多次写starter的过程中体会到，组件注解的价值不只是“少写一遍Bean定义的XML”，更是“让模块的接入能力变成一种标准化协议”。任何人拿到你的starter，不需要读你的源码，只需要关注配置项、组件行为和覆盖方式，集成成本就极低。

8.2 基于Spring + Vue的典型联调项目中的组件使用复盘

这里顺带聊一个网上很热的项目类型：“基于Spring + Vue的仿天猫购物系统”。这类项目里面几乎用尽了所有我们前面聊到的注解能力：@RestController暴露接口、@Service承载业务、@Mapper或@Repository访问数据库、@Transactional绘制购物车/下单事务、@ConfigurationProperties管理OSS/微信支付配置、@Aspect做日志切面。前端Vue组件化通信（父传子、子传父、事件总线）和后端Spring组件化（Bean注入、AOP切面）完全是两种语境下的“组件”概念，但背后的思想一致：划分边界、定义接口、组合复用。

这种全栈项目里最容易出的后端问题，反而是事务和数据一致性。我复盘过一个经典场景：下单时扣库存和写订单如果各用各的@Transactional方法，中间一旦有异常，库存扣了订单没生成，用户看不出来，压测时对不上账。最佳实践是把整个下单一套动作编进同一个事务入口方法里，内部依赖各自保持纯粹。这一点系统设计好了，你的“购物系统”才能谈得上可靠。

9. 一套顺手的Spring组件自检清单

文章最后，给你一份我在新项目启动或者代码review时，大脑里会自动过一遍的组件相关检查清单。好用，且每一次都能揪出几个问题。

1. 所有业务类有没有被Spring管理？Controller、Service、DAO层是否都标了正确的组件注解？
2. 包扫描范围对不对？主启动类和自建包是否在同一父包下？
3. 依赖注入方式是否统一？新写代码是否优先构造器注入？
4. 同类型多个Bean时，@Primary和@Qualifier的选择是否有明确依据？
5. 所有@Transactional方法是否显式指定了rollbackFor？
6. 有没有同类内部调用导致事务/AOP失效的点？互相调用的方法是否都在代理入口？
7. @PostConstruct里是否用了尚未填充的属性？
8. 配置属性是否统一通过@ConfigurationProperties管理，而不是散落的@Value？
9. 自定义注解的保留策略是不是RUNTIME？@Inherited是否需要？
10. 自动配置类里是否用了@ConditionalOnMissingBean给用户留覆盖口子？

这10条我几乎每一条都付出过生产事故的学费。把这些变成肌肉记忆之后，Spring的组件与注解对你来说就不再是一堆散装特性，而是一套清晰的、可预测的对象管理哲学。框架本身会迭代，但这个思维模式会用很多年。