拓冰网站定制 
简介《javaweb框架源码-baltika》是一套基于Spring Framework构建的Java Web应用开源工程以“框架源码工程实践”为主线适合具备一定Java基础、希望深入掌握Spring容器、MVC模式及Web开发最佳实践的中高级开发者作为学习样本。压缩包共48个文件整体仅约1.04MB涵盖后端Java源码、前端HTML页面、JavaScript脚本、CSS样式表、XML配置、字体及图片等资源文件类型完整且工程结构清晰适合按Controller、Service、DAO分层展开阅读。当前已有170人学习下载。通过研读该项目可以直观理解Spring依赖注入如何解耦对象关系AOP切面如何统一处理日志与事务Spring MVC如何处理请求映射与视图渲染同时也能借鉴其数据访问、统一异常处理、国际化等模块的组织方式快速提升自身搭建与重构Java Web应用的能力是一份轻量而典型的框架学习资料也可作为团队内部培训或技术分享的参考资料。1. 项目整体脉络先读懂baltika在讲什么第一次打开baltika的源码目录大多数人会被一堆包名和配置文件劝退。但我建议你不要急着看代码而是先回答一个问题如果让你用Spring Framework从零写一个Java Web应用核心骨架应该长什么样baltika这个名字虽然在国外有啤酒品牌的含义但作为开源项目它本质上是一个典型的Spring MVC分层示例把Controller、Service、DAO、实体对象、配置类、视图层之间的协作方式完整地铺开在你面前。从Package结构来看baltika遵循的是常规的按技术分层而不是按业务模块分包。这个设计决策在初期会显得很规整因为每个分包对应一个职责controller层负责接收HTTP请求和参数绑定service层负责事务边界和业务编排dao层负责跟数据库打交道domain或model包放实体和DTOconfig或resources目录放Spring配置、日志配置、JDBC配置。你把这个骨架吃透了以后看任何基于Spring Framework的传统项目都能在五分钟内定位到对应代码的位置。那baltika适合谁我个人觉得它最适合两类人。第一类是刚学完Spring Core和Spring MVC基础语法、但没真正见过一个完整项目如何组织的人你缺的不是某个注解的用法而是“这些注解怎么拼成一个能跑的系统”。第二类是准备Java面试、尤其面试题里频繁出现Spring容器初始化流程、Spring MVC请求映射、事务传播行为这类八股的人你与其死记硬背不如拿baltika的源码配合着看。它有实际业务场景比如产品管理、订单处理之类的模块Spring的IoC、AOP、声明式事务都是在一个真实可运行的环境里生效理解起来比抽象概念快得多。这个项目的第二个价值在于它用的还是传统Spring XML或JavaConfig方式而不是Spring Boot的一堆自动配置。如果你只学过Spring Boot看到baltika的第一反应会很不适应怎么没有application.yml怎么没有内嵌Tomcat这里Tomcat是自己下载安装的web.xml要自己写DispatcherServlet要自己注册。但这恰恰是好事——Spring Boot把太多细节藏起来了而baltika把这些细节又亮出来给你看。了解传统Spring应用的组装方式会让你反过来更理解Spring Boot帮我们省了哪些事。2. 源码核心装配Spring容器到底在项目中做了什么如果你拉下baltika的源码并全局搜索Configuration、ComponentScan、Bean、Autowired这些注解你会发现它们分布在各个package的角落里。初看会觉得“这不是很常规吗”但实际上这些注解组合起来就是在构建Spring IoC容器容器管理着所有对象的生命周期和依赖关系。我先用一个生活化类比解释IoC在baltika里的意义传统方式写代码你new一个Service对象再new一个Dao对象然后手动把Dao塞进Service就像自己去菜市场买菜、洗菜、做菜而Spring容器接管后你只需要声明“我需要一个Service它需要一个Dao”容器就像中央厨房食材、调料统一采购、统一分发你做菜的人不需要关心食材从哪来。2.1 组件扫描与自动装配的协作逻辑baltika通常会在配置类上标注basePackage比如ComponentScan(com.baltika.controller)或者扫描整个根包。Spring启动时会遍历这些包下面所有标注了Controller、Service、Repository、Component的类把它们注册为Bean。这里有一个值得注意的细节Spring容器默认是单例模式也就是说baltika里同一个Service类只会有一个实例在容器里反复使用。如果你的业务代码里不小心在Service里存了可变的成员变量并发请求下就会互相污染这是新手最容易踩的坑。自动装配方面Autowired是按类型注入的。baltika里一个接口只有一个实现类时没问题但如果以后你自己扩展给某个接口写了两个实现类又不指定Qualifier或Resource(namexxx)启动时Spring会直接抛NoUniqueBeanDefinitionException。我在调试baltika时特意试过这种情况控制台报错会明确指出“expected single matching bean but found 2”解决方式也简单要么加Primary标记主实现要么注入时指定Bean名字。这里还要提一下Spring AOP在baltika里最常见的落地点——事务管理。传统的JDBC事务需要你手动Connection.setAutoCommit(false)、try里执行SQL、catch里rollback、finally里close代码又长又容易忘。baltika是直接在Service方法上标注Transactional容器就会在方法执行前开启事务、方法正常返回后提交、抛出RuntimeException时回滚。我建议你打开baltika中某个Service类把Transactional注解去掉然后故意让第二句数据库操作报错你会发现第一条数据依然被写进去了这就是事务边界被破坏的直观后果。2.2 分层架构中依赖关系的边界约束baltika的分层依赖方向是单向的Controller - Service - Dao不允许反向依赖。这种约束保证了代码的可测试性和可替换性。比如你在写单元测试时想测试Controller层而不用真正连接数据库只需要给Service做一个Mock对象然后用setter或构造器把Mock注入Controller。baltika源码里Controller通常会通过构造器或Autowired注入Service这个设计就是在为单元测试铺路。为什么有些老项目后期会腐化问题往往出在Cross-reference上Controller里直接写了SQL操作Service里又引用了HttpServletRequestDao里塞了业务判断逻辑。baltika作为一个教学型项目它把这些边界划分得很清晰。你在阅读的时候可以在IDE里用“Find Usages”功能查看每个类的引用关系如果发现Controller直接引用了Dao接口那就说明代码职责开始越界了这是代码审查时一个有效的检查手段。3. 配置与启动流程从web.xml到DispatcherServlet的完整链路很多Spring Boot开发者看到baltika这类传统项目时第一个障碍是不知道请求是怎么进来的。我先从web.xml讲起。Tomcat启动时会读取WEB-INF/web.xmlbaltika在这里声明了一个ServletContext参数通常叫contextConfigLocation指向applicationContext.xml的路径。还有一个核心配置是org.springframework.web.context.ContextLoaderListener它的作用是启动Spring的根容器加载所有业务层、持久层的Bean。这里最容易混淆的是Spring有根容器和子容器两个概念。ContextLoaderListener加载的是根容器里面放Service、Dao等业务组件而DispatcherServlet启动时又会创建一个子容器通常加载spring-mvc.xml里面放Controller、HandlerMapping、ViewResolver等Web组件。子容器能访问父容器的Bean而父容器访问不到子容器的Bean。所以你在baltika里如果把一个Service误放到spring-mvc.xmlController能注入它但ContextLoaderListener加载的根容器里就没有这个Service定时任务或其他非Web组件就找不到它。这个规则搞明白后很多莫名其妙的NoSuchBeanDefinitionException就能瞬间定位。3.1 请求处理的六个关键步骤假设用户在浏览器里访问了baltika系统中某个查询产品的URL完整流程是这样的第一步Tomcat收到HTTP请求根据URL中的ContextPath找到部署的baltika应用。第二步请求进入DispatcherServlet——它是Spring MVC的前端控制器在web.xml中会用url-pattern指定拦截路径常见的配置是“/”表示除了JSP以外的所有请求都进来。第三步DispatcherServlet拿着请求URL去找HandlerMappingbaltika里默认用的就是RequestMappingHandlerMapping它会根据RequestMapping注解里的value值匹配到具体的Controller方法和参数。第四步匹配到方法后DispatcherServlet调用HandlerAdapter去执行这个Java方法。方法参数里的RequestParam、PathVariable、RequestBody等注解就是在这时完成数据绑定的。第五步Controller方法执行完返回一个字符串逻辑视图名或者ModelAndView对象。第六步ViewResolver将逻辑视图名解析为物理JSP路径比如逻辑名“productList”可能对应WEB-INF/views/productList.jspJSP渲染完成后把HTML响应回浏览器。我建议你在这个项目里加一个HandlerInterceptor来观察这个过程比如preHandle方法里打印每个请求的URL和处理时间你会更直观地看到请求在进入Controller之前和离开之后各有一个钩子点。baltika本身往往没有太多拦截器这正好给了你动手扩展的空间。3.2 配置类与XML的混用策略baltika这类项目还有一个特点配置方式可能是XML和JavaConfig混用。比如applicationContext.xml里启用注解驱动用 context:component-scan 扫描Service而spring-mvc.xml里又配置了mvc:annotation-driven /和ViewResolver的Bean。这种混用在维护上会有一定认知成本但同时也展示了Spring Framework的高度灵活性你完全可以在一个项目里老的配置用XML保持不动新的模块用Configuration注解类只要在XML里通过 context:component-scan 扫描到新配置类的包路径即可。动手实践时你可以试着把baltika中某个XML配置改成Bean方法的形式比如把DataSource的配置从一个properties文件读取改成Java代码里读取验证行为是否一致。这个过程会帮助你理解PropertySource和Environment对象的用法也会让你以后面对Spring Boot的application.yml时更加从容——本质上都是把配置外置只是载体不同。4. 实操过程中的坑从编译到部署的排障手记我在跑通baltika时确实踩了几个坑整理成清单分享给你每一条都是实打实踩出来的。4.1 常见问题速查表问题现象根本原因解决办法Tomcat启动报ClassNotFoundException缺少依赖jar包用Maven或Gradle执行compile确认target/classes存在且依赖已下载请求404且控制台无任何日志DispatcherServlet没有拦截到请求检查web.xml的url-pattern以及Controller上的RequestMapping路径是否有拼写错误注入Service时报NoSuchBeanDefinitionException组件扫描包路径设置错误或注解遗漏检查ComponentScan的basePackages、Service类是否有Service注解数据库连接失败Access denied for user数据源配置的账号密码不对检查jdbc.properties里的driver、url、username、passwordJSP页面中文乱码编码不一致确保JSP文件UTF-8、web.xml配置CharacterEncodingFilter、MySQL连接参数加characterEncodingutf8修改了Java代码但热部署不生效IDE没有开启自动编译或Tomcat未配置热部署使用devtools或插件每次修改后重新编译并重启Tomcat4.2 调试工具与断点定位技巧如果你要从源码层面理解baltika我强烈建议学会在关键类里打断点。第一步在DispatcherServlet的doDispatch方法里打断点能看到完整的请求分发流程第二步在自定义Service的实现类上打断点观察事务是否在调用前开启第三步在Dao层的JDBC执行点打断点查看最终生成的SQL和参数绑定情况。这三个断点一打整个请求的脉络就像X光片一样清楚。IDEA还有一个功能叫Conditional Breakpoint断点上可以写条件比如某个参数id等于100时才停下调试复杂业务分支时非常有用。Eclipse也支持类似功能。调试baltika这类源码项目时建议不要用System.out.println去打印效率太低直接断点看调用栈每一步调用关系都会展示出来。4.3 扩展与重构的一点建议如果你想让baltika这个学习项目的含金量再高一层可以从几个方向做扩展第一把某个Dao实现从JdbcTemplate替换成MyBatis理解ORM框架的出现是为了解决什么痛点第二给现有Controller补充单元测试用MockMvc模拟请求和响应断言这会让你更熟悉Spring MVC测试体系的用法第三把某个原本基于XML的配置逐步迁移到JavaConfig体会两种配置模式下Bean生命周期是否完全一致第四给系统加入一个简单的消息推送模块比如用SSE或WebSocket看看Spring对这个场景的支持如何。你在扩展过程中必然会遇到一些看起来“没道理”的错误比如明明代码看起来没问题但编译时Lombok不生效。这里分享一个排查思路先看pom.xml中Lombok的scope是否设为provided再看IDEA的Annotation Processing是否开启。如果都没问题检查一下项目用的JDK版本和Lombok版本的兼容性这是很多人忽略的盲区。我在实践里的心得是处理这类编译期注解问题最有效的方法就是复现最小场景然后把不相关的依赖通通关掉逐个引入来定位冲突。说起阅读源码的方法论我的体会是不要从头到尾一行一行看而是用“入口驱动”的方式。先从web.xml和配置类入手把启动链路摸清然后挑一个最完整的业务功能从Controller入口走到数据库返回整个过程走通后再回头看那些拦截器、监听器、工具类。这个顺序比从第一个类按顺序阅读高效得多而且能让你在短时间内建立起对项目的整体认知。最后再分享一个小细节看baltika这类老派Spring项目时记得多留意它的依赖版本。老版本Spring的注解行为、Java版本要求跟新版差别不小。比如某些老项目里还用Controller注解的value属性来区分Bean名称现在的Spring虽然兼容但团队规范里可能已经不再推荐。你把项目跑通之后可以试试把SpringFramework版本升级一个大版本看看有哪些API被废弃或改名这个过程本身就是一次很好的框架演进学习。我后来带团队时让新人上手Spring经常说的一句话是——先去把一个传统的SpringMVC项目跑起来再回来用Spring Boot你才会真正理解Boot帮你做了什么。baltika就是这样一个值得花一个周末读透的小型参考项目。本文还有配套的精品资源点击获取 baltika源码解析：手把手读懂传统Spring MVC项目骨架
简介《javaweb框架源码-baltika》是一套基于Spring Framework构建的Java Web应用开源工程以“框架源码工程实践”为主线适合具备一定Java基础、希望深入掌握Spring容器、MVC模式及Web开发最佳实践的中高级开发者作为学习样本。压缩包共48个文件整体仅约1.04MB涵盖后端Java源码、前端HTML页面、JavaScript脚本、CSS样式表、XML配置、字体及图片等资源文件类型完整且工程结构清晰适合按Controller、Service、DAO分层展开阅读。当前已有170人学习下载。通过研读该项目可以直观理解Spring依赖注入如何解耦对象关系AOP切面如何统一处理日志与事务Spring MVC如何处理请求映射与视图渲染同时也能借鉴其数据访问、统一异常处理、国际化等模块的组织方式快速提升自身搭建与重构Java Web应用的能力是一份轻量而典型的框架学习资料也可作为团队内部培训或技术分享的参考资料。1. 项目整体脉络先读懂baltika在讲什么第一次打开baltika的源码目录大多数人会被一堆包名和配置文件劝退。但我建议你不要急着看代码而是先回答一个问题如果让你用Spring Framework从零写一个Java Web应用核心骨架应该长什么样baltika这个名字虽然在国外有啤酒品牌的含义但作为开源项目它本质上是一个典型的Spring MVC分层示例把Controller、Service、DAO、实体对象、配置类、视图层之间的协作方式完整地铺开在你面前。从Package结构来看baltika遵循的是常规的按技术分层而不是按业务模块分包。这个设计决策在初期会显得很规整因为每个分包对应一个职责controller层负责接收HTTP请求和参数绑定service层负责事务边界和业务编排dao层负责跟数据库打交道domain或model包放实体和DTOconfig或resources目录放Spring配置、日志配置、JDBC配置。你把这个骨架吃透了以后看任何基于Spring Framework的传统项目都能在五分钟内定位到对应代码的位置。那baltika适合谁我个人觉得它最适合两类人。第一类是刚学完Spring Core和Spring MVC基础语法、但没真正见过一个完整项目如何组织的人你缺的不是某个注解的用法而是“这些注解怎么拼成一个能跑的系统”。第二类是准备Java面试、尤其面试题里频繁出现Spring容器初始化流程、Spring MVC请求映射、事务传播行为这类八股的人你与其死记硬背不如拿baltika的源码配合着看。它有实际业务场景比如产品管理、订单处理之类的模块Spring的IoC、AOP、声明式事务都是在一个真实可运行的环境里生效理解起来比抽象概念快得多。这个项目的第二个价值在于它用的还是传统Spring XML或JavaConfig方式而不是Spring Boot的一堆自动配置。如果你只学过Spring Boot看到baltika的第一反应会很不适应怎么没有application.yml怎么没有内嵌Tomcat这里Tomcat是自己下载安装的web.xml要自己写DispatcherServlet要自己注册。但这恰恰是好事——Spring Boot把太多细节藏起来了而baltika把这些细节又亮出来给你看。了解传统Spring应用的组装方式会让你反过来更理解Spring Boot帮我们省了哪些事。2. 源码核心装配Spring容器到底在项目中做了什么如果你拉下baltika的源码并全局搜索Configuration、ComponentScan、Bean、Autowired这些注解你会发现它们分布在各个package的角落里。初看会觉得“这不是很常规吗”但实际上这些注解组合起来就是在构建Spring IoC容器容器管理着所有对象的生命周期和依赖关系。我先用一个生活化类比解释IoC在baltika里的意义传统方式写代码你new一个Service对象再new一个Dao对象然后手动把Dao塞进Service就像自己去菜市场买菜、洗菜、做菜而Spring容器接管后你只需要声明“我需要一个Service它需要一个Dao”容器就像中央厨房食材、调料统一采购、统一分发你做菜的人不需要关心食材从哪来。2.1 组件扫描与自动装配的协作逻辑baltika通常会在配置类上标注basePackage比如ComponentScan(com.baltika.controller)或者扫描整个根包。Spring启动时会遍历这些包下面所有标注了Controller、Service、Repository、Component的类把它们注册为Bean。这里有一个值得注意的细节Spring容器默认是单例模式也就是说baltika里同一个Service类只会有一个实例在容器里反复使用。如果你的业务代码里不小心在Service里存了可变的成员变量并发请求下就会互相污染这是新手最容易踩的坑。自动装配方面Autowired是按类型注入的。baltika里一个接口只有一个实现类时没问题但如果以后你自己扩展给某个接口写了两个实现类又不指定Qualifier或Resource(namexxx)启动时Spring会直接抛NoUniqueBeanDefinitionException。我在调试baltika时特意试过这种情况控制台报错会明确指出“expected single matching bean but found 2”解决方式也简单要么加Primary标记主实现要么注入时指定Bean名字。这里还要提一下Spring AOP在baltika里最常见的落地点——事务管理。传统的JDBC事务需要你手动Connection.setAutoCommit(false)、try里执行SQL、catch里rollback、finally里close代码又长又容易忘。baltika是直接在Service方法上标注Transactional容器就会在方法执行前开启事务、方法正常返回后提交、抛出RuntimeException时回滚。我建议你打开baltika中某个Service类把Transactional注解去掉然后故意让第二句数据库操作报错你会发现第一条数据依然被写进去了这就是事务边界被破坏的直观后果。2.2 分层架构中依赖关系的边界约束baltika的分层依赖方向是单向的Controller - Service - Dao不允许反向依赖。这种约束保证了代码的可测试性和可替换性。比如你在写单元测试时想测试Controller层而不用真正连接数据库只需要给Service做一个Mock对象然后用setter或构造器把Mock注入Controller。baltika源码里Controller通常会通过构造器或Autowired注入Service这个设计就是在为单元测试铺路。为什么有些老项目后期会腐化问题往往出在Cross-reference上Controller里直接写了SQL操作Service里又引用了HttpServletRequestDao里塞了业务判断逻辑。baltika作为一个教学型项目它把这些边界划分得很清晰。你在阅读的时候可以在IDE里用“Find Usages”功能查看每个类的引用关系如果发现Controller直接引用了Dao接口那就说明代码职责开始越界了这是代码审查时一个有效的检查手段。3. 配置与启动流程从web.xml到DispatcherServlet的完整链路很多Spring Boot开发者看到baltika这类传统项目时第一个障碍是不知道请求是怎么进来的。我先从web.xml讲起。Tomcat启动时会读取WEB-INF/web.xmlbaltika在这里声明了一个ServletContext参数通常叫contextConfigLocation指向applicationContext.xml的路径。还有一个核心配置是org.springframework.web.context.ContextLoaderListener它的作用是启动Spring的根容器加载所有业务层、持久层的Bean。这里最容易混淆的是Spring有根容器和子容器两个概念。ContextLoaderListener加载的是根容器里面放Service、Dao等业务组件而DispatcherServlet启动时又会创建一个子容器通常加载spring-mvc.xml里面放Controller、HandlerMapping、ViewResolver等Web组件。子容器能访问父容器的Bean而父容器访问不到子容器的Bean。所以你在baltika里如果把一个Service误放到spring-mvc.xmlController能注入它但ContextLoaderListener加载的根容器里就没有这个Service定时任务或其他非Web组件就找不到它。这个规则搞明白后很多莫名其妙的NoSuchBeanDefinitionException就能瞬间定位。3.1 请求处理的六个关键步骤假设用户在浏览器里访问了baltika系统中某个查询产品的URL完整流程是这样的第一步Tomcat收到HTTP请求根据URL中的ContextPath找到部署的baltika应用。第二步请求进入DispatcherServlet——它是Spring MVC的前端控制器在web.xml中会用url-pattern指定拦截路径常见的配置是“/”表示除了JSP以外的所有请求都进来。第三步DispatcherServlet拿着请求URL去找HandlerMappingbaltika里默认用的就是RequestMappingHandlerMapping它会根据RequestMapping注解里的value值匹配到具体的Controller方法和参数。第四步匹配到方法后DispatcherServlet调用HandlerAdapter去执行这个Java方法。方法参数里的RequestParam、PathVariable、RequestBody等注解就是在这时完成数据绑定的。第五步Controller方法执行完返回一个字符串逻辑视图名或者ModelAndView对象。第六步ViewResolver将逻辑视图名解析为物理JSP路径比如逻辑名“productList”可能对应WEB-INF/views/productList.jspJSP渲染完成后把HTML响应回浏览器。我建议你在这个项目里加一个HandlerInterceptor来观察这个过程比如preHandle方法里打印每个请求的URL和处理时间你会更直观地看到请求在进入Controller之前和离开之后各有一个钩子点。baltika本身往往没有太多拦截器这正好给了你动手扩展的空间。3.2 配置类与XML的混用策略baltika这类项目还有一个特点配置方式可能是XML和JavaConfig混用。比如applicationContext.xml里启用注解驱动用 context:component-scan 扫描Service而spring-mvc.xml里又配置了mvc:annotation-driven /和ViewResolver的Bean。这种混用在维护上会有一定认知成本但同时也展示了Spring Framework的高度灵活性你完全可以在一个项目里老的配置用XML保持不动新的模块用Configuration注解类只要在XML里通过 context:component-scan 扫描到新配置类的包路径即可。动手实践时你可以试着把baltika中某个XML配置改成Bean方法的形式比如把DataSource的配置从一个properties文件读取改成Java代码里读取验证行为是否一致。这个过程会帮助你理解PropertySource和Environment对象的用法也会让你以后面对Spring Boot的application.yml时更加从容——本质上都是把配置外置只是载体不同。4. 实操过程中的坑从编译到部署的排障手记我在跑通baltika时确实踩了几个坑整理成清单分享给你每一条都是实打实踩出来的。4.1 常见问题速查表问题现象根本原因解决办法Tomcat启动报ClassNotFoundException缺少依赖jar包用Maven或Gradle执行compile确认target/classes存在且依赖已下载请求404且控制台无任何日志DispatcherServlet没有拦截到请求检查web.xml的url-pattern以及Controller上的RequestMapping路径是否有拼写错误注入Service时报NoSuchBeanDefinitionException组件扫描包路径设置错误或注解遗漏检查ComponentScan的basePackages、Service类是否有Service注解数据库连接失败Access denied for user数据源配置的账号密码不对检查jdbc.properties里的driver、url、username、passwordJSP页面中文乱码编码不一致确保JSP文件UTF-8、web.xml配置CharacterEncodingFilter、MySQL连接参数加characterEncodingutf8修改了Java代码但热部署不生效IDE没有开启自动编译或Tomcat未配置热部署使用devtools或插件每次修改后重新编译并重启Tomcat4.2 调试工具与断点定位技巧如果你要从源码层面理解baltika我强烈建议学会在关键类里打断点。第一步在DispatcherServlet的doDispatch方法里打断点能看到完整的请求分发流程第二步在自定义Service的实现类上打断点观察事务是否在调用前开启第三步在Dao层的JDBC执行点打断点查看最终生成的SQL和参数绑定情况。这三个断点一打整个请求的脉络就像X光片一样清楚。IDEA还有一个功能叫Conditional Breakpoint断点上可以写条件比如某个参数id等于100时才停下调试复杂业务分支时非常有用。Eclipse也支持类似功能。调试baltika这类源码项目时建议不要用System.out.println去打印效率太低直接断点看调用栈每一步调用关系都会展示出来。4.3 扩展与重构的一点建议如果你想让baltika这个学习项目的含金量再高一层可以从几个方向做扩展第一把某个Dao实现从JdbcTemplate替换成MyBatis理解ORM框架的出现是为了解决什么痛点第二给现有Controller补充单元测试用MockMvc模拟请求和响应断言这会让你更熟悉Spring MVC测试体系的用法第三把某个原本基于XML的配置逐步迁移到JavaConfig体会两种配置模式下Bean生命周期是否完全一致第四给系统加入一个简单的消息推送模块比如用SSE或WebSocket看看Spring对这个场景的支持如何。你在扩展过程中必然会遇到一些看起来“没道理”的错误比如明明代码看起来没问题但编译时Lombok不生效。这里分享一个排查思路先看pom.xml中Lombok的scope是否设为provided再看IDEA的Annotation Processing是否开启。如果都没问题检查一下项目用的JDK版本和Lombok版本的兼容性这是很多人忽略的盲区。我在实践里的心得是处理这类编译期注解问题最有效的方法就是复现最小场景然后把不相关的依赖通通关掉逐个引入来定位冲突。说起阅读源码的方法论我的体会是不要从头到尾一行一行看而是用“入口驱动”的方式。先从web.xml和配置类入手把启动链路摸清然后挑一个最完整的业务功能从Controller入口走到数据库返回整个过程走通后再回头看那些拦截器、监听器、工具类。这个顺序比从第一个类按顺序阅读高效得多而且能让你在短时间内建立起对项目的整体认知。最后再分享一个小细节看baltika这类老派Spring项目时记得多留意它的依赖版本。老版本Spring的注解行为、Java版本要求跟新版差别不小。比如某些老项目里还用Controller注解的value属性来区分Bean名称现在的Spring虽然兼容但团队规范里可能已经不再推荐。你把项目跑通之后可以试试把SpringFramework版本升级一个大版本看看有哪些API被废弃或改名这个过程本身就是一次很好的框架演进学习。我后来带团队时让新人上手Spring经常说的一句话是——先去把一个传统的SpringMVC项目跑起来再回来用Spring Boot你才会真正理解Boot帮你做了什么。baltika就是这样一个值得花一个周末读透的小型参考项目。本文还有配套的精品资源点击获取