直接封装通用业务组件为自定义 starter，核心是把「可复用的逻辑」变成「引入即用的黑盒」，通过规范命名、模块拆分、条件化自动装配及配置驱动实现开箱即用。
直接封装通用业务组件为自定义 Starter，核心是把「可复用的逻辑」变成「引入即用的黑盒」。不需要每个项目都写配置、注册 Bean、处理条件加载——这些全由 Starter 内部完成。
明确组件边界与职责
先想清楚要封装的是什么：不是所有代码都适合放进 Starter。适合的典型场景包括：
- 内部短信/邮件服务（如 custom-sms-spring-boot-starter）
- 统一日志埋点或操作审计能力
- 通用 ID 生成器、分布式锁客户端、缓存工具封装
- 对接某套内部中间件（如配置中心 SDK、任务调度适配器）
关键原则：该组件应与具体 Web 层、数据层解耦，不强依赖 spring-boot-starter-web 或 spring-boot-starter-data-jpa 等高层 starter。
严格遵循命名与模块拆分规范
Starter 能被 Spring Boot 自动识别，前提是名字和结构合规：
- artifactId 必须以 -spring-boot-starter 结尾，例如
company-notify-spring-boot-starter - 推荐拆成两个模块：xxx-spring-boot-autoconfigure（含配置类、属性类、业务实现）和 xxx-spring-boot-starter（仅 pom，只声明对 autoconfigure 模块的依赖）
- autoconfigure 模块只引入
spring-boot-autoconfigure和必要底层依赖（如lettuce-core），绝不能引入spring-boot-starter-web等高阶 starter，否则会污染下游项目依赖树
编写可配置、可开关的自动装配逻辑
自动配置不是无脑注入，而是按需生效：
- 定义
@ConfigurationProperties类（如NotifyProperties），绑定notify.enabled=true、notify.provider=aliyun等配置 - 自动配置类上加
@ConditionalOnClass(NotifyService.class)，确保类存在才尝试装配；再叠加@ConditionalOnProperty(name = "notify.enabled", havingValue = "true")控制开关 - Bean 方法内使用
@ConditionalOnMissingBean，避免与用户自定义的同类型 Bean 冲突 - 多个实现（如阿里云短信、腾讯云短信）可通过
@ConditionalOnProperty分支加载，保持单一入口
注册配置并发布使用
让 Spring Boot 扫描到你的配置类：
- Spring Boot 2.7 及更早版本：在
resources/META-INF/spring.factories中写入org.springframework.boot.autoconfigure.EnableAutoConfiguration=\com.company.notify.NotifyAutoConfiguration - Spring Boot 3.x：改用
resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports，每行一个全限定类名 - 打包后部署到私有 Maven 仓库（如 Nexus），其他项目只需添加依赖即可
- 使用方在
application.yml中开启配置，无需@Import或手动@Bean，启动时自动注入
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
