基于Spring Boot的自研框架迁移结构方案咨询

方案一：直接继承spring-boot-parent并整合starter到our-framework #

优势 #

• 迁移成本极低，完全保留现有框架结构，业务仓库无需大幅调整——只需把our-framework-parent的父依赖换成spring-boot-parent，our-framework打包所需starter即可，业务项目的依赖声明不用改。
• 依赖管理高度集中，spring-boot-parent的版本管控能力直接复用，业务项目不用再处理Spring Boot生态的版本冲突问题。
• 现有Wicket组件（页眉、页脚等）和Spring基础组件（认证、过滤器等）的整合逻辑可以直接沿用，不需要额外做自动配置适配。

劣势 #

• 耦合性过高，our-framework绑定了固定的starter集合，业务项目如果不需要某些starter（比如非Web项目不需要starter-web），很难干净地排除，会引入冗余依赖。
• 扩展性受限，后续如果要支持不同版本的Spring Boot，或者业务项目有自定义配置需求，这种紧耦合结构会大幅增加调整成本。
• 不符合Spring Boot的starter设计理念，框架组件无法实现按需加载，必须全部初始化，浪费资源。

方案二：拆分出our-framework-spring-boot-autoconfigure和our-framework-spring-boot-starter #

优势 #

• 彻底解耦，starter仅作为依赖传递入口，autoconfigure模块负责通过条件注解（如@ConditionalOnClass、@ConditionalOnMissingBean）实现组件的按需自动配置，业务项目可以根据需求选择是否引入starter。
• 完全贴合Spring Boot生态规范，能和其他第三方starter更好兼容，方便后续框架扩展（比如新增功能模块时，只需新增对应的starter即可）。
• 灵活性极强，支持场景化配置：比如可以根据项目中是否引入Wicket依赖来自动初始化页眉页脚组件，或者根据Spring Security的存在来自动配置认证逻辑。
• 版本管理更清晰，autoconfigure和starter可以独立于our-framework的核心Wicket组件更新，也能更好地适配不同版本的Spring Boot。

劣势 #

• 初期迁移成本高，需要将现有our-framework中的Spring配置类、过滤器、认证组件等拆分到autoconfigure模块，编写自动配置类和条件注解，调整依赖结构。
• 多模块维护成本增加，需要额外维护autoconfigure和starter两个模块，对框架团队的Spring Boot自动配置知识有一定要求。

针对你的场景的实操建议 #

由于你的框架本身基于Spring开发，核心组件和Spring深度绑定，建议分阶段推进：

1. 短期快速迁移：如果业务项目数量多、迁移时间紧张，优先选方案一。可以快速完成Spring Boot适配，同时通过<optional>标记our-framework中引入的非必需starter，让业务项目能按需排除冗余依赖。
2. 长期优化重构：迁移完成后，逐步拆分出autoconfigure和starter模块。将Spring相关的配置、组件逻辑迁移到autoconfigure，实现条件化自动配置；starter模块则依赖autoconfigure和必要的Spring Boot starter，作为业务项目的依赖入口。此时our-framework-parent依然可以继承spring-boot-dependencies，统一管控所有模块的版本，业务项目依然可以继承该parent，按需引入our-framework（核心Wicket组件）和starter（Spring自动配置）。

内容的提问来源于stack exchange，提问作者Phoenix