1. 项目定位：一套能被“真正跑起来”的Java Web练手系统
先说说这套系统的定位。基于SSM（Spring + Spring MVC + MyBatis）的酒店客房预定管理系统，是一个非常典型的Java Web全栈项目。标题里几个关键词值得拆开看：SSM说明后端用的是经典三层框架组合，Vue说明前端是现代化SPA，前后端分离说明这不是传统的JSP套模板开发，而是真正符合企业开发习惯的分离架构。再加上源码、文档、调试这几个字眼，这套内容的目标用户非常明确——正在学Java Web、准备毕业设计、或者想通过一个完整项目把SSM和Vue串起来的人。
我做过的类似项目不少，带过的人也很多，说实话这类系统的业务复杂度刚好卡在一个很舒服的位置：比图书管理、学生选课这类单表CRUD有挑战性，又不像电商秒杀、分布式支付那样需要微服务、消息队列等大规模架构。酒店客房预订涉及房间类型管理、房态实时变化、订单状态流转、价格计算、入住退房业务，这些场景足够支撑你理解“一个真实业务系统是怎么被设计出来的”，又不会让初学者被中间件和分布式问题淹没。
我拿它走过的完整链路是：从数据库设计出发，到SSM框架整合，到RESTful API开发，再到Vue前端页面联调，最后是部署调试。这套顺序是合理的，但也是很多人容易搞反的。多数人拿着源码第一件事是打开ApplicationContext.xml看配置，然后导入数据库、启动Tomcat，报一堆错之后就开始怀疑人生。我的建议是先把业务ER图看懂，再去碰代码。原因很简单——配置错误是机械问题，业务理解错误才是系统性灾难，后者会让你越改越乱。
这套系统的适用人群我再说细一点：一是准备毕业设计的学生，它的技术栈完全匹配大多数高校的Java课程要求；二是自学Java想找一份入门级开发工作的人，用它来把SSM、Vue、RESTful API、Maven、Git这些技能点串成一条线；三是想快速上手“如何把一套源码在本地跑起来”的读者。如果你是后面这类人，我会在文章后半部分专门讲调试和踩坑经验，那部分是我实际跑通这个项目后的第一手总结。 直接说结论：这套系统的技术深度不算高，但它背后涉及的问题面非常典型——Spring IoC如何管理三层对象、MyBatis如何和业务解耦、Vue如何通过Axios走后端接口、跨域问题怎么解决、登录状态如何保持，这些全是实际面试和工作中躲不开的问题。把这套项目嚼透了，你的收获绝对不只是“我会写一个酒店预订系统”，而是“我理解了一个前后端分离项目的完整生命周期”。
2. SSM整合的底层逻辑：为什么这个组合能成为经典
2.1 为什么用SSM而不是直接上Spring Boot
很多刚接触这套项目的朋友会问：现在企业都用Spring Boot了，为什么还要折腾SSM？这个问题我在很多场合回答过，核心原因是学习价值。
SSM强调的是“手动装配”的过程。用Spring Boot时，很多东西都被自动配置隐藏了，你并不知道它底层做了什么；用SSM时，你要自己写web.xml、自己配置DispatcherServlet、自己扫描Mapper接口、自己管理事务切面。这个过程非常痛苦，但痛苦恰恰是学习的意义。你亲手把这些繁琐配置一项项做完之后，再去看Spring Boot的自动配置，才会真正理解它帮你省掉了什么。
另外，毕业设计评审和企业面试里，SSM的痕迹依然大量存在。很多公司的老项目还在用SSM架构维护，面试官问的也经常是这类问题：“Spring MVC的请求流转过程是怎样的”“MyBatis的一级缓存和二级缓存区别是什么”。你只有亲手搭过这套框架，才能对这些底层问题有自己的理解，而不是背面试题答案。
2.2 三层架构在这个项目中的真实落点
SSM项目的经典分层是Controller层、Service层、Mapper层。在这个酒店客房预订系统里，这套分层的逻辑特别清晰。
Controller层不写任何业务逻辑，只做参数接收、调用Service、返回结果。比如提交一个预订请求，Controller要做的事情是接收前端传来的入住日期、离店日期、房型ID、入住人数，然后封装成一个DTO对象，交给Service层处理。它不关心这个预订是否会导致房间超卖，也不关心价格怎么算，这些全是Service层的职责。
Service层是业务逻辑的核心。在这个项目里，预订房间的业务包含几个关键步骤：验证房间在指定日期内是否有空房、计算总价、创建订单、更新房态、把订单信息存库。这几个步骤要么全部成功、要么全部失败，所以Service层必须加事务管理。这就是SSM中事务切面的意义——保证数据一致性。如果你写过只操作单张表的代码，可能不太能理解事务的必要性；但在这个项目里，你预订一间房要同时修改房间状态表和订单表，一旦中途出错，数据就会不一致，这时候事务的价值就体现出来了。
Mapper层负责和数据库交互。MyBatis在这里起的作用是把Java方法和SQL语句映射起来。比如查询可用房间，你要写一条动态SQL，根据不同条件（入住日期、人数、房型）拼接不同的查询语句，MyBatis的XML配置就是干这个的。这比JDBC手动拼SQL、手动处理结果集要优雅得多，也比Hibernate的全自动映射更容易控制复杂查询。
2.3 关键配置的细节：Maven依赖和Spring配置文件的协作
一套SSM项目能跑起来，Maven依赖和Spring配置文件的配合是基础。很多新手在这一步就卡住了，最常见的问题是依赖版本冲突。
以这个项目为例，你需要重点注意这几个依赖的版本匹配：
- Spring核心库（spring-context、spring-webmvc、spring-jdbc、spring-tx）必须使用同一版本，建议5.x系列。因为Spring的各个模块之间有内部调用，版本不一致容易出现NoSuchMethodError这类诡异错误。
- MyBatis和mybatis-spring的版本要适配。mybatis-spring 2.x对应MyBatis 3.5.x，如果用旧版mybatis-spring去对接新版本MyBatis，会出现MapperFactoryBean无法创建的问题。
- 数据库驱动版本要和你的MySQL版本匹配。MySQL 8.x必须使用mysql-connector-java 8.x，同时驱动类是com.mysql.cj.jdbc.Driver，不是旧版的com.mysql.jdbc.Driver，而且连接URL需要加serverTimezone=Asia/Shanghai参数，否则会报时区错误。
提示：新手最容易忽略的是JDK版本对CGLIB代理和动态代理的影响。如果你用JDK 17跑SSM项目，很多反射相关的操作会遇到模块化限制，建议使用JDK 8或JDK 11。
Spring配置文件的组织方式，我推荐拆成三个文件：applicationContext.xml负责非Web层（Service、Mapper、DataSource、事务）、spring-mvc.xml负责Web层（Controller、视图解析器、静态资源、拦截器）、mybatis-config.xml负责MyBatis全局配置（驼峰映射、日志、类型别名）。这样分开的好处是职责清晰，排查问题时能快速定位。
2.4 事务管理的配置教训
我在调试这个项目的过程中，遇到过Service层方法执行到一半，数据库里房间状态已更新但订单没插入的情况。这就是典型的事务没生效。
原因常见有两种：一是配置了事务切面，但切点表达式写错了，导致Service层方法没有被拦截；二是数据库表用了MyISAM引擎，不支持事务。排查方法很简单：先看数据库引擎，再看事务配置。
事务配置的核心是这三行：
- 事务管理器，绑定数据源
- 事务通知，声明事务传播行为（REQUIRED是默认，表示当前没有事务就新建一个，有就加入现有事务）
- 切点表达式，定位到service包下所有public方法
有一个细节容易被忽略：事务切面的拦截目标是接口方法还是实现类方法。如果你用了JDK动态代理，事务注解或切点必须基于接口；如果你用了CGLIB代理，可以基于实现类。SSM中默认使用JDK动态代理，所以Service层的接口和实现类必须严格分离，方法签名要保持一致，否则事务会静默失效。
3. 前后端分离的落地：Vue前端与Java后端的两种“对话方式”
3.1 RESTful API设计：酒店预订系统的接口划分
前后端分离的第一个关键问题是接口设计。这套系统的API设计可以直接按资源来划分，这也是RESTful风格的核心思想。
用户模块：POST /user/register（注册）、POST /user/login（登录）、GET /user/info（获取当前用户信息）、PUT /user/info（修改个人信息）。
房间模块：GET /room/list（按条件查询可用房间）、GET /room/detail/{id}（查看房间详情）。
订单模块：POST /order/create（提交预订）、GET /order/list（查询我的订单）、PUT /order/cancel/{id}（取消预订）、POST /order/checkin（入住登记）、POST /order/checkout（退房结算）。
管理端模块：房间管理、房型管理、订单审核、客户管理、数据统计。
这套接口设计的核心原则是：每个接口只做一件事，参数尽量通过JSON传递，返回结果使用统一的结构。统一返回结构特别重要，我见过太多项目前后端联调时因为返回格式不统一而互相扯皮。
项目里一般会定义一个Result类，包含code、message、data三个字段。前端只要判断code是不是200就知道请求是否成功，不需要为每个接口单独解析数据结构。这种设计在团队协作时尤其重要，文档写起来也轻松，对接成本大幅降低。
3.2 Axios请求封装与拦截器：让每个页面少写一堆重复代码
Vue项目中使用Axios发送请求，最忌讳的做法是每个组件里直接调用this.$http.post，然后各自处理错误弹窗、各自判断登录态。正确的做法是封装一个统一的request模块。
我常用axios.create创建一个实例，设置baseURL（比如http://localhost:8080）、超时时间（10秒或15秒），然后通过请求拦截器统一在header中追加token，通过响应拦截器统一处理错误码。
这个项目中，响应拦截器的逻辑必须包含两个特殊处理：一是code是401时，说明token失效或未登录，要跳转到登录页并清除本地用户信息；二是网络错误时，要给出统一的toast提示，而不是让每个页面自己弹窗。这样封装的收益非常大，新增一个页面模块时，你只需要写具体的API函数，不用担心请求细节。
3.3 跨域问题的根源与三种解法
前后端分离项目跑不起来，至少有一半的概率是跨域问题。浏览器有一个同源策略：协议、域名、端口任何一个不同，直接请求就会被拦截。前端运行在Vue的8080端口，后端运行在Tomcat的8080端口，端口不同，天然就是跨域。
很多新手看到浏览器控制台报CORS错误就懵了，其实解决办法就三种。
第一种是后端在Spring MVC的配置类中开启跨域支持，声明允许的来源、请求头和方法。这是最干净的做法，因为这个项目本身就是后端控制API，跨域策略跟着后端走是合理的。
第二种是前端在Vue项目的vue.config.js里配置开发环境的proxy代理。它的原理是让前端开发服务器帮你去请求后端，因为服务器端不存在同源策略限制。这种方式在开发阶段好用，但打包上线后，proxy配置就不生效了，所以只能解决本地开发问题。
第三种是使用Nginx反向代理，把后端接口统一暴露到前端域名的/api路径下。这是生产环境的标准做法，但在学习阶段配置Nginx容易增加复杂度。
我的建议是项目调试阶段用后端CORS配置，因为它一步到位，前端不需要任何额外配置。
3.4 登录态保持：Token方案在SSM项目中如何落地
前后端分离后，Session机制变得有些尴尬，因为前端和后端不在同一个服务下，Cookie的管理和跨域策略纠缠在一起，太麻烦。这套项目更合理的方案是使用Token。
用户登录成功后，后端生成一个Token返回给前端。Token的生成方式可以用UUID，也可以用一个简单的JWT实现。如果项目里没有引入JWT依赖，用UUID加过期时间存到Redis或内存Map中也能撑住学习项目。但考虑这套系统的定位是练手加答辩，我建议引入JWT，因为JWT是无状态的，后端不需要存储会话信息，验签通过就能确定用户身份，这本身就是面试加分项。
前端拿到Token后，存储在localStorage中。每次发起请求时，Axios请求拦截器把Token加到Authorization头。后端提供登录状态校验的拦截器，在处理请求前检查Token的有效性，无效就返回401。
关于拦截器配置，有一个细节值得注意：白名单机制。登录、注册、获取房间列表这类公共接口不应被拦截，否则用户还没登录就无法浏览酒店信息。但提交预订、查询订单、管理后台所有接口都必须校验身份。拦截器里配置excludePathPatterns处理白名单，这个逻辑不能写错，否则要么安全漏洞巨大，要么用户连看首页都报错。
4. 业务场景实现的硬骨头：房态管理、订单状态机与库存防超卖
4.1 房态的本质：日期+房型+数量的三维矩阵
酒店客房的业务模型比图书馆借书复杂，核心原因在于房态是用时间维度来度量的。一间房今天空着，明天可能被预订了，后天又空出来了。所以在数据库里，光靠room表的一个status字段来记录“空闲/占用”是不够的，因为它无法表达时间维度上的可用性。
我设计这套系统时，会使用一种更稳妥的模型：room表管房间的基本信息，room_status表或order表去关联“哪个时间段被谁占了”。判断一间房在某段日期内是否可用，不能只查房间表，而要查这段时间内是否存在冲突订单。
具体判断逻辑是：订单A的入住日期是start1、离店日期是end1，你要预订的日期是start2、end2，两者存在重叠的条件是：start1 < end2 且 start2 < end1。这个条件写进SQL的WHERE子句中，就能查出所有时间冲突的预订记录。只要冲突记录数大于等于房间在该房型下的可用数量，就说明没房了。
4.2 订单状态机：从待支付到已完成的流转规则
酒店预订订单不是一次写入就固定不变的，它有一个生命周期。设计状态机时，我把订单状态定义如下：
- 待支付：用户提交预订后，房间被预占，但这笔订单还没有付款。
- 已支付：付款成功后，房间确定占用，等待入住。
- 已入住：用户到店办理入住后，订单进入服务中状态。
- 已完成：退房结算后，订单结束。
- 已取消：用户在支付前取消，或管理员取消，房间释放。
这个状态机务必做到单向流转，而且要限制哪些状态可以跳转。不能允许一笔“已入住”的订单直接变成“已取消”，也不能允许“已完成”再变回“已支付”。这种限制要放在Service层，用状态判断去拦住非法操作，而不是完全信任前端传过来的操作指令。
4.3 防超卖：并发场景下这个项目给出的答案
防超卖是酒店预订系统里最有含金量的业务难点。假设某房型只有3间房，同一时刻来了4个用户同时提交预订，如果代码写成先查询可用房数，再判断是否够用，再插入订单，那并发请求会把可用房数同时读成3，然后4个订单全部插入成功，这就是超卖。
解决思路一般有三层。最基础的一层是在判断可用房数的SQL里加上条件，使用悲观锁或乐观锁的思路。悲观锁做法是SELECT ... FOR UPDATE，把这一行锁住，其他事务要等它提交才能操作。乐观锁做法是在房间表或房态表加一个version字段，更新时检查version是否匹配，不匹配就重试。
对学习项目来说，直接使用数据库的行级锁，配合事务，是一个能讲清楚原理、又能演示效果的选择。具体做法是：在事务内先执行一条带FOR UPDATE的查询，把指定房型的记录锁住，然后执行可用数判断，再插入订单、更新房态。因为锁保证了同一时刻只有一个事务能修改这组数据，并发时后面的请求会排队等待，等前面事务提交后再判断发现的可用房间数已经减少了。
讲到并发，还有一个不可忽略的点：数据库隔离级别。Spring事务默认使用的是数据库默认隔离级别，MySQL的默认是REPEATABLE READ。在校验房间可用性和插入订单之间，数据不能被其他事务干扰，因此务必将事务隔离级别设置为READ_COMMITTED或以上，并且在查询语句上使用悲观锁兜底。否则，即使加了FOR UPDATE，也会因为隔离级别设置过于宽松而产生幻读风险。
4.4 价格计算：日期差、节假日加价与订单快照
酒店价格不是一锤子买卖，它涉及入住天数、工作日与节假日的差异、会员折扣等因素。在代码实现时，我的建议是第一次计算价格时就用专门的PriceCalculator类处理，然后在订单表里记录一份“价格快照”。为什么需要快照？因为房间价格后续可能调整，如果订单页面一直从房间表实时取价，用户会看到自己订的房价格忽高忽低，这在业务上是不可接受的。所以订单的金额必须在签订时锁定。
计算逻辑举例：一间标准间平时价格是280元/晚，周末价是360元/晚。用户周五入住，周日离店，共2晚，其中周五晚按周末价计算、周六晚按周末价计算。如果用户在两大节假日场景下，还需要查holiday表来判断日期是否属于节假日价。这个逻辑不复杂，但关于“日期单位是自然日还是24小时区间”的理解要提前统一，否则就会出现跨天订单价格多算一天的Bug。
5. 管理后台与权限控制：拦截器、用户角色和权限设计的边界处理
5.1 下放给管理员的资源：房间、房型、订单、客户与统计
酒店管理员的后台功能，核心是管理酒店运营资源。房型管理负责定义房型名称、面积、床型、图片、设施，以及每间房间的基础价格。房间管理是房型下的物理房间，一个房型可以有多间房，每间房有房间号、楼层、朝向等属性。订单管理是管理员的运营核心，查看所有用户的订单列表、处理异常订单、执行取消或退款操作。客户管理用来查看注册用户信息和消费记录。数据统计模块负责分析入住率、订单量趋势、房型偏好等指标，给运营决策提供依据。
这个后台的管理端页面不需要做得多花哨，但交互和权限一定要清晰。左侧导航把模块分成层次，点击后右侧主区域加载对应的Vue视图，通过路由跳转实现页面切换。
5.2 角色权限设计的最小可行方案
我对这套系统的用户角色定义为两类：普通用户和管理员。普通用户能浏览房间、提交预订、查看和取消自己的订单、修改个人资料；管理员能管理所有后台资源。
权限控制的最简方案是：给用户表加一个role字段。前端路由通过Vue Router的导航守卫来判断当前登录用户的角色，决定是否允许访问管理端页面；后端在Controller的请求处理前用拦截器检查Token里的角色信息，拒绝非管理员访问管理接口。
需要强调的是，单纯依赖前端导航守卫是不够的，因为恶意用户可以绕过前端直接调用后端接口。后端必须在每个管理端Controller上都加上角色校验。我是通过一个AuthInterceptor实现的：拦截所有请求，解析Token，读取用户角色字段，如果访问路径是以/admin/开头而且角色不是管理员，直接返回403。这个思路虽然简易，但对一套练习项目来说足够了。
5.3 管理端常用的统计SQL：入住率和订单量趋势这样算
统计模块的SQL是这套项目里比较有含金量的部分。入住率需要统计“已入住订单的间夜数”除以“总可售间夜数”。总可售间夜数是房间数乘以统计天数，分子是订单表里状态为已入住的房间累计天数。这个查询要使用聚合函数和日期函数，对于练习MySQL操作非常有价值。
订单量趋势就是按日期分组统计订单数量。SQL写法大体是：SELECT DATE(create_time) AS day, COUNT(*) AS cnt FROM orders WHERE create_time BETWEEN ... GROUP BY day。需要注意的是时间字段的类型，如果存的是DATETIME，日期函数直接可用；如果存的是字符串，要先做格式转换。我在处理这个项目时，使用的是LocalDateTime类型，加上JSON序列化配置后，前后端传参不会因为时区或格式问题对不上。
5.4 一种更顺手的做法：用“策略模式”替代过度复杂的权限框架
很多学习项目把权限做得过于复杂，引入了Spring Security或者Shiro。我理解堆技术栈的心情，但对于一套以SSM为核心、以毕业设计或求职练习为目标的系统，我更推荐轻量级方案。引入Security意味着要理解FilterChain机制、UserDetailsService、加密策略、注解权限表达式，在一套本就承载了前后端分离逻辑的项目里，这些复杂度容易把人劝退。
在实际搭建过程中，我用拦截器配合一个小型策略工具类解决了角色区分：定义AdminRequired注解，在需要管理员权限的Controller方法上打标，拦截器只要发现方法上有这个注解且当前用户不是管理员，就直接拦截。这是策略模式的轻量应用。这样做不仅代码量少，逻辑直观，而且答辩时能清楚地讲出设计思路：用注解作为元信息，用拦截器作为执行器，再用角色模型做判断依据。
6. 从“二次开发”到“能上生产”：这套系统的扩展建议与不足分析
这套系统有相当广的延展空间。如果你愿意继续深耕，我建议从以下几个方向入手。
第一个方向是引入Redis，用来缓存热点数据。比如房型列表、房间详情这些接口，用户每次打开首页都要请求，但数据变动并不频繁。把热点数据放到Redis里，能明显减少数据库压力。更重要的是，Redis在登录场景中可以替换Token的内存存储，这样前端每次请求都不需要查数据库验证Token，登录态管理会变得非常轻松。
第二个方向是引入消息队列，合理场景是退订和订单超时处理。用户下单但一直不支付的订单，需要在15分钟后自动释放房间。这类定时任务的方案可以用Spring的@Scheduled简单实现，但更合理的做法是使用延迟队列。项目如果能在现有SSM架构上增加一个RabbitMQ延迟队列模块，会让订单超时处理、通知下发的场景变得完整且专业，答辩时也更有说服力。
第三个方向是补充测试内容。当前项目大多是Controller到DB的直接使用。如果给Service层补充JUnit单元测试，给订单创建逻辑增加并发压测代码，项目的完整性会大幅提升。测试是很多自学者忽视的环节，但他们恰恰能在面试中被单独问出来。
第四个方向是完善部署方案。目前这套系统跑在本地Tomcat，只是一套开发环境。如果给它加一份Linux环境下的部署手册，把前端打包成静态资源交由Nginx托管，后端打包成WAR包部署到Tomcat，再通过Nginx反向代理统一访问入口，这套项目就具备了基本的上线能力。很多企业的初级开发岗位对部署方式有基本要求，提前走一遍部署流程会加很多分。
从不足的角度来看，这套系统的功能粒度还可以更重视几个盲区：目前用户密码大多使用明文或简单MD5，更稳妥的做法是使用BCrypt加盐加密，能显著提高安全性；Token管理缺少服务端主动失效机制，如果用户的手机丢了或者在其他设备登录，旧Token仍然有效；Lean管理后台缺少操作日志审计，在实际业务中，管理员执行敏感操作（删除订单、修改价格）必须记录操作人、操作时间和操作内容，这是很多生产系统的硬性要求。
7. 调试运行阶段的真实记录：从“白屏”到“跑通”的关键步骤
7.1 环境匹配是第一道大关
我并不是第一次调试这类SSM+Vue项目，但每次都会遇到环境版本不一致的问题。如果你是在校生，用的很可能是学校机房的老电脑；如果你是在职自学，电脑上可能装着最新的JDK和MySQL。以下是这套项目需要严格匹配的环境列表。
- JDK：1.8或1.11。JDK 17及更高版本由于对反射和动态代理的限制，与旧版Spring、MyBatis会存在兼容问题。遇到UnsupportedClassVersionError或InaccessibleObjectException时，优先检查JDK版本。
- Maven：3.6.x或3.8.x即可，仓库最好配置阿里云镜像，否则首次下载Spring和MyBatis依赖时会等得让人怀疑人生。
- MySQL：5.7或8.0都可以，但要区分驱动和连接URL。如果使用8.0，驱动必须明确为com.mysql.cj.jdbc.Driver，URL必须带serverTimezone参数。
- Node.js：Vue项目依赖Node环境，建议用14.x或16.x版本。Npm版本过新可能导致node-sass编译失败，如果项目用的是sass，建议直接切换到dart-sass。
- Tomcat：8.5或9.0。Tomcat 10以上换了Servlet API的包名，和老SSM项目不兼容，Java代码会报NoClassDefFoundError。
注意：如果你的项目自带Maven打包的WAR文件名，配置Tomcat时要把war包重命名为ROOT.war，或者调整Tomcat的context路径，否则部署之后的访问路径会多出一层目录，前端请求的baseURL就全部失效了。
7.2 数据库初始化最容易踩的坑
数据库脚本是这套系统能否顺利跑起来的关键。大部分源码会附带一个xxx.sql文件。但执行脚本时要注意几个问题。
第一是编码问题。如果SQL文件是用UTF-8保存的，而MySQL客户端默认使用latin1或gbk，执行后中文会变成乱码。需要使用source命令指定编码，或者在连接串里加characterEncoding=utf8参数。
第二是外键约束和引擎问题。脚本里如果有外键约束，导入的顺序不能乱。如果直接执行整份脚本报错，优先检查被外键引用但还没创建的表。部分低版本的MySQL数据库默认引擎是MyISAM，不支持外键和事务，需要手动改成InnoDB。
第三是初始数据必须包含一个管理员账号和一个测试用户账号。我的习惯是先登录管理员，确认后台页面能正常渲染，再去注册新用户测试预订流程。这样能快速区分故障模块到底在前端路由、后端接口还是数据库本身。
7.3 启动顺序和IDE配置的细节
启动这套系统必须遵循一个顺序：MySQL -> Redis（如果用了）-> 后端Tomcat -> 前端Npm run serve。先后顺序不能乱，因为前端启动时会检查后端接口是否可达。
在IDEA里导入后端项目后，第一件事是确认Maven配置是否正确：检查项目中pom文件是否正确、本地仓库是否已有依赖、项目根目录是否被正确标记为Sources Root。然后配置Tomcat，把war包部署上去，再修改VM options添加内存参数。曾经遇过不作任何内存调整时，Spring容器启动一半就OOM的情况，项目复杂起来后这种情况会很明显。
前端项目导入VSCode后，执行npm install之前要确认一下package.json里的依赖版本。我个人建议装完依赖后先跑一遍npm run serve，如果报编译错误，优先去看sass相关代码是否替换成了dart-sass语法。
7.4 接口联调时最高频的三个错误
联调阶段最常见的问题当然是跨域。这个问题在前面已经详细说过配置方法，但我想补充一个容易忽略的点：如果后端项目使用@CrossOrigin注解进行局部跨域配置，那么不同Controller使用不同配置风格会产生不可控的冲突。建议要么全项目统一开CORS，要么全项目统一用拦截器处理，不要混用。
第二个高频问题是Token未传递。表现是登录后，前端跳转到首页，但请求预订接口报401。排查方法是打开浏览器开发者工具，查看请求头里有没有Authorization字段。如果没有，检查Axios拦截器中header设置的代码有没有被执行；如果有，检查后端拦截器处理Token的代码是否读错了header名称。这类问题定位很快，但不知道去哪看的话会很迷。
第三个问题是日期格式解析失败。前端返回的日期是“2025-03-21”格式或带T的ISO格式，Spring默认的Date转换器解析不了，会直接报400。解决办法是在后端全局配置一个Jackson序列化规则，或者接收参数时用@DateTimeFormat注解指定格式。这一点非常建议在项目开始时就配置好，否则每个日期参数都会是一个定时炸弹。
7.5 前端页面渲染异常的排查思路
前端白屏不一定全是接口问题。我用这套系统测试时，遇到过多次前后端都正常但页面空白的情况。排查分四步走。
第一步，看浏览器控制台有没有JavaScript报错。Vue的渲染错误会直接打印在console里，这是最快定位问题的方式。
第二步，检查路由配置是否存在拦截器循环。Vue Router的导航守卫里如果写错了跳转逻辑，会导致页面不停重定向，最终白屏。我曾经在导航守卫里写了判断当前用户不存在就跳转登录页，但登录页本身也触发了守卫，形成了一个死循环。
第三步，确认接口数据结构是否符合前端期望。Vue拿到后端返回的data后，如果直接渲染data.list，而后端返回的是data.records，页面就会是空列表。这种字段名不一致的问题非常隐蔽，要沿着接口返回的JSON逐层比对。
第四步，确认组件注册和路由懒加载的配置一致。如果使用了异步组件或路由懒加载，路径写错会导致组件加载失败而页面空白。这种情况下浏览器控制台会显示一个动态import失败的错误。
7.6 浏览器调试工具的进阶用法
调试前后端分离项目时，浏览器开发者工具Network面板会是你最得力的助手。重点看几个信息：某个接口的Status Code；请求和响应的Preview面板，查看JSON结构；查看某个接口的耗时，判断是数据库慢查询还是前端渲染慢。
当某个接口返回500时，优先切到后端Tomcat控制台找异常堆栈。Java报错堆栈里最关键的三行信息是：异常类型、出错类名和出错行号。拿到行号之后回到IDE对照代码，80%的问题都能当场定位。如果遇到看不懂的异常类型，不要把整段堆栈贴到搜索引擎里，而是把异常类名单独拆出来去查，效率高得多。
8. 做完这个项目后，我觉得最值钱的三个收获
第一，我真正理解了“分层”不仅是代码结构上的划分，更是团队协作时的分工边界。Controller、Service、Mapper各司其职，改动一个模块不会影响另一个模块，这种模块化思维是日常工作里最关键的工程素养。
第二，我学会了通过“全局视角”去看一个项目的全貌。从数据库设计阶段先画ER图，到依据ER图设计API，再到前端根据API写页面，整个过程形成了完整链路。这一套方法迁移到任何其他管理系统，比如图书馆系统、健身房预约系统、会议室预订系统，都能很快复刻出来。
第三，项目里踩过的每一个坑都成了我后续几套项目快速推进的地基。从SSM到Spring Boot，从JSP到Vue，框架可以变，但关于事务边界、Token认证、跨域处理、版本冲突的认知，是通用的、可以复用的。
如果你正在纠结要不要选这套项目作为毕业设计，或者正卡在某个启动报错里，不妨先把我在调试章节里列的那些排查步骤过一遍。数据库连不上就先试命令行，报缺类就检查Maven依赖，前端白屏就先看控制台。大多数问题都是这几个地方，问题本身并不可怕，可怕的是遇到问题直接放弃。
等这套系统顺利跑通、你能用管理员账号登录后台、用户能正常下订单，再回过头去看看每个Java文件、每个Vue组件、每份配置文件背后的逻辑。你会发现自己早已不只是一个“会运行源码”的读者，而是一个真正“能造系统”的开发者。
