做Java后端这些年Spring和SpringBoot就像是前后脚走进办公室的两个同事。一个资历老成、规则多一个上来就把麻烦事全包了。我见过不少人直接跳过Spring去学SpringBoot也见过老项目还在用当年的XML配置硬撑着两种场景我都踩过不少坑。写这篇东西不是为了论证后者一定比前者强而是想聊聊我在真实项目里经历的这套进化路径Spring给我留下的基础认知SpringBoot到底帮我省掉了哪些事以及迁移过程中文档里不会写但一定会遇到的坎。1. Spring时代的经典套路1.1 XML配置Spring当年的立身之本回到很多年前Spring之所以能成为Java后端的事实标准核心就一句话把对象的创建和依赖关系交给容器管。但“交给容器管”这件事在早期落地的时候并不轻松。最常见的做法是维护一个巨大的applicationContext.xml里面一个个bean标签。随便一个小项目数据源、事务管理器、DAO、Service、Controller几十个bean是常态。配置长什么样我到现在都记得bean iddataSource classorg.apache.commons.dbcp.BasicDataSource property namedriverClassName valuecom.mysql.jdbc.Driver/ property nameurl valuejdbc:mysql://localhost:3306/xxx/ property nameusername valueroot/ property namepassword value123456/ /bean bean idjdbcTemplate classorg.springframework.jdbc.core.JdbcTemplate property namedataSource refdataSource/ /bean bean idtxManager classorg.springframework.jdbc.datasource.DataSourceTransactionManager property namedataSource refdataSource/ /bean这段配置现在看不算复杂但它只是开胃菜。一旦项目里引入MyBatis、集成消息队列、接入缓存XML就会像滚雪球一样膨胀。经常出现的情况是某个bean改名连带着在XML里得找出五六个ref去改某个环境漏了一段配置启动时候莫名其妙报一堆NullPointer。更痛苦的是XML里写错一个路径、少写一个属性都是运行期才炸排查起来全靠经验和眼神。那个年代有个说法“Spring入门容易精通难”。正是因为核心概念好理解但配置体系的复杂度和项目规模成正比真正把一套Spring项目从零跑通背后需要的是大量试错。1.2 注解配置一次进步但没完全解决问题后来Spring推出了注解配置Component、Autowired、Service这些注解让代码里的依赖关系变得清晰了很多。XML里终于不用再堆几百个bean了只要配一个包扫描context:component-scan base-packagecom.example/再加上各种Configuration类Java代码就能代替一部分XML。但这时候问题并没有消失只是换了个地方。你依然要手动管理很多东西Spring MVC的视图解析器、拦截器、文件上传解析器、消息转换器每一项都需要单独配置。DataSource还是得自己建JdbcTemplate还是得自己声明事务管理器还是得自己配Web项目依然要打包成WAR放到Tomcat或者别的应用容器里才能跑。当时我记得最清楚的场景是新同事入职光是把开发环境搭起来就能花上一天。JDK版本、Maven镜像、Tomcat版本、依赖冲突、配置文件里的环境变量任何一环出问题后面的活都没法干。很多人第一次接触Spring的体验不是优雅而是心累。但这不是Spring本身设计得不好而是它做了太多“可配置的事”。它给了你很大的自由也就意味着你必须花费足够的精力去理解、去约束、去组装。SpringBoot的出现本质上就是把这一层“组装”的复杂度接走了。2. SpringBoot到底做了哪几件关键的事2.1 自动配置条件化的魔法背后是条件判断SpringBoot最核心的能力拆开看就只有四个字自动配置。但自动配置不是玄学它的底层是一堆Conditional注解加上spring-boot-autoconfigure模块里的各种AutoConfiguration类。说白了它的判断逻辑就是你classpath里有没有某个类有我就自动创建对应的bean没有我就不管。你配了某个属性吗配了我按你的属性来设置没配我用默认值。拿DataSource举例。之前XML里要手动声明一个BasicDataSourceBoot时代你可能只需要在配置文件里写几个spring.datasource开头的key。当Boot发现classpath里有Spring的DataSourceTransactionManager依赖、有数据库驱动、并且你自己没定义DataSource类型的bean它就会自动new一个HikariCP数据源出来。如果看不到这层机制你很容易觉得“这是在变魔法”。实际上它非常机械DataSourceAutoConfiguration类加载的时候看ConditionalOnMissingBean(DataSource.class)是否成立成立就干活。真正要做的事其实是“理解你到底想不想让它替你干活”。当你自己定义了核心beanBoot会优先尊重你的选择自动配置自动退场。这里面的经验是遇到自动配置不生效先别急着怀疑框架。用--debug参数启动应用控制台会打印一份自动配置报告。Positive matches和Negative matches清清楚楚列出来哪些条件成了、哪些没成一眼就能定位。2.2 Starter依赖给项目开一份精选菜单自动配置负责创建bean但这些bean得先有依赖才聊得上“condition成立”。这时候Starter就上场了。spring-boot-starter-web、spring-boot-starter-data-jpa、spring-boot-starter-test这些依赖本质上不是什么新框架而是把若干个“配合默契”的依赖打成一个包。以前你引入Spring MVC得自己数清楚需要几个jarspring-web、spring-webmvc、jackson-databind、servlet-api、tomcat-embed-core……版本还不能乱配。Starter把这些事一次性办完版本由Boot的BOM统一锁定。这套机制的实用价值极高。主要体现在两点第一新项目起步成本极低加一个spring-boot-starter-web就获得了搭一个Web工程的全部基础弹药第二版本冲突的概率大幅下降因为Boot已经替你把常用技术栈的兼容版本都测试过了。它不是消灭了依赖管理这件事而是把“逐个挑选版本”变成了“选一个菜篮子”。不过Starter也有容易踩的坑。最常见的就是“塞太多”。反正加依赖不费劲就把MyBatis的、Redis的、消息队列的、监控的Starter全一股脑放进pom里。结果就是启动变慢、自动配置报告老长老长还容易出现莫名其妙的bean冲突。Starter是菜单不是自助餐按需点菜才是正确用法。2.3 内嵌服务器WAR包时代的落幕传统Spring项目部署需要先把项目打成WAR然后扔到外置的Tomcat的webapps目录里启动Tomcat才能访问。这个过程其实藏着不少坑本机Tomcat版本和服务器Tomcat版本不一致某些JSP或Servlet写法在高版本容器里行为完全不同部署机器环境要单独调优。SpringBoot把Servlet容器变成了内嵌组件。你只需要一个可执行JARjava -jar直接跑起来应用自己带着Tomcat或者换Jetty/Undertow。从“装容器、部署应用、管理容器”变成了“跑一个进程”部署的复杂度发生了质变。我曾经把一个老项目迁移成Boot之后部署脚本从原来的十几行shell缩到了两行一行打JAR一行java -jar启动。这在日常发布和扩容场景下省下的精力非常可观。尤其现在云上部署、容器化环境流行内嵌服务器这种方式天然适配“一个镜像一个进程”的模式写Dockerfile的时候甚至不用再关心应用服务器那一层。3. 迁移动手课Spring项目改造SpringBoot实战3.1 从一个真实的老工程开始假设手里有个传统的Spring Maven项目包结构大概是这样的src/main/java/com/example ├── controller ├── service ├── dao └── resources ├── spring-mvc.xml ├── spring-mybatis.xml └── jdbc.properties用的是Spring MVC MyBatis没有Spring Boot没有内嵌容器。第一步不是直接改pom而是先看清楚依赖。因为Boot的Starter已经内置了常见框架的依赖如果你直接把老依赖硬加进来很容易出现两个不同版本的jar同时在classpath里打架。我一直的建议是新建一个Boot工程然后把老工程的源码和配置迁过去比“原地升级”要干净很多。3.2 配置迁移XML走向Java Config和配置文件老工程里的spring-mvc.xml通常会干这几件事开启注解扫描、配置视图解析器、配置静态资源、配置拦截器。迁移到Boot之后注解扫描不需要了因为SpringBootApplication自带ComponentScan默认从启动类所在包往下扫。视图解析器如果是JSP那套Boot里通过spring.mvc.view.prefix和suffix配置就行如果是前后端分离连视图解析器都不需要直接RestController返回JSON。spring-mybatis.xml这块要麻烦一点。老工程里通常会配SqlSessionFactory、MapperScannerConfigurer之类的东西。Boot里有两种选择一种是用mybatis-spring-boot-starter它会自动完成SqlSessionFactory的创建和Mapper扫描另一种是保留JavaConfig自己写一个Configuration类手动注册SqlSessionFactoryBean同时用MapperScan指定Mapper接口所在的包。我个人的建议是除非老项目里对SqlSessionFactory做了非常特殊的定制否则优先沿用mybatis-spring-boot-starter的默认方式。理由很简单Default自动配置已经处理好了DataSource和SqlSessionFactory的关联你只需要把数据源配置好就行。手动新建的话不但要自己保证事务管理器和SqlSessionFactory跟DataSource用的是同一个实例而且一旦多数据源场景出现复杂度会翻倍。3.3 properties配置把散装配置集中起来老工程常见配置散落在多个properties和XML里迁移的时候正好可以一并收拢到application.yml。举个例子server: port: 8080 servlet: context-path: / spring: datasource: url: jdbc:mysql://localhost:3306/old_project?useUnicodetruecharacterEncodingutf8 username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver servlet: multipart: max-file-size: 10MB max-request-size: 20MB mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.dao.model有一点值得注意老配置里的driverClassName在这里要写成driver-class-name这是Boot里规范化后的key。很多人在这一步踩坑因为两边的命名风格不一样。另外老项目里的数据库URL如果写的是jdbc:mysql://localhost:3306/xxx到了新版驱动上可能因为时区问题启动报错建议在url后面加上serverTimezoneAsia/Shanghai这样的参数。3.4 启动类和事务行为Boot工程需要一个主启动类形式非常固定SpringBootApplication public class DemoApplication { public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } }有人会问老工程里的Root Context和Servlet Context在Boot里怎么对应Boot把这件事简化成了在一个应用上下文里完成。SpringBootApplication内部就是Configuration、EnableAutoConfiguration、ComponentScan三个注解的组合你不需要再单独加载spring-mvc.xml和spring-mybatis.xml所有Bean都在同一个容器里。事务方面老工程如果之前在XML里配置过tx:annotation-driven transaction-managertxManager/那么Boot里有两种保留方式一是依赖自动配置的事务管理器只要DataSource是Boot自动创建的DataSourceTransactionManager也会自动创建二是在任意Configuration类上手动加EnableTransactionManagement。多数情况下我建议不要自己重复声明事务管理器。Boot已经帮你做好了重复声明反而可能覆盖掉它精心配置的连接属性。3.5 打包和启动方式的变化老Spring项目打WAR包然后丢到Tomcat里。Boot项目打的是可执行JAR但有一点要特别提醒如果你依赖了JSP或者项目里还有一部分老Servlet代码直接打成普通JAR是有风险的。Boot的官方态度是JSP支持但有限制最好别把JSP当成第一选择。如果是内部老系统强依赖JSP那要么继续用WAR方式部署要么干脆打包的时候指定打包方式是war但这也意味着你保留了一个内部的Servlet容器启动类需要额外配置SpringBootServletInitializer。如果你前程无忧项目是REST接口那直接默认打JAR用java -jar启动即可。启动后可以通过spring.profiles.active切换不同环境的配置这样同一个JAR在测试环境和生产环境都能用同一份构建产物只是启动参数不一样。这种“同一产物不同环境”的做法比当年维护多份配置文件的体验好太多。4. 自动配置和深入问题排查4.1 自动配置失效的经典排查现场迁移完成之后很容易遇到一个情况应用起来了但某个功能没生效。最典型的是“我自定义了一个Filter怎么不执行”或者“我自己手写了一个RestTemplate为什么没走我配的属性”遇到这类问题我的第一动作永远是看自动配置报告。在启动参数里加--debugBoot会打印出所有自动配置的启用和跳过原因。比如某个xxxAutoConfiguration显示Negative match原因是ConditionalOnClass没有找到对应class那大概率是依赖没引全如果显示是因为ConditionalOnBean没满足那说明你的自定义bean没有在正确时机注册。这个报告是排查复杂问题的导航仪。不要凭感觉猜先看报告再决定改代码还是改依赖。我在实践里靠这个报告解决过至少七八个看起来毫无头绪的冲突。4.2 多数据源场景自动配置反而需要打破Boot的自动配置名单里单数据源是默认最优路径。一旦涉及多数据源情况就不一样了。比如一个项目既连业务库又连日志库。如果你只写一套spring.datasource.urlBoot只会创建一个DataSource。另一个库连不上必然会报错。常规做法是两套数据源都用自己的ConfigurationProperties绑定不同前缀的配置并且自己定义DataSource、SqlSessionFactory、MapperScan。这种情况下反而要绕过Boot的自动配置明确告诉它“这里不需要你帮忙”。绕过的办法有两个关键点。第一两个DataSource类要注意Primary标记否则MyBatis或者JPA在注入默认数据源时会分不清第二要确保自己创建的SqlSessionFactory和对应的DataSource绑定不要让人一个Mapper无意识走到另一个库里去了。多数据源是所有Boot项目里最容易翻车但又极常见的高频需求方案本身不复杂但每一步都得落实到明处。4.3 Starter版本冲突的实战处理BOM能解决大部分版本冲突但不是所有。实际项目中某个业务方强行引入了一个老版本的依赖比如Oracle驱动是固有的或者某个私有中间件不在SpringBoot官方管理范围内就很容易把类路径搅浑。这种问题的排查经验我总结成一个套路先执行mvn dependency:tree看依赖树找出同一个包出现的不同版本。确认冲突链看看是不是有传递依赖在作怪。在pom里用exclusion把不需要的版本排除掉。重新开启--debug观察启动是否正常。有人喜欢图省事直接dependencyManagement里强制指定版本。但这个操作要谨慎因为你压下去的版本可能和Boot的其他组件不兼容。原则是能用exclusion排除就排除尽量保留Boot BOM里的版本。4.4 启动慢、自动配置加载慢的问题有些老工程迁移到Boot之后启动速度反而比原来还慢。常见原因有几个一是引入的Starter太多启动时做的class扫描和条件判断大量堆积。这可能体现在SpringBootApplication默认扫描了整个包连带扫描进去许多其实用不到的组件。可以在启动类上细化ComponentScan的basePackages缩小扫描范围。另外MapperScan这类地方如果写的是顶层包也会触发大量Mapper接口的检查尽量精确到具体子包。二是HikariCP连接池预热。如果数据库在网络环境里启动时连接池初始化会阻塞。把spring.datasource.hikari.initializationFailTimeout设置为负数或者合理调大超时可以避免因为数据库临时不可用导致启动卡死。三是日志框架反复初始化。老工程可能本身带了一套log4j2配置Boot又引入logback两边互相干扰。最好统一用SpringBoot默认的logback或log4j2来配置并保证只有一套日志实现。5. 迁移过程中的实战经验总结5.1 “小步迁移错峰收尾”的策略我见过有人一口气把几百个文件的老项目直接切到SpringBoot结果陷入无穷无尽的兼容性修复里。正确的方式应该是小步推进先把配置迁移完成让老项目在Boot上能跑起来不追求重构代码然后逐步替换掉老的基础设施依赖比如缓存客户端、消息客户端换成Boot风格的版本最后再看能不能用自动配置替代手写的Bean定义。这个顺序的好处是每一步都有可控验证点。配置迁移好了启动起来能跑接口这一步就完成了。如果一上来就大刀阔斧改业务代码出了问题都分不清是配置的锅还是逻辑的锅。5.2 保留核心认知不要丢掉Spring本身很多新人一上来就学SpringBoot觉得Boot太方便了根本不用知道bean是什么。这其实是个很大的误区。Boot做的自动配置是“帮你做决定”但如果你不懂“为什么要这样决定”一旦遇到异常场景就抓瞎。比如NoSuchBeanDefinitionException连是哪个bean缺失、为什么缺失都判断不出来那连问题都无从下手。Spring的核心内容IOC容器、AOP、Bean生命周期、事务抽象依然是Boot体系里最需要掌握的地基。把这两者关系比喻一下Spring就像发动机的原理Boot就像一辆帮你调试好车况的车。你可以不会修发动机就直接开车但跑长途的时候遇到仪表盘报警不懂原理的人只能停在路边等救援。能做这个比喻就是想强调两者不是对立的替代关系而是逐渐演进的前后阶段。5.3 你不需要为了用Boot而用Boot虽然我整体是强烈推荐SpringBoot的但有个边界要划清楚小项目、内部工具类项目、或者纯Spring生态里非常定制化的项目可能并不需要硬切到Boot。举个例子一个纯内部使用的定时任务脚本只是用Spring的ApplicationContext加载几个bean处理数据没有Web层、不需要外部HTTP接口这种情况下Boot的价值并不明显反而增加了启动开销。Boot更适合的是需要快速启动、快速部署、面向外界提供服务的场景。场景决定选型不要因为Boot是“流行技术”就无脑套用。6. 常见问题与排查笔记速查现象大概率原因排查方向数据库连接一直初始化失败URL格式、时区参数、驱动版本检查driver-class-nameMySQL8用com.mysql.cj.jdbc.Driver自定义Filter没生效没交给Spring容器管理Filter用Component注册或通过FilterRegistrationBean注册NoSuchBeanDefinitionException包扫描路径不对确认启动类所在包能否覆盖目标BeanMapper无法注入MapperScan没扫到接口包检查MapperScan的basePackages自动配置没生效条件判断不满足用--debug查看自动配置报告启动校验非常慢扫描范围过大缩小ComponentScan和MapperScan范围出现了两个数据源互相干扰多数据源配置缺Primary指定主数据源并注意两个bean的名称区分打包启动后静态资源404没设置WebMvc静态目录spring.web.resources.static-locations正确指向目录与外部老依赖冲突版本挤占执行dependency:tree排查并用exclusion排除这些小项里最想强调的还是排查现场的心态。SpringBoot隐藏了复杂度但不代表复杂度消失了。它只是把“造轮子”的部分吞到了底层。遇到问题时别急着质疑框架也别急着堆补丁顺着自动配置逻辑去逆向追踪绝大多数谜题都能解开。最后聊一点个人体会。我刚开始接触SpringBoot的时候因为Boot太“省事”了反而产生了一种不安全感总觉得事情变简单了是不是会漏掉什么。后来在几个老项目上逐步改造才慢慢明白这种“简单”不是降低标准而是把标准动作固化到框架里让开发者能把注意力真正放在业务本身。这个过程不是一句替代就能说清楚的它更像一套工具从手工走向工业化该保留的零件还是那些零件只是组装方式彻底变了。如果你也正从一个老Spring项目往Boot迁移耐心点先把自动配置报告吃透把启动方式切换干净剩下的变化都会顺理成章。
