多模块项目中，将spring-boot-starter依赖置于common而非app是否有实用价值？

有实用价值的场景 #

• 统一依赖版本与配置：如果项目后续会扩展多个Spring Boot业务模块（比如admin、定时任务模块等），把spring-boot-starter（包括父依赖或核心starter）放在common模块里，能强制所有业务模块使用统一的Spring Boot版本，避免版本冲突。同时可以在common里集中配置Spring Boot通用属性（如日志规则、MVC基础参数），其他模块引入common后直接复用，不用重复编写配置。
• 封装Spring Boot通用组件：如果common模块里封装了基于Spring Boot的通用能力，比如全局异常处理器、自定义Redis操作模板、数据库通用Mapper、跨域配置等，这些组件本身依赖Spring Boot的核心API，将spring-boot-starter放在common里是必要的——否则这些组件无法正常编译运行，业务模块引入common时也能自动获取所需的Spring Boot依赖。
• 简化业务模块依赖声明：业务模块（比如app）只需要引入common模块，无需再单独声明spring-boot-starter相关依赖，能让业务模块的pom.xml更简洁，降低依赖维护的工作量。

不建议这么做的场景 #

• common需要被非Spring Boot项目依赖：如果有纯Java工具模块、非Spring的Web模块等需要引入common，把spring-boot-starter放在common里会强制这些模块引入Spring Boot的全套依赖，造成依赖冗余，甚至可能引发类加载冲突。
• common只是纯工具库：如果common里只有字符串处理、日期转换、加密解密这类不依赖Spring的纯工具类，完全没必要引入spring-boot-starter——这会增加common模块的体积，违背工具库轻量化的设计原则。

总结 #

是否将spring-boot-starter放在common模块，核心取决于common的定位：如果common是Spring Boot生态下的通用业务基础模块，供多个Spring Boot业务模块复用，这么做的实用价值很明显；如果common是通用纯工具库或需要被非Spring Boot项目依赖，就不适合这么做。

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