SSM健身房管理系统开发实战：从三层架构到前后端部署全流程解析

简介本资源是一套基于SSMSpringSpringMVCMyBatis框架开发的健身房管理系统完整源码面向计算机、电子信息工程等专业的本科生及毕业设计/课程设计学习者解决健身场馆会员管理、课程预约、教练排班、消费统计等核心业务场景的系统实现问题。压缩包共668个文件涵盖160个Java后端逻辑类、114个Vue前端组件、44个JS交互脚本、26个XML配置文件及52张JPG运营图片等全面支撑B/S架构下的前后端分离开发模式包体大小21.14MB结构清晰含SQL初始化脚本、Tomcat部署批处理bat、Vue路由与状态管理模块便于快速导入IDEA或Eclipse运行调试。所有代码经严格测试适配JDK1.8、MySQL 5.7与Tomcat 8.0/9.0环境配套SQL文件可一键建库建表显著降低部署门槛助力高效完成高分毕设或期末大作业。 做毕业设计或者项目实战的时候健身房管理系统几乎是SSM技术栈里最经典的选题之一。它的业务边界清楚、角色划分明确、数据关系不复杂但又足够练手非常适合用来把Spring、SpringMVC、MyBatis这三个框架真正串起来理解。这篇文章我按自己实际开发这类系统的经验把从设计到部署的完整链路拆开讲一遍包括数据库怎么建、业务层怎么组织、权限怎么控制、Vue3怎么对接以及我踩过的那些坑。不管你是准备答辩还是想拿这套代码当脚手架二次开发这篇文章应该都能帮到你。1. 项目整体设计思路与技术选型1.1 为什么选SSM而不是Spring Boot这个问题基本每次答辩都会被老师问到。很多同学做项目已经习惯Spring Boot一键启动但在健身房管理系统这个场景里我更推荐用传统的SSM结构理由有三个。第一SSM能让你把请求处理的完整链路看得一清二楚。Spring Boot把Tomcat、DispatcherServlet、自动配置全部藏起来了你敲一个SpringBootApplication就启动但底层发生了什么你根本没有感知。而SSM要求你手动在web.xml里配Listener、配DispatcherServlet、配编码过滤器这一套下来你对Web应用的运行机制理解会扎实很多。面试的时候被问“一个HTTP请求从进来到返回经历了什么”做过SSM的人能答到Servlet、HandlerMapping、Controller、ViewResolver这个深度而只用过Spring Boot的人往往说不出DispatcherServlet在哪配的。第二SSM的代码结构更适合课程设计这种需要“看得见的封装”的场景。SSM天然强制你写三层架构Controller只做参数接收和响应封装Service只写业务逻辑Mapper只做SQL交互。每一层职责极其清晰文档和答辩PPT都特别好写。老师看到的是规规矩矩的代码分层而不是一个Controller里塞了五百行业务代码的“大泥球”。第三SSM的排错难度反而比Spring Boot低。Spring Boot启动失败的时候报错栈往往被自动配置的日志淹没新手根本不知道是谁导致的。而SSM启动流程是显式的Spring容器加载失败、MyBatis的Mapper扫描失败、SpringMVC配置出错每一步都对应明确的配置文件你只要按加载顺序排查就行。当然Spring Boot在真实企业中确实是主流这不冲突。我的建议是用SSM学习原理用Spring Boot做实战两者能力是互通的SSM打底反而让你的后端基本功更扎实。1.2 系统功能模块与角色划分健身房管理系统的业务本质上就是围绕“人、卡、课、钱”四个字展开的。人指的是会员和教练卡指的是会员卡类型与状态课指的是团课和私教课钱指的是办卡、续费、课程消费带来的流水。基于这个理解我把系统划分成三种角色。会员端的核心操作是注册登录、查看个人信息、查看课程表、预约私教课和团课、查看自己的卡状态和消费记录。这个端一定要做得轻不要让会员去管理什么器材库存那不是会员该操心的事。教练端的核心操作是查看自己的排课表、查看被预约的课程列表、确认或取消课程、查看自己名下的会员上课记录。教练不应该有修改会员卡种和金额的权限这个约束必须在后端做不能只靠前端隐藏按钮。管理员端是整个系统的重头戏包含会员管理增删改查、办卡续费、卡到期提醒、教练管理入职、离职、排班、课程管理新增课程、设置课时费、分团课和私教课、器材管理器械列表、报修状态、收入统计按日按月查看办卡收入和课程收入、公告管理。这里有一个设计的关键点角色权限不能写死在页面跳转逻辑里而是要用拦截器配合Session或Token统一做。我的做法是在后端定义拦截器拦截/admin和/coach开头的URL然后从Session里取出当前用户身份判断角色是否匹配不匹配直接return 403页面。前端菜单只是用来隐藏入口的真正的安全防线永远在后端。1.3 数据库表结构设计数据库设计是这套系统能不能稳定运行的地基。我在设计时一共建了十张表核心的七张表我直接给出结构说明。会员表member是系统的核心主体字段包括id、姓名、手机号、密码、性别、年龄、会员卡类型、卡到期时间、注册时间。手机号建议加唯一索引因为登录用的是手机号。密码存的是MD5加密后的值千万不要明文存密码答辩时老师一定会查这一点。教练表coach字段包括id、姓名、手机号、专长方向比如增肌、减脂、康复、简介、入职时间。课程表course字段包括id、课程名称、课程类型团课或私教课、教练ID、上课时间、课时费、可预约人数、已预约人数。这里需要注意课程表要同时关联教练和每节课的容量这是后面做预约冲突校验的关键。预约表appointment是整个系统中业务逻辑最复杂的一张表字段包括id、会员ID、课程ID、预约时间、状态已预约、已上课、已取消、已过期。预约表一定要加唯一约束比如UNIQUE KEY(member_id, course_id)防止同一个会员重复预约同一节课这属于数据库层的最后一道保险。器材表equipment字段包括id、器材名称、位置、购置日期、状态正常、维修中、报废。收入表income字段包括id、收入类型办卡收入、课程收入、金额、关联订单号、创建时间。这张表是为了管理员端报表统计建议所有涉及钱的操作都往这张表里写一笔流水不要直接改会员卡字段就算完否则月底对账根本对不上。还有一个很容易疏忽的点是公告表notice字段很简单就是id、标题、内容、发布时间。但千万别省掉这张表因为管理员发布公告是健身房系统的常见功能而且它能验证你JSP或者前端页面的数据渲染能力。建表时还要统一字段命名规范比如所有表的主键都叫id所有外键关联字段用xxx_id时间字段统一用datetime类型。这个习惯会让你写MyBatis映射时省掉很多不必要的字段别名。2. 核心功能与实操要点2.1 搭建项目骨架我用的开发环境是JDK 1.8IDEA 2022Tomcat 8.5MySQL 5.7Maven 3.6。这套组合是SSM项目的黄金搭配兼容性最好教程外的坑也最少。你如果用Tomcat 10会遇到javax到jakarta的包名迁移问题很多网上教程直接失效我建议不要碰Tomcat 10。创建Maven工程时packaging选择war包然后手动补上src/main/java、src/main/resources、src/test/java这些目录。依赖方面核心是spring-webmvc、mybatis、mybatis-spring、mysql-connector-java、druid连接池、jackson-databindJSON转换、jstl和taglibs。有一个细节如果你的JDK版本是9以上还需要额外引入javax.annotation-api否则Resource注解会报错。项目包结构我建议这样分com.gym ├── controller # 控制层 ├── service # 业务接口 │ └── impl # 业务实现 ├── mapper # MyBatis接口 ├── pojo # 实体类 │ ├── entity # 数据库实体 │ └── vo # 视图对象 ├── interceptor # 拦截器 ├── common # 统一返回结果、常量类 └── util # 工具类这种分包方式的优势在于每一层只依赖相邻下层不会出现Controller直接调用Mapper的情况后面写业务的时候你就能体会到这种约束的价值。2.2 SSM整合的核心配置SSM的整合配置是整个项目技术含量最高的部分我按加载顺序拆开讲。首先是web.xml这是整个应用的入口要配置三样东西Spring的ContextLoaderListener、SpringMVC的DispatcherServlet、字符编码过滤器。编码过滤器必须放在所有过滤器的最前面位置放错了中文就乱码。然后是Spring的配置文件applicationContext.xml它负责扫描Service和Mapper配置数据源、事务管理器、SqlSessionFactory。这里最关键的是SqlSessionFactory的配置要把mapper-locations指向XML文件夹把typeAliasesPackage指向实体类包同时开启驼峰映射这样数据库下划线字段名可以自动映射到Java驼峰属性。再就是springmvc.xml它扫描Controller配置注解驱动、视图解析器、静态资源放行同时也要配置拦截器。视图解析器的prefix和suffix设置为/WEB-INF/jsp/和.jsp这样Controller返回字符串时自动拼接路径一个典型的例子是管理员登录成功后返回admin/index真实路径就是/WEB-INF/jsp/admin/index.jsp。MyBatis的XML文件里有一个非常容易踩的坑查询结果的列名和实体属性对不上。如果数据库字段是member_name实体属性是name即使开启了驼峰映射也救不了你因为映射规则是member_name映射到memberName中间存在下划线才能转换。所以要么建表时字段不加下划线要么SQL里给字段起别名AS userName我实际开发时倾向于在SQL中写清楚别名毕竟SQL是给人读的别名写明白之后维护成本最低。2.3 会员办卡与续费的业务实现会员办卡是我个人认为这套系统里最能体现业务逻辑的一段代码。办卡操作不是简单insert一条数据而是一个典型的事务场景涉及三个操作生成会员卡订单、更新会员表卡状态和到期时间、在收入表写入流水。这三个操作必须在同一个事务里完成。我用的Spring声明式事务在Service实现类的办卡方法上加上Transactional注解。如果你不用注解而是手动在代码里try-catch然后自己commit一旦第三个操作抛异常前面两个操作已经提交了数据就残了。事务里有一个关键点不要把异常自己吃掉。很多同学在ServiceImpl里习惯写try-catch把异常打日志然后返回null这样Spring根本感知不到异常事务不会回滚。正确做法是方法上不写try-catch直接让RuntimeException往外抛由Spring的TransactionInterceptor统一拦截回滚。如果你确实需要感知异常可以catch住之后用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()手动标记回滚但这个方式比较底层能不用尽量不用。续费业务还有一个细节是到期时间的计算。会员卡有效期的计算逻辑要区分新办和续费新办会员从当天开始加时长续费会员要从原到期时间之后开始加时长如果卡已经过期了则从当天开始算。这个判断在写代码时要注意不然很容易出现会员卡还没到期续费后时间反而被覆盖的bug。我核心Service方法的代码大概是这样的Override Transactional public Result createCardOrder(CardOrderDTO dto) { Member member memberMapper.selectById(dto.getMemberId()); if (member null) { return Result.error(会员不存在); } // 计算新到期时间 LocalDate startDate LocalDate.now(); if (member.getExpireDate() ! null member.getExpireDate().isAfter(startDate)) { startDate member.getExpireDate(); } LocalDate newExpire startDate.plusMonths(dto.getMonths()); // 更新会员卡信息 memberMapper.updateExpireDate(dto.getMemberId(), newExpire); // 生成收入流水 Income income new Income(); income.setType(Income.TYPE_CARD); income.setOrderNo(UUID.randomUUID().toString().replace(-, )); income.setAmount(dto.getAmount()); income.setCreateTime(new Date()); incomeMapper.insert(income); return Result.success(办卡成功, newExpire); }代码里有一个细节用LocalDate而不是java.util.Date来做日期运算因为LocalDate的plusMonths方法天然处理了跨月和平闰年问题如果手写Calendar计算跨2月容易翻车。2.4 课程预约与冲突校验课程预约的逻辑复杂度比办卡更高因为它涉及三个维度的校验会员是否有资格预约会员卡是否有效、课程是否还有名额已预约人数是否小于可预约人数、是否重复预约同一人同一节课只能预约一次。第一个校验很简单查询会员的卡到期时间是否在明天之后过期了直接返回“会员卡已过期请续费后预约”。第二个校验用课程的已预约人数和可预约人数比较这里有一个并发问题要注意两个会员同时点击预约可能恰好预约到最后一个名额两人都通过了已预约人数的校验。解决方式有两种一种是乐观锁思想在预约SQL里加上where reserved_count max_count这样的条件如果影响行数为0说明预约失败另一种是悲观锁在业务方法上加SELECT ... FOR UPDATE锁住课程行。课程设计阶段推荐第一种因为它不锁表性能好且逻辑直观。第三个校验就是查预约表判断member_id和course_id组合是否已存在数据库的唯一约束兜底。我把这段逻辑写在Service里为了直观也为了事务保证数据一致性。预约成功之后还要同步增加课程的已预约人数这个操作必须和插入预约记录在同一个事务里完成。我最初实现时把两步拆成了两个方法结果出现过插入预约记录成功但名额没减少的bug后来改成在一个Service事务方法内调用两个Mapper方法才稳定。2.5 角色权限控制与拦截器实现权限控制我在前面提到过这里给出具体的实现方案。我的拦截器配置在springmvc.xml里拦截所有请求然后根据URL前缀做角色判断。public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user request.getSession().getAttribute(loginUser); String uri request.getRequestURI(); if (uri.startsWith(/admin) || uri.startsWith(/coach)) { if (user null) { response.sendRedirect(request.getContextPath() /login); return false; } String role (String) request.getSession().getAttribute(role); if (uri.startsWith(/admin) !admin.equals(role)) { response.setStatus(403); return false; } if (uri.startsWith(/coach) !coach.equals(role) !admin.equals(role)) { response.setStatus(403); return false; } } return true; } }这里有一个容易忽略的细节管理员往往也需要访问教练的接口比如管理员要查看教练的排课情况所以教练URL的拦截条件应该是允许admin访问的。如果你把权限做成互斥的反而会在实际使用中处处碰壁。前端菜单我通常通过JSP的c:if标签判断session里的role属性来动态显示或者在Vue方案里通过接口返回的role字段控制菜单渲染。注意这只是体验优化不是安全手段因为前端代码可以被绕过真正防护靠的是后端拦截器。3. 前后端数据交互与Vue3对接3.1 统一JSON返回格式传统SSM项目常常直接在Controller里返回ModelAndView渲染JSP页面但如果你希望前端用Vue3来写那Controller就需要改成返回JSON数据的接口风格。我强烈建议在项目一开始就定义统一的结果封装类而不是让每个方法返回不一样的Map或Object。我的Result类是这么设计的public class Result { private Integer code; // 200成功 500失败 private String message; // 提示信息 private Object data; // 业务数据 // getter/setter... }对应的Controller方法用ResponseBody或者RestController注解标记方法直接返回Result对象SpringMVC通过MappingJackson2HttpMessageConverter自动序列化成JSON。如果你是传统方式Controller的Controller注解忘记加ResponseBody方法就会返回默认的视图名然后Tomcat报404找不到JSP这个坑很典型。统一返回格式带来的好处是前后端协作时数据结构永远是{code, message, data}三件套前端ajax拦截器只需要判断code是否为200非200统一弹提示不用每个接口单独写错误处理。3.2 Vue3项目对接SSM后端Vue3和SSM对接的核心问题是跨域。前后端分离部署时Vue跑在5173端口后端跑在8080端口浏览器会拦截跨域请求。解决跨域有好几种方式我在实际项目中用的最顺的是后端配置CORS过滤器。Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedMethod(*); config.addAllowedHeader(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }注意这里addAllowedOrigin(*)和setAllowCredentials(true)不能同时用否则启动会报错。要用addAllowedOriginPattern(*)代替。然后前端用axios调用后端接口。因为Controller接收JSON复杂的对象参数时比如办卡时传一个CardOrderDTO对象需要加上RequestBody注解前端发起请求时必须设置Content-Type: application/json并且请求体是JSON字符串而不是FormData格式。这个不匹配是前后端联调最常见的报错SpringMVC会抛出HttpMessageNotReadableException。如果用Vite做开发服务器还可以用proxy配置代理来解决跨域问题在vite.config.js里export default defineConfig({ server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })这样前端请求/api/member/login时Vite开发服务器会转发到后端的/api/member/login浏览器看到的请求是同源的也就没有跨域问题了。生产环境上线时用Nginx做反向代理把/api路径转发到后端Tomcat逻辑跟Vite proxy是一致的。我建议自己的项目从开发阶段就统一用/api前缀这样上线时配置Nginx不用改前端代码。3.3 日期时间字段的处理前端Vue和后端Java之间的时间格式问题也值得单独说。数据库DATETIME类型对应Java的Date类型Jackson序列化后默认返回一个时间戳字符串Vue组件里显示出来就是一串数字体验很差。解决方式有两种。一种是在VO实体类的日期字段上加JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8)注解Jackson序列化时就会输出格式化好的字符串。另一种是在jackson配置里全局设置日期格式。我自己项目中用的是全局配置因为不需要为某个字段单独调整格式写法是在springmvc.xml里配置消息转换器。这里有一个隐患如果你只配置了输出的日期格式没有配置timezone那么时间会比实际少8个小时。因为Jackson默认用UTC时区序列化Date而中国在东八区。踩过一次这个坑之后我现在不管是用注解还是全局配置timezone必定写成GMT8。4. 部署上线与常见问题排查4.1 本地环境搭建与部署这套系统我推荐直接用IDEA运行先配置Tomcat。在IDEA的Run Configuration里添加Tomcat ServerLocal模式然后在Deployment选项卡添加打包出来的war包。这里有一个很多人不会注意的坑Application context默认是/项目名_war_exploded这会导致前端资源路径特别长。建议手动改成/这样前端请求就是http://localhost:8080/login清爽很多。数据库初始化方面我习惯在项目里放一个sql/init.sql文件包含建库、建表、插入默认管理员数据的全部SQL。每次部署新环境时执行一遍这个脚本就能跑起来不用手动一条条执行建表语句。默认管理员密码建议在SQL里插一段MD5加密后的值不要明文写123456。我用MD5(admin123)的密文插进去然后在登录时也做MD5再比对。项目的打包方式在IDEA右侧Maven面板里双击package如果没有配置跳过测试记得先确认测试类不会因为访问数据库失败导致整个打包失败。我一般在pom.xml里配置了maven-surefire-plugin的skipTeststrue/skipTests因为课程设计项目很少写单元测试打包时不跑测试更省事。打包好之后会得到一个war包。本地调试建议不单独部署外部Tomcat直接用IDEA集成Tomcat。但如果你需要给老师演示可以把war包扔进Tomcat的webapps目录启动Tomcat自动解压发布。注意war包的文件名就是访问路径比如文件名是gym.war访问地址就是http://localhost:8080/gym/如果想根路径访问就要把war包改名为ROOT.war再丢进去。4.2 常见问题速查表这里我整理了开发这套系统时最容易遇到的几个问题基本覆盖了SSM项目的典型故障场景。问题现象根本原因解决方案启动Tomcat直接报ClassNotFound依赖缺失或版本冲突检查pom.xml有没有引入对应的jar包刷新Maven重新导入启动成功但访问任何接口都404DispatcherServlet拦截路径配置错误web.xml里servlet-mapping的url-pattern检查是否为/并且Controller类通过ComponentScan扫描到页面报NoSuchBeanDefinitionSpring扫描包路径不对检查applicationContext.xml的component-scan是否覆盖service和mapper接口包查询返回字段全是null驼峰映射未开启或列名与属性名不一致mybatis-config.xml开启mapUnderscoreToCamelCase或者SQL起别名登录接口报错密码不一致登录时没有做MD5加密在Service里对输入的密码先MD5再和数据库比对提交表单中文乱码编码过滤器位置不对或没有配置web.xml的CharacterEncodingFilter必须放在最前面forceEncoding设为true前端跨域请求失败CORS未配置或配置不合法添加CorsFilter注意allowedOriginPattern和allowCredentials的配合前端传JSON后台说参数缺失Controller方法没加RequestBody使用RequestBody接收请求体JSON并确认Content-Type为application/json办卡成功后收入表没有记录事务没有生效或异常被catch检查ServiceImpl方法是否有Transactional确认没有try-catch吞异常预约时查到的课程已预约人数不同步删除了预约记录却没有更新课程名额删除预约的Service方法里同时更新课程表的reserved_count字段这张表在答辩时价值极高。老师问你有没有遇到过什么bug你从中抽两三个讲清楚原因和解决过程比罗列自己实现了多少功能更能打动他。4.3 几个值得避开的坑我再分享几个开发过程中容易踩的深坑这些都是我在实际项目里花了很多时间才搞明白的。第一个坑是MySQL连接串的编码参数。jdbc的url一定要带useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai。如果缺了serverTimezone高版本MySQL驱动连接时会报时区错误如果缺了characterEncoding即使后端有编码过滤器数据存到库里也可能是乱码。这一串参数建议直接固定复制使用。第二个坑是关于MyBatis的resultType和resultMap。当一个查询结果包含了多张表的字段时比如查询预约列表同时要显示会员姓名和课程名称千万不要用resultType去接一个不存在的Vo类然后期望自动映射所有字段。MyBatis对resultType做的是自动映射但前提是列名能匹配到Vo的属性。跨表查询时我建议显式写resultMap把列和属性对应关系写清楚。这个避免了很多隐藏bug因为你一旦用了resultTypeMyBatis并不会报错它只是默默的把匹配不到的字段置为null你查出来明明有数据但对象里就是拿不到排查起来特别费劲。第三个坑是Lombok的使用。虽然Lombok能省掉一堆getter/setter代码但我和多个同学合作项目时发现Lombok版本和JDK版本不匹配会导致编译期报错。如果你用的JDK 8Lombok 1.18.20以后的版本基本没问题。但如果你在更高版本JDK下编Lombok可能完全不工作编译器报找不到getter方法。如果项目对稳定性要求高可以不用LombokIDEA的Generate getter/setter快捷键也不慢。第四个坑是文件上传功能的编码与大小限制。如果健身房系统里需要会员上传头像或教练上传资质照片要在springmvc.xml里配置MultipartResolver并且注意Tomcat默认请求体大小限制是2MB超过这个大小会上传失败。需要手动扩展Tomcat的maxSwallowSize或者在Connector里设置maxPostSize。我实际测试时用一张5MB的照片直接报错排查了半天才发现是Tomcat配置的锅。4.4 答辩复盘与亮点提炼最后聊一下这套系统在答辩时怎样呈现才最有竞争力。很多同学做完项目就结束了答辩时只会说“我做了增删改查”这显然不够。至少要能给老师讲清楚三个亮点事务在哪里用了、权限控制怎么做、数据表为什么这么设计。事务的亮点就在办卡和预约这两个场景。拿预约举例你可以在演示时临时把课程可预约人数改成1然后开两个浏览器模拟两个会员同时点击预约一个成功后另一个提示资源不足这个操作直观展示了并发控制和事务的作用。此时你趁机说明自己用的是乐观锁思想老师一般会连续追问几个问题比如“如果不用乐观锁会怎么样”你回答“会出现超卖就像火车票卖超了一样”他基本就满意了。权限控制的亮点在拦截器上。你可以现场演示一个未登录用户直接访问/admin/memberList的URL被重定向到登录页的过程然后说明后端对URL做了角色匹配前端菜单只是辅助。这比单纯说“我做了登录功能”要高级很多。数据表设计方面你可以主动说明为什么要把收入单独建表而不是直接改会员表的字段。因为会员卡充值是一个金额流转行为需要留痕和追溯有表才能做统计报表没有表就只能现算现用数据容易错乱。这个设计思路的表达能让老师感觉到你是真的有业务考量而不是背教程。5. 这个项目后续可以怎么扩展健身房管理系统虽然看起来是个经典的练手项目但如果想让它成为简历上的亮点还有几个很好的扩展方向。一个是引入Redis缓存课程信息和会员信息减少数据库压力另一个是把预约模块做成基于定时任务的状态自动更新比如课程开始后自动把预约状态改成已完成还可以把SSM后端改造成更贴近企业的Spring Boot架构同时保留前端Vue3不变这样既能展示你对传统SSM的理解又能体现技术迁移能力。在我个人实际开发经历中这个项目前后迭代了三版第一版纯JSP第二版加了事务和拦截器第三版引入了Vue3前后端分离和统一返回格式。每一版重构都让我对Web开发的理解更深一层尤其是第三版重构时踩的那些坑比如跨域、日期格式化、统一异常处理都是真实工作中每天都在面对的问题。如果你现在正在做这个系统我的建议是先把SSM的配置吃透再回头看Spring Boot你会发现Spring Boot的每一个“自动配置”其实都能对应到SSM里那些繁琐的XML配置项那时候你对框架的理解才是真正通了。本文还有配套的精品资源点击获取