洗浴管理系统实战：Spring Boot + MyBatis Plus 完整设计与实现

1. 洗浴管理系统到底在管什么：业务场景与模块拆解

每年带课程设计和毕业设计，总能看到一批同学扎堆选"某某管理系统"。洗浴管理这个名字听起来有点"小众"，但说实话，它背后的业务逻辑相当完整——会员、计费、商品、报表全都有，而且场景贴近现实生活，答辩的时候能讲的东西很多。跟图书管理、学生管理这类"教科书式"项目相比，洗浴管理的业务规则更复杂，比如按时计费、按次计费、手牌挂账、押金管理这些细节，做出来的系统才真正有"设计感"。

我先把这个系统的业务全貌说清楚。一家中等规模的洗浴中心，日常运营涉及的核心角色无非三类：

• 前台收银员：办卡、开单、结账、挂账、退押金，这是系统使用频率最高的角色
• 管理员：管理商品库存、查看营业报表、配置计费规则、管理员工账号
• 顾客：通过手牌或会员卡消费，需要查询余额、消费明细

围绕这三个角色，系统至少要包含以下功能模块：

会员管理。洗浴中心几乎都是会员制运营，散客占比很低。会员卡通常分次卡、时限卡、储值卡三种。次卡就是"洗20次"这种，时限卡是"30天不限次"，储值卡则是先充钱后消费。三种卡对应的计费逻辑完全不同，数据库设计时最好用一张会员表加一个卡类型字段来区分，而不是拆成三张表，否则后面的计费逻辑会写到你怀疑人生。

手牌管理。这是洗浴行业特有的一套机制。顾客进门，前台开单分配一个手牌号，顾客凭手牌进入浴区消费。手牌有"空闲、占用、挂账、已结账"几种状态，手牌状态的管理直接影响到后面的计费逻辑。

计费管理。洗浴计费比想象中复杂。首先有"净桑"和"套餐"的区别，净桑就是纯洗澡，套餐会包含搓澡、汗蒸这些增值服务。其次计费方式有时长计费（按小时）、按时段计费（过夜加钱）、按次计费（门票制）多种模式。这块是整个系统最核心、最容易出错的模块。

商品管理。浴区里卖的毛巾、饮料、零食，前台卖的各种洗护用品，都需要进销存管理。库存扣减、盘点、进货记录，麻雀虽小五脏俱全。

营业报表。老板最关心的是今天的营业额多少、会员充值了多少、哪些项目卖得最好。日报、月报的统计功能不需要太复杂，SQL写几个GROUP BY就能搞定，但一定要有，这是答辩时最出彩的部分。

系统管理。员工账号、角色权限、操作日志，这个不用多说，几乎每个管理系统都有。

从技术角度看，这个项目选Spring Boot + MyBatis Plus + MySQL + Vue（或Thymeleaf）是最稳妥的组合。如果你做的是前后端分离版本，前端建议用Vue 3 + Element Plus，后面接Spring Boot接口；如果不想折腾前端，直接用Thymeleaf + Bootstrap渲染后端页面也行，省去跨域和打包的麻烦。我对课程设计类项目的建议是：能简单就简单，优先保证把业务逻辑讲清楚，不要盲目堆技术栈。

2. 技术选型与项目架构：为什么Spring Boot是这种系统的最佳选择

2.1 框架选择的底层逻辑

市面上做管理系统的框架很多，SSH（Struts + Spring + Hibernate）是老古董了，SSM（Spring + Spring MVC + MyBatis）虽然经典但配置繁琐。Spring Boot的出现，核心价值就是解决Spring配置地狱的问题——约定优于配置，内嵌Tomcat，自动装配。拿洗浴管理系统来说，你只需要一个启动类加几个注解，就能把Web环境跑起来，这对课程设计和毕业设计来说是巨大的效率提升。

还有一点很关键，Spring Boot的生态太成熟了。你需要权限认证，引入Spring Security或Sa-Token；你需要操作数据库，引入MyBatis Plus；你需要接口文档，引入Knife4j；你需要参数校验，引入Validation——全都是starter一键引入，专注写业务代码就行。这也是为什么现在企业招Java后端，Spring Boot几乎是必须写在简历上的技能。

2.2 项目分层设计

这个项目的代码结构，我建议按经典的四层架构来组织，你不用自己去发明什么新架构，四层够用且是面试官最熟悉的：

code复制com.sauna
├── controller        // 控制层：接收请求、参数校验、返回结果
├── service           // 服务层：核心业务逻辑（计费、结算、会员操作）
├── mapper            // 数据访问层：MyBatis Plus的Mapper接口
├── entity            // 实体类：对应数据库表结构
├── dto               // 数据传输对象：接收前端参数，不直接暴露实体
├── vo                // 视图对象：返回给前端的数据结构
├── config            // 配置类：拦截器、WebMvc配置、全局异常处理
├── common            // 通用类：统一返回结果（R类）、常量、枚举
└── util              // 工具类：时间处理、金额计算

分层设计的核心价值是降低耦合。举个例子，你在service层写一个"结账"方法，它需要调用会员Service扣余额、调用订单Service记录消费、调用手牌Service释放手牌、调用日志Service记录操作。如果这些逻辑全部堆在Controller里面，Controller会膨胀到几百行，而且事务边界极难控制——四个操作要么全成功、要么全失败，中途只要有一步抛异常，之前扣的余额就没法自动回滚了。放到Service层，一个@Transactional注解就能解决。

2.3 统一返回结果与全局异常处理

这两个东西容易被忽略，但实际开发中非常重要。很多同学写接口的时候，返回类型一会儿是Map，一会儿是List，一会儿是String，前端对接的时候非常痛苦。我要求所有接口统一返回一个R<T>对象：

java复制public class R<T> {
    private Integer code;// 状态码：200成功，500失败
    private String msg;// 提示信息
    private T data;// 返回数据
    public static <T> R<T> success(T data) {
        R<T> r = new R<>();
        r.setCode(200);
        r.setMsg("操作成功");
        r.setData(data);
        return r;
    }
    public static <T> R<T> fail(String msg) {
        R<T> r = new R<>();
        r.setCode(500);
        r.setMsg(msg);
        return r;
    }
}

全局异常处理用@RestControllerAdvice + @ExceptionHandler实现。这样做的好处是，Service层只管抛业务异常，Controller层不用到处try-catch，所有异常统一汇聚到全局处理器里转换为友好的提示信息返回给前端。

提示：建议自定义一个BusinessException，凡是业务上的异常（比如"余额不足""手牌已被占用"）都抛这个类型。全局异常处理器中，BusinessException返回500和业务提示信息，其他未知异常统一打印日志并返回"系统繁忙，请稍后重试"，避免把数据库报错直接暴露给用户。

3. 数据库设计：13张表背后的业务规则和边界情况

3.1 核心表结构总览

洗浴管理系统的数据库设计是整个项目的地基。我基于实际开发经验，整理了一套经过验证的表结构方案，共13张表：

3.2 会员卡设计：三种计费模式的数据库表达

这里重点说下会员卡的设计。表面上很简单——一个会员表存余额、存次数。但如果你把"次数"和"余额"都放在同一个字段里，后面遇到"次卡过期""余额不足但还有次数"这些情况就没法灵活处理了。

我的方案是用card_type区分卡种，用独立字段记录不同维度：

• 储值卡：只关注balance（余额），消费时扣余额
• 次卡：只关注total_times（总次数）和used_times（已用次数），每次消费做used_times + 1，剩余次数 = total - used
• 时限卡：只关注expire_time（到期时间），判断expire_time > NOW()即可决定是否有效

至于"一个会员能不能同时持有多种卡"这种问题，课程设计阶段我建议不要做成多卡并存，一个会员一张卡，简单直接，把精力花在核心逻辑上。

3.3 计费逻辑的边界情况

洗浴计费有几种典型场景，设计数据库时就要想清楚：

场景一：低消商品。很多洗浴中心的净桑门票里包含一份水果或饮料，顾客消费时系统要自动判断是否超过包含额度。这种情况下，订单明细表需要一个is_included字段，标记该商品是否包含在门票套餐内，金额为0也要记录，方便日后报表统计。

场景二：跨天计时。顾客凌晨12点前进来，凌晨2点走，计费规则是"超过凌晨00:00加收过夜费"。这时hand_card表的start_time、end_time字段必须是datetime类型，并且计费逻辑里要单独判断"是否跨天"。

场景三：押金管理。手牌是实体的，顾客领取时需要缴纳押金，结账时退还。押金不能和消费金额混在一个字段里，需要独立字段deposit存储，退款时走单独的退款流程。

数据库设计这块，只有真正上线运营过的人才懂这些细节。从课程设计的角度，不一定全做，但至少要理解这些业务规则的存在——答辩老师问起来，你能讲明白为什么这样设计，就是加分项。

4. 核心功能实现：从登录鉴权到计费结算的完整链路

4.1 登录与权限拦截：Sa-Token还是Spring Security？

用户认证这块，我强烈推荐使用Sa-Token。理由很简单：Sa-Token封装了登录、注销、权限认证、踢人下线这些功能，几行代码就能搞定，比Spring Security的学习成本低一个数量级。

java复制// 登录逻辑
@PostMapping("/login")
public R<String> login(@RequestBody LoginDTO loginDTO) {
    // 1. 查询用户
    LambdaQueryWrapper<Employee> wrapper = new LambdaQueryWrapper<>();
    wrapper.eq(Employee::getUsername, loginDTO.getUsername());
    Employee employee = employeeMapper.selectOne(wrapper);
    // 2. 校验密码（MD5加盐或BCrypt）
    if (employee == null || !BCrypt.checkpw(loginDTO.getPassword(), employee.getPassword())) {
        throw new BusinessException("用户名或密码错误");
    }
    // 3. 校验状态
    if (employee.getStatus() == 0) {
        throw new BusinessException("账号已被禁用");
    }
    // 4. 登录成功，生成token
    StpUtil.login(employee.getId());
    return R.success(StpUtil.getTokenValue());
}

权限拦截用Spring Boot的HandlerInterceptor加WebMvcConfigurer注册，全局限流+鉴权。不推荐在每个Controller方法里手动判断StpUtil.isLogin()，那是重复劳动，而且容易漏。统一走拦截器，排除登录接口和静态资源路径，剩下的所有请求都校验登录状态。

4.2 手牌状态机：从空闲到结账的流转

手牌是洗浴系统的"交通枢纽"，所有业务流程都围绕手牌展开。我建议把状态用枚举定义好：

java复制public enum HandCardStatus {
    FREE(0, "空闲"),
    USING(1, "使用中"),
    PENDING_PAY(2, "待结账"),
    DISABLED(3, "已停用");

    private final Integer code;
    private final String desc;
    // 构造函数、getter方法省略
}

状态迁移的规则：

• FREE -> USING：顾客进场，前台开单分配手牌，记录开单时间
• USING -> PENDING_PAY：顾客离场结账，系统计算费用但尚未确认支付
• PENDING_PAY -> FREE：支付完成后，手牌释放，可以分配给下一个顾客
• FREE -> DISABLED：手牌丢失或损坏，停用该手牌

这块我觉得需要画状态机图（当然博客里不画图，我用表格说清楚就行），编码时要注意的坑是：每次状态变更都必须用UPDATE语句配合WHERE条件做乐观锁，否则多台收银机同时操作同一块手牌，会出现重复开单或者状态错乱的问题。

实操代码：

java复制@Mapper
public interface HandCardMapper extends BaseMapper<HandCard> {
    @Update("UPDATE hand_card SET status = #{newStatus} WHERE id = #{id} AND status = #{oldStatus}")
    int updateStatusWithLock(Long id, Integer oldStatus, Integer newStatus);
}

调用时检查updateStatusWithLock的返回值，如果返回0，说明状态已经被其他请求修改了，直接提示"手牌状态已变化，请刷新重试"。这个细节写进论文里，是非常亮眼的"并发安全处理方案"。

4.3 结账计算的完整流程

结账是整个系统最复杂的操作，我按步骤拆解：

1. 校验手牌状态：必须是USING状态，否则拒绝结账
2. 计算净桑费用：根据开单时间和结账时间，按计费规则计算
3. 计算商品费用：查询该手牌对应的order_item中未结算的商品记录
4. 合计算总金额：净桑费用 + 商品费用 - 会员折扣 = 应支付金额
5. 判断支付方式：如果会员卡余额足够，优先使用余额支付；否则现金/微信/支付宝
6. 扣减余额/记录订单：生成订单主记录和明细记录，扣减会员余额
7. 释放手牌：状态改为FREE
8. 记录消费流水：在consumption_record中记录，用于后续查询余额变动

这个过程必须要加@Transactional事务注解，而且事务要放在Service层。我见过很多同学把@Transactional加在Controller方法上，其实这也能生效，但不符合规范——Controller不需要也不应该管事务，事务是服务层的职责，因为一个事务边界正好对应一个完整业务操作。

计费核心算法示例：

java复制@Override
@Transactional(rollbackFor = Exception.class)
public PayResult settle(Long handCardId, Integer payType) {
    HandCard handCard = handCardMapper.selectById(handCardId);
    if (handCard == null || !HandCardStatus.USING.getCode().equals(handCard.getStatus())) {
        throw new BusinessException("手牌状态异常，无法结账");
    }
    // 1. 计算净桑费用：开单到结账的小时数 * 单价
    long minutes = Duration.between(handCard.getStartTime(), LocalDateTime.now()).toMinutes();
    BigDecimal saunaFee = calcSaunaFee(minutes, handCard.getCardType());
    // 2. 查询待结算商品
    LambdaQueryWrapper<OrderItem> itemWrapper = new LambdaQueryWrapper<>();
    itemWrapper.eq(OrderItem::getOrderId, handCard.getCurrentOrderId());
    List<OrderItem> items = orderItemMapper.selectList(itemWrapper);
    // 3. 汇总商品金额
    BigDecimal goodsFee = items.stream()
            .map(OrderItem::getAmount)
            .reduce(BigDecimal.ZERO, BigDecimal::add);
    // 4. 生成订单、更新余额、记录流水、释放手牌（省略细节）
}

这个calcSaunaFee方法网上有无数版本，很多都是简单的小时乘以单价。但真实场景中还要考虑"不满半小时按半小时计""超过一定时长打折""跨天加收"这些规则。解析时我先写最简单的版本，然后在论文中说明可以扩展的计费规则点，这样设计才完整。

4.4 报表统计：SQL排名与分组

营业报表是答辩时的加分项，实现也不难。比如"近7天每日营业额"：

java复制@Select("SELECT DATE(create_time) AS day, SUM(pay_amount) AS total_amount " +
        "FROM orders " +
        "WHERE create_time >= DATE_SUB(CURDATE(), INTERVAL 6 DAY) " +
        "GROUP BY DATE(create_time) ORDER BY day")
List<DailyReportVO> selectDailyReport();

"热销商品TOP5"：

java复制@Select("SELECT item_name, SUM(quantity) AS total_quantity, SUM(amount) AS total_amount " +
        "FROM order_item " +
        "WHERE item_type = 'GOODS' " +
        "GROUP BY item_name " +
        "ORDER BY total_quantity DESC LIMIT 5")
List<HotGoodsVO> selectHotGoods();

这些SQL都不复杂，关键是思路：报表查询和业务查询分开写，不要在Service里先查List再在Java代码里GroupBy求和，SQL能一次搞定的就交给SQL。

5. 开发调试阶段最容易踩的坑：我的排查链路记录

5.1 环境层面的经典问题

做Spring Boot项目，环境问题占了排查时间的40%以上。最典型的几个：

JDK版本与Spring Boot版本兼容性。Spring Boot 3.x要求JDK 17及以上，Spring Boot 2.x支持JDK 8/11。如果你用的JDK 8装了Spring Boot 3.x的依赖，启动直接报错，报错信息可能指向一些莫名其妙的地方。建议统一：JDK 8 + Spring Boot 2.7.x，或者JDK 17 + Spring Boot 3.x，别混搭。

Maven依赖下载缓慢或失败。国内网络环境下，Maven中央仓库经常连不上，或者下载到一半卡死。解决方法是配置阿里云镜像。这个问题的排查思路很明确：如果pom.xml里的依赖一直标红，先检查Maven是否用了国内镜像，再检查仓库配置是否正确。

排查链路：

1. 打开maven/conf/settings.xml，确认mirror节点
2. 执行mvn clean compile -X查看依赖下载日志，定位卡在哪个依赖
3. 如果是某个特定依赖反复下载失败，可能是网络原因或者依赖本身的坑
4. 删除本地仓库.lastUpdated后缀文件后重试

5.2 启动报错"Failed to configure a DataSource"

这个报错出现概率极高，原因很简单：Spring Boot自动配置发现你引入了数据库相关的starter，但application.yml里没有配置数据源信息

排查链路：

1. 先检查pom.xml有没有引入spring-boot-starter-data-jpa或mybatis-spring-boot-starter
2. 检查application.yml或application.properties中的spring.datasource.url/username/password有没有配置
3. 检查MySQL服务是否启动，端口是否3306
4. 检查数据库名、用户名、密码是否匹配——这里最容易出错，密码包含特殊字符时需要加引号或使用转义

还有一种情况是，你明明配了数据源但仍然报错，那就检查@SpringBootApplication注解扫描的包路径。默认扫描启动类所在的包及其子包，如果Application启动类在com.sauna，而Mapper接口在com.sauna.mapper，没问题；但如果Mapper接口在com.sauna.admin.mapper，就会扫描不到。解决方案是在启动类加@MapperScan("com.sauna.**.mapper")。

5.3 MyBatis Plus的常见误区

字段映射问题。MyBatis Plus默认将实体类的驼峰字段createTime映射为数据库的create_time列，前提是要开启驼峰映射配置：

yaml复制mybatis-plus:
  configuration:
    map-underscore-to-camel-case: true

不开启的话，createTime会绑定到createtime列（MySQL在Windows环境下不分大小写，Linux下区分），查出来的数据全是null，看起来像"查询失败"，实际是映射问题。

逻辑删除配置。这里要留意一个典型的坑：如果你在实体类的deleted字段上加@TableLogic注解，那么MyBatis Plus执行deleteById时会变成UPDATE SET deleted=1，而不是真正删除。多个条件删除时，如果deleted字段没有设置默认值，老数据的deleted是null，WHERE deleted = 0就查不出来。所以加逻辑删除字段时，一定要给数据库字段设置DEFAULT 0。

分页插件。MyBatis Plus分页需要在配置类注册PaginationInnerInterceptor，很多人一开始忘了注册，然后发现page方法没生效，把全表数据一次性查出来了。代码：

java复制@Configuration
public class MybatisPlusConfig {
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));
        return interceptor;
    }
}

如果忘了加这一步，用Page对象查询时，total为0、records是全部数据，这是个大坑，调试时很难发现。

5.4 前端联调阶段最头疼的跨域与JSON格式问题

如果你做的是前后端分离，前端跑在localhost:5173（Vite默认端口），后端跑在localhost:8080，跨域问题躲不掉。常见方案：在后端写一个CORS配置类：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

另外，Swagger接口调试时，如果发现日期时间字段返回的是时间戳，需要在实体类的时间字段上加@JsonFormat注解，或者全局配置Jackson的日期格式。这个问题在洗浴系统里尤其突出——计费记录、开单时间、结账时间都是时间字段，格式不对前端根本没法渲染。

java复制@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")
private LocalDateTime createTime;

6. 项目讲解与答辩的系统性思路

源码和文档都有了，最后一个重要环节是"讲解"。很多同学代码写得没问题，但一上讲台就不知道从哪讲起。这篇系统设计的讲解思路，我建议按下面的逻辑串联。

6.1 先讲清楚"为什么做"而不是"怎么做"

别一上来就甩架构图和技术栈。先讲故事：洗浴中心的日常运营有哪些痛点——手牌管理混乱、计费容易出错、会员余额不透明、财务报表靠手工。这些问题天然存在，而你的系统就是为了解决这些痛点。把故事讲清楚了，后面所有设计都有了理由支撑。

6.2 按业务流程演示功能

演示不要按菜单顺序点一遍，那样没有逻辑。要按一个顾客完整的消费流程来演示：

1. 顾客到店，前台录入会员信息/办理新卡
2. 分配手牌，顾客进入浴区
3. 浴区消费商品，前台录入手牌挂账
4. 顾客离场，结账计算费用（演示计时计费的计算过程）
5. 打印小票、释放手牌
6. 查看今日营业报表，验证刚才的消费是否正确统计

这样演示的好处是，每一步操作都有前因后果，老师跟着你的节奏走，思路不会断。

6.3 答辩高频问题清单

根据我带项目的经验，答辩老师最常问的问题集中在以下几个方面：

• 事务管理："结账过程中如果扣款成功但生成订单失败怎么办？"——回答：@Transactional保证原子性，任何一步异常全局回滚
• 并发问题："两个收银员同时给同一个手牌结账会怎样？"——回答：乐观锁方案，UPDATE ... WHERE status = 旧值，通过影响行数判断冲突
• 密码安全："员工密码是明文存储吗？"——回答：BCrypt加密存储，登录校验用BCrypt.checkpw()
• 计费规则："过夜费用怎么计算的？"——回答：在calcSaunaFee中判断是否跨天，额外叠加时段费用
• 数据库设计："次卡和储值卡的消费逻辑有什么不同？"——回答：次卡扣次数不扣余额，储值卡扣余额不扣次数，卡类型字段区分

提前把这些问题的答案写进讲解文档里，答辩时不慌，回答得流畅自信，分数自然不会低。

7. 这份源码怎么快速跑起来：部署与启动清单

不管你是直接拿这份源码做二次开发，还是照着源码自己敲一遍，下面的启动清单都能帮你少走很多弯路。

7.1 环境准备清单

7.2 启动步骤

1. 导入数据库：用Navicat或命令行执行项目doc目录下的schema.sql，生成初始数据（包含一个测试账号admin/admin123）
2. 修改配置文件：打开application.yml，修改数据库的url、username、password
3. 启动后端：IDEA运行SaunaApplication.java，观察控制台启动日志，确认端口8080启动成功
4. 启动前端（如果是前后端分离版）：在frontend目录执行npm install，然后npm run dev，浏览器访问localhost:5173
5. 验证登录：使用初始账号登录，检查首页数据是否正常显示

注意：如果MySQL是8.x版本，pom.xml中的驱动必须是com.mysql.cj.jdbc.Driver，并且url要加serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=utf8。如果漏掉时区参数，操作时间字段时会报错或差8个小时。

踩过几次坑之后，我的习惯是每拿到一套新源码，先不看业务代码，先把环境跑通，再对照数据库表结构看代码——数据库设计能看懂，代码逻辑就懂了一半。

8. 从洗浴管理到通用业务：这套系统的可复用设计方法论

写到这里，我想最后分享一点更深层的想法。很多人觉得课程设计做完就完了，但其实洗浴管理系统这个题目，最大的价值在于它的业务逻辑可以复用到大量其他系统里。

会员管理 + 商品管理 + 订单管理 + 报表统计，这一套组合几乎是所有"门店运营类"系统的通用骨架。你把这套代码里的"手牌"换成"桌号"，就是餐厅收银系统；换成"房间号"，就是酒店管理系统；换成"机位号"，就是网吧计费系统。计费模型、状态机、订单流程这些设计思想是相通的。

我给准备做类似项目的同学几个实用建议：

• 不要过度设计。课程设计阶段，Redis缓存、消息队列、微服务这些技术栈不要强行引入。老师更看重的是你把一个完整的业务逻辑做闭环了，而不是你集成了多少技术栈却没跑通
• 代码多写注释。不只是给自己看，答辩老师和查重系统都会看代码。注释规范了，代码质量评分自然高
• 文档务必自己写。就算源码是参考的，文档也一定要自己梳理一遍。写文档的过程就是理解系统的过程，答辩时才能应对自如

这套洗浴管理系统的设计和实现，核心难度不在技术，而在把现实业务规则转换成软件逻辑的那一层抽象能力。把这层能力练好，未来做任何管理系统心里都有底。