1. 这场分手其实蓄谋已久我和XML的关系最早可以追溯到刚学Spring那会儿。那时候写一个Spring项目第一步不是写代码而是先得伺候好那一大坨XML配置。applicationContext.xml、spring-mvc.xml、spring-mybatis.xml有时候工程还没跑起来光是配置文件就先写了上百行。更要命的是这些配置还不能随便写错一个标签顺序不对、一个class路径打错启动报错能查半天。你有没有经历过这种场景明明只是加了一个新接口结果为了在XML里注册一个Bean还得翻到几百行开外找到对应的位置小心翼翼地加一段配置再重新启动整个应用。要是赶上多个环境切换还得维护dev、test、prod三套XML配置哪个字段漏改了线上出问题就是分分钟的事。所以当我第一次接触Spring Boot看到那句“约定优于配置”的口号时说实话心里是既期待又怀疑的。期待的是它真能解放我怀疑的是它靠什么取代那套已经用了多年的XML体系。结果一上手就明白了Spring Boot确实把我和XML彻底拆开了而且拆得干干净净。这篇博客我就用自己从传统Spring过渡到Spring Boot的真实经历聊一聊这场“分手”到底是怎么发生的Spring Boot这个“新恋人”又凭什么打动了我。无论是准备入门Spring Boot的小白还是想从传统Spring迁过来的老开发这篇都值得你花几分钟认真看一看。1.1 当年XML配置的真实痛点先说清楚Spring早期选择XML作为配置方式本身是有道理的。XML天生就是结构化的标记语言层次清晰可读性不错配合DTD或Schema还能做格式校验这在那个Java注解还不算普及的年代已经是很成熟的方案了。但问题在于当项目规模变大之后XML的缺点就会暴露得特别明显。第一是配置量太大。一个稍微复杂一点的项目要配置数据源、事务管理器、MyBatis的SqlSessionFactory、Spring MVC的视图解析器、拦截器、过滤器……每一项都是一堆标签。我见过一个老项目光applicationContext相关文件就有六个加起来小两千行新来的同事光读懂这些配置就花了一周。第二是配置和代码分离改起来太割裂。你明明改的是Java代码里的一个字段却要去XML里同步改对应Bean的属性。一旦忘记改运行期才会报错排查成本极高。用一句很糙的话来说就是改的时候想骂人查的时候更想骂人。第三是环境切换太痛苦。以前做多环境部署没有什么application-dev.yml这种好东西就是拿着三份XML挨个对比着改。经常出现这种情况测试环境跑得好好的一上生产就报数据库连接失败最后发现是生产环境那份配置里面少了一段driver-class-name这种锅背得实在太冤。经历过这些折磨再看到Spring Boot那一套注解加自动配置的玩法你真的会有一种如释重负的感觉。它不仅仅是把配置从XML换成了别的格式而是从根本上改变了配置的书写方式和使用方式。1.2 分手不是一时冲动从Spring到Spring Boot的演变逻辑很多人以为Spring Boot是Spring的全新替代品这其实是个误解。准确地说Spring Boot是站在Spring这棵大树之上的一套快速开发框架它没有另起炉灶而是把Spring原来需要手动配置的工作尽量交给自动化和约定来处理。Spring Boot最核心的五个特点你完全可以记下来无论是写简历还是应付面试都很好用自动配置通过EnableAutoConfiguration或Spring Boot 2.7之后的AutoConfiguration.imports机制根据classpath下的依赖自动创建Bean。起步依赖一个spring-boot-starter-web就能把Web开发相关的jar包全部带进来不用再手动逐个维护版本。内嵌容器内嵌Tomcat、Jetty或Undertow不再需要单独部署WAR包到外置容器里。配置简化用application.yml或application.properties替代了绝大部分XML配置。生产就绪自带了spring-boot-starter-actuator提供健康检查、指标暴露、环境信息等监控能力。这一套组合拳下来至少省掉了我原来一半的配置工作量。而且更关键的是Spring Boot帮我们把“约定”固定成了一套标准。你只要按照它的目录结构放类、按照它的命名规范写配置它就能自动帮你把组件组装起来。这种“无感”的体验和以前在XML里一对一注册Bean的体验完全不是一个量级。当然Spring Boot也不是神仙。真正复杂的项目光靠自动配置是撑不起来的你依然需要手写Java配置类用Configuration加Bean来精确控制Bean的创建。但这时候你已经不需要跟XML打交道了配置类本身也是一段Java代码写起来顺手得多。2. Spring Boot的“新恋爱对象”注解和自动配置咱们得承认XML这个旧爱并不是彻底没用了。在一些老项目的维护、某些特殊中间件的对接上XML依然有它的一席之地。但Spring Boot也有了更心动的新选择那就是基于注解的配置方式和自动装配机制。如果说XML配置像手写信件你得每一句都写清楚那Spring Boot的自动配置就像对方已经读懂了你的心思只要你在类路径下放一个对应的starter它就知道你想干什么。不要小看这种体验差异日常开发中这种“默认帮你搞定”的设计能省下大量时间。2.1 注解配置把小配置直接写进代码里Spring从早期就支持注解但真正让它成为主流的是Spring Boot把这套体系发扬光大了。现在你在一个Spring Boot项目里最常见的操作就是在类上打一个Component、Service、Repository或者Controller然后在需要注入的地方打一个Autowired一切就搞定了。举个例子传统Spring里要注册一个UserService你得在XML里这样做bean iduserService classcom.example.service.UserService property nameuserMapper refuserMapper/ /bean而在Spring Boot里你只需要在UserService类上标一个Service然后在私有属性上加AutowiredService public class UserService { Autowired private UserMapper userMapper; }就这么简单该注入的注入该创建的创建容器全部接管。不需要额外的配置文件不需要维护Beans之间的关系代码即配置。可能有朋友会问那Value、ConfigurationProperties这类注解又是干什么的它们本质上也是把配置从XML搬到了Java代码里。比如原来在XML里配置数据源连接池现在可以直接在application.yml里写spring: datasource: url: jdbc:mysql://localhost:3306/test username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver然后在代码里定义一个数据源配置类来读取这些属性。这种做法的最大好处是配置项、默认值、类型校验都放在了一起IDE还能帮你自动提示写错了当场就能发现再也不用等到运行期才报错。2.2 自动配置机制这才是真正的“恋爱脑”如果说注解是一条一条地声明那么自动配置就是Spring Boot最核心的“读心术”能力。它不需要你一个个地注册Bean而是扫描你引入的依赖判断你大概率需要什么然后把Bean直接创建好扔进容器里。这里面最关键的原理是条件装配。Spring Boot使用了ConditionalOnClass、ConditionalOnMissingBean、ConditionalOnProperty等一系列条件注解来判断某个自动配置类是否生效。就拿spring-boot-starter-web来说当你把它加到pom里Spring Boot会发现你的classpath下有Servlet、DispatcherServlet这些类于是自动配置类DispatcherServletAutoConfiguration就会被激活帮你把前端控制器、内嵌服务器、默认的错误页等组件全部配置好。你根本不需要写一行配置一个能接收HTTP请求的Web项目就跑起来了。这里我顺便提一个进阶知识点也是Spring Boot面试题里的高频考点Spring Boot到底是怎么找到这些自动配置类的Spring Boot 2.6及更早版本主要看META-INF/spring.factories文件里的EnableAutoConfiguration配置项。从Spring Boot 2.7开始官方逐渐把自动配置的注册信息迁移到了META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件中。到了Spring Boot 3.x新格式已成为标准spring.factories里的自动配置列表基本不再使用。所以你看连“如何加载自动配置”这件事都一直在演进做开发真的不能只记死知识要看版本、看文档、看源码。2.3 配置文件也不是非XML不可Spring Boot不仅把Bean的定义方式从XML换成了Java注解和自动配置连程序的运行参数、数据源、日志、线程池这些配置都统一收拢到了application.yml或application.properties里。YAML这种格式是我个人非常喜欢的它通过缩进表示层级关系比XML那种满屏尖括号的写法清爽太多。同样是配置数据库XML可能长这样bean iddataSource classorg.apache.commons.dbcp.BasicDataSource destroy-methodclose property namedriverClassName valuecom.mysql.jdbc.Driver/ property nameurl valuejdbc:mysql://localhost:3306/test/ property nameusername valueroot/ property namepassword value123456/ /bean而YAML是这样的spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/test username: root password: 123456你一眼就能看出来YAML的可读性更好层级关系也更直观少了那一堆尖括号和标签眼睛舒服太多了。当然application.properties也完全没问题它就是一个keyvalue的格式适合简单场景。它们俩Spring Boot都支持甚至可以同时存在但建议不要混合使用实在容易踩坑。3. 实操用Maven构建一个Spring Boot项目光说不练假把式。讲完了原理和设计思路下面我直接演示一遍从零搭建一个Spring Boot项目的完整过程顺便把期间会遇到的一些坑也指出来。我用的构建工具是Maven这也是目前最主流的方式。3.1 从零创建工程最稳妥的起步方式创建Spring Boot工程一般有两种路径一种是去 Spring Initializr 网站上勾选依赖生成压缩包下载另一种是直接在IDE里通过内置的工具创建比如IntelliJ IDEA的Spring Initializr插件。我个人更推荐你在IDEA里直接建因为集成度高依赖选好之后会自动下载省去手动导入的麻烦。创建的时候需要注意几个关键点Group填你的公司或组织域名倒写比如com.example。Artifact填项目名比如hello-boot。Type选择MavenJava版本建议选你本机已安装的版本Spring Boot 3.x要求Java 17以上。依赖先只勾Spring Web就够了其他等需要的时候再加。工程创建完成后IDEA会自动生成一个主启动类长这样SpringBootApplication public class HelloBootApplication { public static void main(String[] args) { SpringApplication.run(HelloBootApplication.class, args); } }那个SpringBootApplication注解是一个组合注解它里面包含了SpringBootConfiguration、EnableAutoConfiguration和ComponentScan三个核心注解。你可以把它理解成我的应用就在这里启动帮我开启自动配置帮我扫描当前包下所有组件。很多新手不知道这个启动类一定要放在顶层包下也就是所有其他类的父包。如果你把它放到了某个子包里ComponentScan默认扫描的范围就变了导致很多Controller、Service注入不进去启动不报错但访问接口一直是404。3.2 核心实现步骤写一个能跑的REST接口工程建好后我在启动类的同包或者子包下建一个controller包新建一个HelloControllerRestController RequestMapping(/api/hello) public class HelloController { GetMapping public String sayHello(RequestParam(defaultValue Spring Boot) String name) { return Hello, name ! 我已经和XML分手了。; } }这里的RestController表示这是一个纯接口类方法的返回值会直接以JSON或文本形式写入HTTP响应体不需要再额外配置视图解析器。GetMapping表示处理GET请求。写完之后直接运行启动类的main方法控制台出现类似Tomcat started on port(s): 8080的日志就说明启动成功了。然后浏览器输入http://localhost:8080/api/hello?nameJava就能看到接口返回的JSON结果。从写代码到跑通整个流程全程没有写一行XML配置没有部署到外置Tomcat一个Maven坐标加一个SpringBootApplication注解就把Web环境全搞定了。这在以前真的不敢想。3.3 进一步接触新恋人配置文件的魔术等接口通了以后咱们可以再玩一点花活。给工程加一个自定义配置然后通过注解读出来展示在接口里。先在application.yml里加一个自定义配置app: name: My First Spring Boot App version: 1.0.0然后创建一个配置属性类ConfigurationProperties(prefix app) public class AppProperties { private String name; private String version; // getter和setter省略 }在启动类上加上EnableConfigurationProperties(AppProperties.class)就可以在Service或Controller里注入这个配置了。这样做的好处是所有的第三方配置、业务参数都可以用这种强类型的方式管理比散落在各个XML里的property标签强得多。我再延伸一句配置还可以按环境拆分。比如建一个application-dev.yml、application-prod.yml然后通过spring.profiles.activedev这个参数来切换环境发布的时候只需要指定一个参数根本不用像以前那样改三份XML。这个体验上的差距谁用谁知道。4. Spring Boot的隐藏加分项监控、JSON与生态集成恋爱谈了甜头尝到了再说几个Spring Boot真正让人上头的点。这些功能有一半属于“你不主动研究就可能错过但一旦用起来就回不去”的类型。4.1 生产级监控Actuator和MicrometerSpring Boot自带的spring-boot-starter-actuator是我非常推荐大家上手的模块。它能暴露各种运行时信息健康状态、指标数据、Beans清单、自动配置报告、日志级别、线程快照等等。配置起来特别简单。在pom里引入dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-actuator/artifactId /dependency然后在application.yml里配置暴露端点management: endpoints: web: exposure: include: health,info,metrics,beans,configprops启动后访问http://localhost:8080/actuator/health就能看到服务健康状态。配合Micrometer还能把指标数据接入Prometheus或者InfluxDB做一套比较完整的监控体系。不过这儿我得特别提醒一句不要在生产环境把所有Actuator端点都暴露在外网尤其是shutdown、heapdump、env、beans、conditions这类端口信息泄露风险极高。之前网上爆出过Spring Boot Actuator相关的漏洞大多都是因为运维对端点访问没有做权限控制所致。建议设置独立的management端口或者加上spring-security依赖对端点做访问认证。4.2 默认JSON处理一整套“开箱即用”的序列化机制现代后端开发已经基本离不开JSON了你返回给前端的数据、接收前端的参数、调用第三方接口的报文全是JSON格式。Spring Boot默认就集成了Jackson你只需在接口方法上返回一个对象它就会自动把对象序列化成JSON。比如GetMapping(/user/{id}) public User getUser(PathVariable Long id) { return userService.getById(id); }Spring Boot会自动调用Jackson的ObjectMapper把User对象转成{id:1,name:张三,email:zhangsanexample.com}这样的JSON字符串响应头也会自动设置成application/json。如果你对Jackson的默认行为不满意比如想对日期格式做统一处理、想忽略某些字段、想空值不出现在JSON里都可以在application.yml里配置或写一个自定义的ObjectMapper。这种灵活性比早期用ResponseBody还得手动引入Jackson还得自己装配要舒服太多。另外说一句虽然Fastjson也是很多老项目在用的库但这些年它的安全漏洞实在太多我不建议在新项目里使用Spring Boot自带的Jackson以外的JSON库。Jackson的成熟度、社区维护速度应对日常需求完全足够。4.3 生态集成从消息推送到SDK对接Spring Boot的另一个强项是生态集成足够丝滑。比如和Firebase集成做消息通知与传统Spring项目需要写一堆Bean配置不同在Spring Boot里只需要引入对应的SDK在application.yml里配置好服务账号路径再写一个配置类注册FirebaseApp实例就行。配置类本质上也只是一个普通的Configuration类Configuration public class FirebaseConfig { Value(${firebase.config-path}) private String configPath; Bean public FirebaseApp firebaseApp() throws IOException { if (FirebaseApp.getApps().isEmpty()) { FileInputStream serviceAccount new FileInputStream(configPath); FirebaseOptions options FirebaseOptions.builder() .setCredentials(GoogleCredentials.fromStream(serviceAccount)) .build(); return FirebaseApp.initializeApp(options); } return FirebaseApp.getInstance(); } }这种模式其实是Bean方法最典型的使用场景把第三方SDK的初始化逻辑封装成一个Bean交给Spring容器管理。你以后再接什么阿里云、腾讯云、华为云的SDK几乎都可以照搬这个套路。所以你会发现Spring Boot之所以强大不只是因为它省掉了XML配置更重要的是它提供了一套统一的、可扩展的开发模式——无论你遇到什么第三方组件都能用相近的姿势把它整合进来。这种“谈一个恋爱就打通了一个圈子”的感觉确实是传统Spring给不了的。5. 常见问题与踩坑实录聊到这里估计你已经急着动手了。不过我还是想按老规矩把自己在实际操作中踩过的一些坑和排查经验整理出来给大家当个避雷针。这部分内容网上不一定都有但遇到的时候那是真的耽误时间。5.1 自动配置没生效接口一直404新手最常见的问题之一明明Controller写好了启动也不报错但访问接口一直是404。这时候先别急着怀疑Spring Boot多半是启动类的位置放错了。如果你把SpringBootApplication所在的启动类放在了某个子包下面比如com.example.controller这个层级那么Spring Boot只会扫描这个包及其子包下的类你在com.example.service里的类就扫描不到Bean自然不会被注册。解决办法很简单把启动类移到所有业务类的上一层包也就是com.example下。另外一种排查办法是访问/actuator/mappings端点如果你开启了Actuator能看到当前所有已注册的HTTP接口映射一目了然。5.2 YAML配置的缩进和中文乱码YAML是缩进敏感的语言很多人第一次写容易把层级缩进搞错。比如spring: datasource: url: jdbc:mysql://localhost:3306/test这里url的缩进和datasource平级了Spring Boot会报绑定失败或者根本识别不到这个配置项。IDE一般会自动帮你修正缩进但如果你用的编辑器不支持就很容易踩这个坑。中文乱码问题也不少见尤其是Windows环境下application.yml文件里的中文字符如果没有以UTF-8保存启动后配置读出来就是乱码。建议把IDE的默认文件编码统一设成UTF-8这是最一劳永逸的办法。5.3 端口占用启动报Web server failed to start这个算是高频故障了。Eclipse、IDEA或者别的进程占用了8080端口Spring Boot启动就会失败。最简单的两个解法关掉占用端口的进程Linux可以用netstat -tlnp | grep 8080查出PID再kill。或者直接在application.yml里换端口server: port: 8081我个人更推荐先用占用排查因为你还会遇到8080、8081都被占用的极端情况。学会查端口比一直换端口重启更高效。5.4 版本兼容问题Spring Boot 3.x和Java的关系如果你用的是Spring Boot 3.x那么本地Java版本必须17以上如果还用Java 8写启动直接会在编译阶段就报错。网上很多教程是Spring Boot 2.x配Java 8你只换了一个Spring Boot版本就会出现各种不兼容的情况。同理一些老的第三方starter可能还没有适配Spring Boot 3.x引进来会出现ClassNotFoundException或者NoSuchMethodError。建议新项目倒还好直接选最新稳定版老项目升级到Spring Boot 3.x之前先确认所有依赖都兼容别盲目追新。5.5 XML配置要完全删除吗不见得很多从老项目迁移到Spring Boot的朋友有个习惯就是见到XML就删。我的建议是能删的尽量删但别一刀切。因为有些依赖的Bean定义还是通过XML导入的比如你自己封装的某个中间件官方只提供了XML的配置方式。Spring Boot其实也留了后门你可以用ImportResource(classpath:legacy-config.xml)把老的XML配置导入到Spring容器里来实现渐进式迁移。但后续新写的代码我是强烈建议别再用XML了否则等于一边跟旧爱藕断丝连一边又跟新欢谈着恋爱到头来两边都不讨好。5.6 常见问题速查表问题现象常见原因解决建议接口404启动类包路径不对将启动类移到顶层包Bean注入失败缺少Component或扫描包不匹配检查扫描范围端口启动失败端口被占用查PID、切换端口中文配置乱码文件编码问题统一UTF-8编码自动配置没生效条件不满足、依赖未引入查看自动配置报告Jackson返回null字段默认序列化策略自定义ObjectMapper排查自动配置问题时候有一个很有用的技巧在application.yml里开启debug模式debug: true启动后控制台会打印出所有自动配置的匹配报告哪些生效了、哪些因为条件不满足被忽略一目了然。这个对理解Spring Boot的自动配置机制非常有帮助强烈建议你亲手跑一次看看。6. 写在最后的几句真心话和XML说再见的这几年我最大的感受是技术选型从来不是越老越好也不是越新越强而是要看它能不能帮你把复杂的事情变简单把脆弱的地方变稳定。Spring Boot给出的答案是把选择收敛成约定把重复交给自动把复杂藏在封装之下。但打个不恰当的比方谈了恋爱也不意味着前女友就一无是处。XML在配置复杂多级结构、可校验性、工具链成熟度上至今仍有不可替代的场景。那些遗留系统、那些老牌中间件很多依然需要XML来声明结构。所以我的态度一直是新项目放手用Spring Boot面对老项目也不必急着推翻重来在能掌控的范围内逐步前行就好。最后再送你一个实操建议不要只看Spring Boot的“魔法”有时间一定要去读一遍AutoConfiguration.imports里的自动配置类源码。你只有真的理解了自动配置背后的判断逻辑才不会被各种不可预期的框架行为牵着鼻子走。到那时候你才算真正和XML正式分手也真正迎接了这个新恋人。