先直接说结论：Spring Boot 自动装配和 Starter 机制，是理解整个框架的钥匙，也是让 Spring Boot 从“配置繁琐”走向“开箱即用”的核心设计。这篇文章我会从一个真实项目里“去掉模板代码”的需求讲起，拆解自动装配的原理链条，再用一个自定义 Starter 的完整开发过程，把这一整套机制跑通。适合已经写过 Spring Boot 接口但对启动原理半懂不懂的人，想自己封装公共组件给团队用的开发者，以及准备面试把“自动装配”讲清楚的人。

我先抛一个尽量真实的场景。你自己的团队里有好几个微服务，每个服务都得引入 Redis、MQ、短信发送这一套东西。Redis 的配置类你可能复制了三遍，短信 SDK 的初始化代码每个项目都一样，甚至因为版本不统一，出过几次低级问题。你想把这些公共能力抽成一个组件，让同事在 pom 里加一行依赖，配置文件里填几个自定义项，组件就自动生效，代码里能直接注入封装好的客户端。这个诉求，就是 Spring Boot Starter 的典型使用场景。要实现它，你必须先搞懂一件事：Spring Boot 在启动的瞬间，是怎么把那些乱七八糟的自动配置类加载进来的。

1. 自动装配原理：一个注解背后的加载链路

1.1 起点是组合注解，不是单个注解

很多人第一眼看到@SpringBootApplication以为它是一个注解，其实它是一个组合注解。源码里长这样：

@Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented @Inherited @SpringBootConfiguration @EnableAutoConfiguration @ComponentScan(excludeFilters = { @ComponentScan.Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class), @ComponentScan.Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) }) public @interface SpringBootApplication { }

这里面@SpringBootConfiguration本质就是个加了特殊标记的@Configuration，@ComponentScan负责扫描当前包及子包的 Bean，真正干“自动装配”脏活的是@EnableAutoConfiguration。

我用一句人话来总结三者关系：@ComponentScan管你项目自己写的 Bean，@EnableAutoConfiguration管框架和第三方库预置的配置类，@SpringBootConfiguration只是告诉 Spring 这个类是配置入口。

1.2 自动装配的核心入口：AutoConfigurationImportSelector

@EnableAutoConfiguration注解本身没什么魔法，它通过@Import(AutoConfigurationImportSelector.class)引入了臭名昭著又至关重要的导入器。

这个AutoConfigurationImportSelector才是自动装配的“总指挥”。Spring Boot 启动时，调用它的selectImports(AnnotationMetadata)方法，返回一组类的全限定名数组，Spring 容器再把这批类当普通@Configuration配置类一样处理。

那段经典源码逻辑大致是：

// 核心链路： 1. getCandidateConfigurations() 2. 读取 META-INF/spring/.../AutoConfiguration.imports 文件 3. 结合 exclusions 排除项、过滤条件、Order 排序 4. 去重并返回配置类名数组

在 Spring Boot 2.7 之前，配置类清单写在META-INF/spring.factories里，key 是org.springframework.boot.autoconfigure.EnableAutoConfiguration。从 2.7 开始，官方用META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports替代，好处是更清晰、能避免 IDE 提示混乱，也让合入自动配置类列表更可控。到了 Spring Boot 3.x，spring.factories方式默认不再支持加载自动配置类，必须用AutoConfiguration.imports。

这段加载是第一次过滤，确定了“哪些类有资格进候选池”。

1.3 为什么加载了候选类，却没有生效？

真正体现自动装配“智能”的，是第二次过滤。

候选池里可能有上百个自动配置类，比如RedisAutoConfiguration、DataSourceAutoConfiguration、MongoAutoConfiguration。你项目里根本没有引入 Redis 的客户端依赖，如果RedisAutoConfiguration强行生效，就会因为缺少RedisConnectionFactory直接报错。

Spring Boot 解开这个死结的方案是@Conditional条件注解体系。几乎每个自动配置类头上都挂着好几个条件注解：

@AutoConfiguration( after = { JtaAutoConfiguration.class, HibernateJpaAutoConfiguration.class } ) @ConditionalOnClass({ DataSource.class, EmbeddedDatabaseType.class }) @ConditionalOnMissingBean(type = "io.r2dbc.spi.ConnectionFactory") @EnableConfigurationProperties(DataSourceProperties.class) public class DataSourceAutoConfiguration { ... }

这组注解的含义是：只有当类路径中存在DataSource和EmbeddedDatabaseType时，这个配置类才进入候选；当容器里已经有人自定义了DataSource时，装配置会自动“退位让贤”。这一套机制保证了你引入依赖和排除依赖时，框架的配置方案都能自适配，这也是我前面说“最小侵入”的落地基础。

1.4 从候选到生效，流程串起来看

我把整个自动装配链路按执行顺序理出一条线：

1. 启动应用，Spring 容器刷新开始。
2. 处理@EnableAutoConfiguration，触发AutoConfigurationImportSelector。
3. 读取AutoConfiguration.imports文件获取全量候选类。
4. 根据exclude属性、spring.autoconfigure.exclude配置项做第一轮剔除。
5. 对剩余候选类，逐一解析@ConditionalOnClass、@ConditionalOnMissingBean等条件，逐条验证是否通过。
6. 通过条件的自动配置类注册为容器内的配置类，继续创建内部定义的 Bean。
7. 配置属性类通过@EnableConfigurationProperties绑定到application.yml中前缀对应的配置项。

这条链路里有个容易忽略的细节：条件判断的顺序。Spring Boot 对自动配置类的处理不是一遍扫描就全部命中，而是分轮进行，先用@ConditionalOnClass快速过滤，再进行@ConditionalOnMissingBean这类延迟到 Bean 定义注册阶段的判断。这也是为什么有些人手动调整 Bean 之间的依赖顺序时，会出现“明明排除了却还是被创建”的情况，本质是条件评定的时机不同。

2. 条件配置与属性绑定：自动装配的决策引擎

2.1 @Conditional 系列注解到底怎么工作

我已经见过太多人把@ConditionalOnProperty和@ConditionalOnExpression搞混。这里做个最直白的区分。

@ConditionalOnClass看类路径里有没有指定的类。这是 Starter“按需加载”的第一道闸门。比如你的自定义 Redis Starter 里可以判断StringRedisTemplate是否存在，如果不存在就说明项目里没引入核心依赖，自动配置就不启动。

@ConditionalOnMissingBean看容器里是否已经存在指定类型的 Bean。这条规则保证了用户自定义优先于框架默认。这也是为啥你在项目里写一个自己的ObjectMapper，Jackson 的自动配置就会失效。Spring Boot 把这种优先级设计称作“自定义覆盖”。

@ConditionalOnProperty看配置文件里的键值。比如：

@ConditionalOnProperty( prefix = "my.redis", name = "enabled", havingValue = "true", matchIfMissing = true ) public class MyRedisAutoConfiguration { }

这段代码表达的是：配置项my.redis.enabled=true时生效，缺省配置时也生效（matchIfMissing = true）。实际操作里我强烈建议给自定义 Starter 的所有开关类配置加上matchIfMissing = true，这样用户引依赖后零配置就能用，想关再显式配置关闭。否则默认不生效，用户会以为组件坏了，体验极差。

还有一类很实用但常被忽略的：@ConditionalOnBean。它判断的是容器里某个 Bean 是否已注册。注意这里的顺序陷阱：如果你在自定义配置类里用它判断一个由另一个自动配置类创建的 Bean，有可能会因为对方还未注册而误判失败。Spring Boot 提供@AutoConfigureAfter来保证先后顺序，但@ConditionalOnBean对自动配置类来说依然有风险，很多时候更稳妥的做法是用@ConditionalOnClass或直接注入ObjectProvider做补救。

2.2 配置属性绑定：从 application.yml 到强类型类

自动装配类负责创建 Bean，但配置项怎么赋进去？靠的是@ConfigurationProperties和@EnableConfigurationProperties的组合。

开发自定义 Starter 时，通常会定义一个属性类：

@Data @ConfigurationProperties(prefix = "my.sms") public class SmsProperties { private String accessKey; private String secretKey; private String signName; private Integer connectTimeout = 3; }

然后在自动配置类上加上：

@EnableConfigurationProperties(SmsProperties.class)

这里有个我踩过坑的技术细节：@ConfigurationProperties单独加在类上作为@Component使用，和配合@EnableConfigurationProperties使用，破解时机不完全一样。后者是专门给自动配置类准备的，更可控，不会因为组件扫描路径不一致导致属性类没被 Spring 管理，推荐优先用后者。

属性值在绑定前的类型转换也值得提一句。application.yml里的字符串、微秒数、时长格式，Spring Boot 的Binder负责把它们转换成目标类型，Duration、DataSize这类特殊类型都有默认转换器。团队里如果有人把connectTimeout写成字符串"3000ms"，只要类型是Duration它也能正确解析，但对Integer类型会直接报转换异常。所以属性类里的类型不要随意设计，尽量考虑到用户配置时的真实习惯。

2.3 自动配置类的优先级排序：after/before 别再乱用

设计自动配置类时，@AutoConfigureBefore和@AutoConfigureAfter提供的排序语义不能乱用。

我见过有些同事写 Starter，为了让自己配置优先，直接在配置类上写@AutoConfigureBefore(SomeAutoConfiguration.class)，这其实是对别人的自动配置生命周期形成了强绑定。一旦版本升级，那个类改名或拆了，你的 Starter 编译和启动都会出问题。

更稳妥的排期思路是：

• 用@ConditionalOnClass判断是否存在“对方的产物类”，替代对配置类的直接依赖。
• 需要注入对方配置创建的 Bean 时，用ObjectProvider<T>或@Autowired(required = false)延迟获取，而不是强制排序。
• 确实需要强先后时，@AutoConfigureAfter填对方自动配置类的类名，不要填业务 Bean 类名。

这套规则，我在换版本兼容旧 Starter 时验证过很多次，稳定性远远好于靠启动顺序猜。

3. 手写一个可落地的自定义 Starter 实战

3.1 选个有代表性的业务：短信发送组件

讲原理讲得再多，不如亲手写一个。下面这个 Starter 不抄 Spring 官方，而是模拟一个真实的云短信 SDK 封装。

需求很简单：项目引入这个 Starter 后，可以零配置发送短信。默认使用 Mock 发送，方便本地联调；显式配置云厂商的 accessKey 后切换到真实通道。所有参数延迟到运行期判断，避免因为配置缺失导致整个应用启动失败。

先建一个 Maven 模块，命名为simple-sms-spring-boot-starter，内部结构：

simple-sms-spring-boot-starter/ ├── pom.xml ├── src/main/java/ │ ├── com/example/smssupport/ │ │ ├── SmsProperties.java │ │ ├── SmsClient.java │ │ ├── MockSmsClient.java │ │ ├── CloudSmsClient.java │ │ └── SmsAutoConfiguration.java └── src/main/resources/ └── META-INF/spring/ └── org.springframework.boot.autoconfigure.AutoConfiguration.imports

注意我没引入 spring-boot-starter-web，因为这个组件是纯底层能力，不关心你上层是 Web MVC 还是 WebFlux。只引入一个spring-boot-autoconfigure就够了，编译期依赖，运行时由使用方提供。

pom.xml大致如下：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.2.4</version> <relativePath/> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-autoconfigure</artifactId> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies>

Lombok 标记optional=true很关键，否则依赖会传递到所有使用方项目，这违背了 Starter 的“只暴露最小依赖”原则。

3.2 属性类与客户端接口设计

属性类和前面SmsProperties类似，但这回加一个开关字段：

@ConfigurationProperties(prefix = "simple.sms") public class SmsProperties { private boolean enabled = true; private String accessKey; private String secretKey; private String signName; private Integer connectTimeout = 5; }

客户端接口保持简单，方便 Mock 和真实实现无缝替换：

public interface SmsClient { String send(String mobile, String content); }

Mock 实现直接落盘日志，本地联调不用花短信费：

public class MockSmsClient implements SmsClient { private final SmsProperties properties; @Override public String send(String mobile, String content) { // 这里可以打成日志文件，方便联调时检查内容 return "mock:" + mobile + ":" + content; } }

云厂商实现核心是根据accessKey和secretKey构造签名请求，细节不展开，重点是条件判断的逻辑怎么写。

这里有一个我坚持的习惯：所有“某功能开关”直接用@ConditionalOnProperty的havingValue = "true"判断，但承载底层能力的客户端切换不要放在属性判断上，而应该在客户端内部实现。原因很简单，真实项目里短信通道切换往往是运行时行为，放配置文件里的启停开关反而会造成误操作。

3.3 自动配置类与条件控制：最核心的 50 行代码

自动配置类我建议这样组织：

@AutoConfiguration @ConditionalOnProperty(prefix = "simple.sms", name = "enabled", havingValue = "true", matchIfMissing = true) @EnableConfigurationProperties(SmsProperties.class) public class SmsAutoConfiguration { @Bean @ConditionalOnMissingBean(SmsClient.class) @ConditionalOnProperty(prefix = "simple.sms", name = "mock", havingValue = "true", matchIfMissing = true) public SmsClient mockSmsClient(SmsProperties properties) { return new MockSmsClient(properties); } @Bean @ConditionalOnMissingBean(SmsClient.class) @ConditionalOnProperty(prefix = "simple.sms", name = "mock", havingValue = "false") public SmsClient cloudSmsClient(SmsProperties properties) { return new CloudSmsClient(properties); } }

这里有几个容易忽略的细节：

第一，@AutoConfiguration注解。Spring Boot 3.x 官方要求自动配置类必须用它替代@Configuration，这确保配置类只在自动装配阶段被导入，而不会被组件扫描误捞。2.7 版本开始同时支持两个注解，但加到AutoConfiguration.imports清单里的类统一推荐用@AutoConfiguration(proxyBeanMethods = false)。

第二，两个客户端 Bean 都加了@ConditionalOnMissingBean(SmsClient.class)。这行的意思是，用户如果在自己的配置类里手动定义了一个SmsClient实现，自动配置创建的 Mock 或 Cloud 客户端都不会重复创建，避免双 Bean 冲突。它提供的这条口子，是团队里有人想深度定制客户端时的逃生通道。

第三，mock属性我没写进SmsProperties里。严格说它应该写在里面，但我故意没写，用来展示@ConditionalOnProperty可以直接匹配environment中任意属性。实际开发里我更建议把 mock 字段放进属性类，便于 IDE 提示和自动补全，这里只是顺带展示配置键的灵活性。

3.4 SPi 清单文件注册与版本差异

自动配置类写完后，还需要把类名写进清单文件。

Spring Boot 2.7 之后的新路径：

src/main/resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

文件内容非常简单，每行一个全限定类名：

com.example.smssupport.SmsAutoConfiguration

Spring Boot 2.0 到 2.6 的旧路径是：

src/main/resources/META-INF/spring.factories

内容格式为：

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ com.example.smssupport.SmsAutoConfiguration

如果你要做一个兼容 2.x 和 3.x 的公共组件，可以同时保留两个文件，两边都会被加载。但我个人建议新组件只维护AutoConfiguration.imports，因为 2.7 之后 Spring Boot 官方对spring.factories里的自动配置项打印了废弃警告，而 3.x 已经完全移除。

这里有个细节：自动配置类的类名写到清单里之后，类上必须能通过@AutoConfiguration标记，否则启动时会报“not a valid auto-configuration class”。我初写 Starter 时在这踩过坑，单独把配置类写进了imports但类上还是@Configuration，启动报错时排查了半天。

3.5 完整测试：不启动 Web 容器，验证装配效果

在测试阶段，我不喜欢把整个 Spring Boot 应用拉起来再验证，那样太重。用ApplicationContextRunner配合断言就能精准测试自动配置到底创建了哪些 Bean。

测试代码如下：

class SmsAutoConfigurationTest { private final ApplicationContextRunner contextRunner = new ApplicationContextRunner() .withConfiguration(AutoConfigurations.of(SmsAutoConfiguration.class)); @Test void mockSmsClientCreatedWhenEnabled() { contextRunner .withPropertyValues("simple.sms.enabled=true") .run(context -> { assertThat(context).hasSingleBean(SmsClient.class); assertThat(context.getBean(SmsClient.class)) .isInstanceOf(MockSmsClient.class); }); } @Test void cloudSmsClientCreatedWhenMockDisabled() { contextRunner .withPropertyValues("simple.sms.enabled=true", "simple.sms.mock=false") .run(context -> { assertThat(context).hasSingleBean(SmsClient.class); assertThat(context.getBean(SmsClient.class)) .isInstanceOf(CloudSmsClient.class); }); } }

ApplicationContextRunner的好处是每次独立创建容器、独立加载配置，不会像集成测试那样互相污染。测试里甚至可以验证排除配置类后的行为：

contextRunner .withBean(SmsClient.class, () -> new MockSmsClient(new SmsProperties())) .run(context -> { assertThat(context).hasSingleBean(SmsClient.class); });

这套测试方法是官方文档里没怎么展开讲，但我实测下来最有价值的验证途径。写完 Starter 后我会先跑通这层测试，再丢进真实项目里做烟测。

4. 实战中遇到的自动化装配问题：排查方法与避坑清单

4.1 看一眼自动配置到底有没有生效

早期排查自动装配问题全靠断点和日志，现在官方给了个神仙工具：debug=true。

在application.yml里加一行：

debug: true

启动日志里就会出现“自动配置报告”，结构类似：

Positive matches: ----------------- SmsAutoConfiguration matched: - @ConditionalOnProperty (simple.sms.enabled) matched Negative matches: ----------------- RabbitAutoConfiguration matched: - @ConditionalOnClass did not find required class 'org.springframework.amqp.rabbit.core.RabbitTemplate'

Positive matches 表示“哪些条件命中、为什么被加载”，Negative matches 表示“哪些条件不满足、为什么没加载”。排查消息队列、缓存组件没生效的问题，我每次都先看这两段日志，比无头绪地加断点快得多。

如果想在测试环境动态查看，还可以用spring-boot-autoconfigure-report相关的日志配置，把匹配结果输出到日志文件。不过对于日常开发，debug=true够用了，排完问题记得关掉，这玩意儿生产环境开着会影响日志噪声。

4.2 常见装配失效场景速查表

我整理了这两年帮团队排查 Starter 问题时的高频原因，直接做成表：

这里重点解释一下第四个冲突情况。自动配置类创建了SmsClient，用户自己又在@Configuration里定义了一个同名 Bean。如果自动配置类没写@ConditionalOnMissingBean，两个 Bean 类型相同，注入的地方会直接报NoUniqueBeanDefinitionException。若自动配置类写了，又会出现一种微妙场景：用户定义的 Bean 在自动配置之前被注册时，自动配置创建失败；但如果用户 Bean 注册顺序靠后，自动配置还是会创建成功。这类问题靠条件注解依然躲不开顺序问题，最彻底的做法是组件内不要暴露太多同类型 Bean，保持单一职责。

4.3 与版本升级相关的坑：Spring Boot 2.3、2.6、3.0

标题里提到了 2.3.x、2.6.x 这些具体版本，我在维护老项目时确实踩过版本差异的坑。

Spring Boot 2.3 开始，官方在spring-boot-starter-parent中引入了spring-boot-buildpack相关变化，同时对spring.factories的加载机制做了内部调整，但当时用户侧感知不强。真正影响自动装配开发的是 2.6 到 2.7 的变化，最典型的是spring.mvc.pathmatch.matching-strategy默认值从ant_path_matcher改成了path_pattern_parser，很多老项目升级后出现 Swagger 或自研路径匹配失效，其实是配置项语义变化，不是自动装配本身出问题。

到了 Spring Boot 3.x，Jakarta EE 包名迁移、AutoConfiguration.imports强制使用，这两个变化对 Starter 作者是必须适配的。随便举个例子，2.6 时代的 Starter 里如果写了javax.annotation.PostConstruct，到 3.x 必须换成jakarta.annotation.PostConstruct，否则编译都过不了。

我给团队维护一个内部统一脚手架时，现在采用双保险方案：imports文件同时兼容 2.7+ 和 3.x，核心代码里不使用javax.*，属性绑定用最基础的@ConfigurationProperties，不碰新特性。这样升级成本降到最低。

4.4 自动配置之外的监控与外部接口设计

热搜词里还有几个有意思的话题，我顺带聊一下自己对这些场景的落地看法。

第一是 Spring Boot 监控。用spring-boot-starter-actuator可以快速导出健康检查、指标信息，配合spring-boot-admin做一个简单的监控看板。这里有个容易踩坑的点：actuator 暴露端点默认只开放health，自己加management.endpoints.web.exposure.include=*时要评估生产环境信息泄露风险。我在生产上一般只开health, info, metrics, logfile，尽量克制。

第二是对外接口放哪里。很多人纠结给第三方提供的 HTTP 接口应该放在单独服务还是放业务应用里。我的经验是：单独拆服务只有一个理由，就是接口协议的演进频率和调用方数量都很高，强烈需要隔离。否则放业务应用里更合适，省掉一套部署链路。决定放业务应用时，把接口逻辑单独分模块、单独建 Controller 包，也别和内部 API 混在一个类里，能把耦合压到最低。

第三是 Spring Boot 3 和 FastAPI 的对比。我在微服务里同时维护过两种技术栈，核心体会是：如果接口背后有大量复杂业务领域逻辑和成熟的 Java 生态库，Spring Boot 3 是首选；如果只是快速出 API、把 Python 的算法模型包一层 HTTP，FastAPI 开发快非常多。这两者不是竞争替代关系，按团队擅长和业务场景选就好，硬比较没有意义。

5. 自定义 Starter 的设计哲学与发布建议

5.1 命名规则别乱来，这涉及加载优先级

Spring Boot 官方 Starter 的命名格式是spring-boot-starter-xxx。自定义 Starter 官方建议用xxx-spring-boot-starter，目的是不要让第三方项目冒充官方 Starter，命名前缀能区分来源。你自己写的内部组件也应遵循这个规矩，否则团队里两个同名 Starter 引入时，排查成本会上升一个等级。

还有一个小细节：如果你命名的spring-boot-starter-xxx，Spring Boot 构建过程中可能会被 Maven 的依赖管理规则干扰，比如被 parent 里的 dependencyManagement 管理，所以这个顺序问题用起来会发现很多奇怪现象，统一改成xxx-spring-boot-starter完全绕开。

5.2 条件注解数量要克制，别写“全家桶”

我见过把@ConditionalOnClass、@ConditionalOnProperty、@Bean改造成自定义条件注解的极致封装，看起来高大上，维护起来崩溃。条件越多，用户排错越难；尤其项目里出现“在某环境不生效”的问题时，调用链一长，普通开发基本无从下手。

我自己的权衡标准是：自动配置类的条件注解数量控制在三到四个以内，其中必须保留一个@ConditionalOnClass（避免类缺失报错）和一个@ConditionalOnMissingBean（保证可覆盖）。如果超过这个数量，我会重新审视组件边界，看是不是设计过度了。

另外很多团队用自定义注解、SPI 扩展点去增强 Starter，我认为这些机制是双刃剑。对外发布的基础组件可以适度引入，对内使用的业务组件尽量别玩花活。业务变化快，研究人员离职后，花活代码就是最大的技术债。

5.3 内部发布与外部发布的不同方式

内部团队使用，可以通过公司私服的 Maven 仓库发布。我用过 Nexus 和 Artifactory，流程大同小异：deploy 到指定仓库，客户端配好私服地址，引坐标直接用。关键点：发布前把SNAPSHOT和RELEASE仓库分清楚，依赖引用规范要写进 README，还要给每个版本打 tag。

外部开源发布则需要走 Maven Central。整个流程比内部发布麻烦不少，涉及 GPG 签名、pom.xml配置developers信息、LICENSE文件等。如果只是想要开源精神而没强动力上 Central，可以先只开源到 GitHub 或 Gitee，配合JitPack让用户引 GitHub 坐标，成本低很多。

发布之前，有一步我强烈建议做：跑一遍 IDE 里 Maven 的dependency:analyze检查依赖；顺便用mvn install到本地仓库，在另一个干净项目里引依赖做一次真实启动验证。这两个检查做下来，能挡掉绝大多数“本地好好的，一发布就缺依赖”的尴尬。

6. 最后的个人经验小结

自动装配这套机制，我从最初只会用注解，到后来追着源码一行行读，最大的变化是：写任何自定义能力时，先思考“什么条件下生效、什么条件下可覆盖”，而不是一上来就写一堆@Bean。解决框架问题也一样，带着条件装配的视角去定位，启动日志里那份自动配置报告，会直接告诉你猜得对还是错。

最近我给团队定了个小规矩：所有新增组件必须带一份不低于二十行的自动装配自测用例，必须包含条件排除场景的测试。这规矩强制执行后，那些组件升级时潜在的不兼容影响，基本都在测试阶段暴露了，几乎没有再发生过“发布后生产环境组件失效”的事故。

希望这篇文章能把自动装配和 Starter 开发的整套逻辑讲透。动手的小建议只有一个：看完随手挑一个你自己常用的 SDK 封装成 Starter，从写属性类开始，一步一步把自动配置类落到本地测试里。跑通的瞬间，你对 Spring Boot 的理解会上一个台阶。