Spring Boot宾馆用品管理系统：从数据库设计到部署答辩全指南

毕设选管理系统类题目，一直是大多数人的稳妥之选，而“宾馆用品管理”这个方向在Spring Boot的加持下，属于典型的“需求清晰、边界明确、技术栈通用、工作量适中”的题目。很多同学私信问我这类系统到底该怎么做，代码拿到手后怎么改成自己的，甚至还有不少人是直接冲着“附源码”三个字来的。这一篇我打算把这类系统的完整设计思路、技术选型理由、数据库建模细节、核心功能实现逻辑，以及部署答辩阶段最容易被追问的坑全部梳理一遍，给准备做类似题目的同学当一份可直接上手的参考手册。

1. 为什么这类“用品管理”题目总是被推荐：需求边界太好画了

先聊一个很多人在开题阶段忽略的问题：毕设题目好不好做，关键不在名字听起来是否高大上，而在于这个系统的功能边界是否清晰、用户角色是否明确、数据流转是否完整。宾馆用品管理系统恰好在这三点上天然占优。

宾馆用品管理的核心诉求说白了就是三件事：东西有哪些、东西在哪儿、东西够不够用。围绕这三件事，系统天然能分出几类用户：前台操作员负责日常登记，库房管理员负责出入库审核，部门主管或者经理负责查看统计报表和审批异常，系统管理员负责人员权限和基础数据维护。角色一清晰，菜单和权限模型设计起来就顺了。

再说数据流转。所有用品的生命周期都可以被拆解成“采购入库—领用出库—库存变更—统计预警”这条线性链路。每一步都有明确的操作对象和操作结果，非常适合用Spring Boot + MyBatis Plus这套经典组合来实现。跟那些一上来就陷入复杂算法或者高并发场景的题目相比，这类系统的开发风险可控，也很容易在答辩时把自己的设计思路讲圆。

还有一个容易被忽略的好处：这类系统扩展空间非常大。你可以在基础CRUD之上加入库存预警、采购申请审批、月度消耗统计报表、Excel导入导出，甚至对接一个简单的移动端扫码出入库界面。这些扩展点随便做上一两个，整个项目的完成度和答辩亮点就出来了。

2. 技术选型不是越新越好：Spring Boot这套组合拳为什么最合适

很多同学在选型时容易走进两个极端：一个是抱着课本里的SSH（Struts2 + Spring + Hibernate）不放，另一个是无脑追新，非要把Spring Cloud Alibaba、RabbitMQ、ElasticSearch全部塞进一个毕设里。这两种我都见过，前者答辩时被问到“为什么不用更主流的方案”很难解释，后者则往往因为项目过于复杂而烂尾。

我的建议一直很明确：用Spring Boot 2.7.x + MyBatis Plus + MySQL + Redis（可选）+ Vue或者Thymeleaf。理由如下。

Spring Boot解决的是“配置地狱”问题。以前SSM整合要写一堆XML，Spring Boot通过自动配置和Starter机制把这些事情都藏起来了，一个spring-boot-starter-web就能把内嵌Tomcat、MVC、Jackson序列化全部带进来。这也意味着你的代码量会显著减少，能把更多精力放在业务逻辑而不是配置文件的堆砌上。

MyBatis Plus则是在MyBatis基础上做了一层增强。对于宾馆用品这种以单表CRUD为主的系统，MyBatis Plus的BaseMapper已经内置了selectById、insert、updateById、deleteById这些方法，不用写XML就能完成80%的数据库操作。它自带的分页插件也很实用，配置一个MybatisPlusInterceptor就能搞定分页查询。

服务端渲染方案上，如果不想前后端分离，直接上Thymeleaf，页面复用layout模板，配合Bootstrap写出来的界面不至于太丑也比Vue少了一层跨域调试。如果觉得自己前端功底还过得去，那就用Vue3 + Element Plus做前端，Spring Boot只暴露RESTful接口。毕设层面两条路都行，我个人的偏好是后者——因为前后端分离架构在论文里可以多写出一章“接口设计与实现”，工作量更容易达标。

下面是两个方案的直观对比，我做成表格供参考：

数据库方面我选了MySQL 8.0，原因不用多解释，行业标配。Redis不是必须的，但如果你的系统里有“今日领用统计”“实时库存看板”这类热点查询，把结果缓存到Redis里能明显提升接口响应速度，也算是论文里的一个技术亮点。

3. 数据库是这套系统真正的地基：表结构设计经验与字段深坑

我每次强调“数据库先设计好，代码写起来就是搬砖”，是因为这类系统的复杂逻辑最终都会落回到多表关联和状态流转上。如果用品的分类、出入库记录、库存快照这些表的关系没理清楚，后面写业务代码时就会不停地改表结构、改Mapper，人直接改麻。

我设计的核心表大概有这些：user（用户表）、category（用品分类表）、supplier（供应商表）、item（用品信息表）、stock（库存表）、stock_in（入库单主表）、stock_in_item（入库明细表）、stock_out（出库单主表）、stock_out_item（出库明细表）、alert_config（预警阈值配置表）。为什么入库和出库要拆成主表和明细表两张？因为一张入库单可能包含多种用品，每种用品的数量、单价不一样，如果不拆表，数据要么产生大量冗余，要么只能满足“单条记录对应单次操作”这种不切实际的假设。主表记录单据的全局信息，比如单号、操作人、入库时间、备注、状态；明细表记录每种用品在这个单据里的具体数量、单价、小计金额。这样后续统计月度采购金额、供应商供货排行，直接关联主表+明细表就能查出结果。

字段类型这里有几个非常容易踩坑的地方，我一个个说。

第一是库存数量字段。很多同学嫌麻烦直接用int，但如果你的系统里存在按“公斤”“升”计量的消耗品，就会面临无法表示小数的问题。我建议统一用decimal(10,2)，整数小数字段都能兼容。但要注意，所有和“数量”相关的计算，在Java里对应BigDecimal，别用double，否则0.1+0.2不等于0.3的经典问题会在库存统计和金额汇总时给你好看。

第二是金额字段。采购单价、金额合计一律用decimal(10,2)，禁止用float或double。浮点数在二进制中无法精确表示多数十进制小数，多次累计入库金额后误差会逐渐放大，财务统计一旦出现几毛钱对不上的情况，排查起来非常浪费时间。

第三是时间字段的统一。建议全局统一使用datetime，并让数据库字段默认值设置为CURRENT_TIMESTAMP，创建时间create_time不用Java代码手动set，直接依赖数据库自动填充。MyBatis Plus里也可以配置自动填充处理器，但我更推荐数据库层面设置默认值，因为这样即使有人绕过Java代码直接改库，数据的创建时间也不会丢。

第四是唯一键设计。用品的item_code（用品编号）一定要加唯一索引，库存表里的item_id也建议做唯一约束。原因很现实：系统里每次新建用品、调整分类、查看库存明细，都会以编号为查询条件，没有唯一索引，在并发或者重复提交的场景下很容易产生重复数据。

下面是库存表的核心结构示例，可以作为参考：

sql复制CREATE TABLE `stock` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `item_id` bigint(20) NOT NULL COMMENT '用品ID',
  `quantity` decimal(10,2) NOT NULL DEFAULT '0.00' COMMENT '当前库存数量',
  `locked_quantity` decimal(10,2) NOT NULL DEFAULT '0.00' COMMENT '锁定数量（预留）',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_item_id` (`item_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用品库存表';

这里面的locked_quantity字段是我后来加的，用途是处理“出库单申请但还没审核”的场景。申请出库时先锁定库存，审核通过后扣减正式库存并释放锁定，审核驳回则直接释放锁定。这样做的好处是：库存看板上的可用库存永远是quantity - locked_quantity，不会出现一个还没通过的出库单把库存先“预支”掉的情况。如果不做这个设计，就容易出现两张申请单同时看上同一批库存，审核的时候才发现实际库存不足的尴尬局面。

另外说一个很小但很实际的点：所有表的排序规则统一使用utf8mb4_general_ci。因为有些同学的数据库连接串没设置characterEncoding=utf8，结果插入中文变成乱码，排查一圈发现是驱动版本和库表排序规则不匹配。统一utf8mb4不仅兼容正常的字符，连表情符号都能存，比较稳妥。

4. 核心功能模块的代码落地：从出库单到库存扣减的完整链路

数据库设计好之后，代码层面的核心任务就是把“库存变化”这条链路跑通。我挑三个最有代表性的功能来讲：出库单审核扣库存、库存预警、月度统计报表。

出库单审核扣减库存是这个系统业务逻辑最重的一个操作，核心点在于“事务”和“行锁”。用户提交出库申请后，管理员点审核通过，系统要执行两步操作：一是更新出库单状态，二是扣减库存。这两步必须放在同一个事务里，否则就会出现出库单状态是“已审核”但库存没扣减的脏数据。

扣减库存的SQL不是简简单单的update stock set quantity = quantity - #{num} where item_id = #{itemId}，因为这样写在高并发场景下有超卖风险。更稳妥的写法是：

sql复制UPDATE stock
SET quantity = quantity - #{num},
    update_time = NOW()
WHERE item_id = #{itemId}
  AND quantity >= #{num};

这条SQL的巧妙之处在于把“库存是否充足”的判断放在了数据库层面，一次原子操作就完成了“检查+扣减”。如果受影响行数为0，就说明库存不足，业务层抛出异常，事务回滚，出库单状态也不会被误改。

Service层代码大概长这样：

java复制@Transactional(rollbackFor = Exception.class)
public void auditStockOut(List<StockOutItem> items) {
    for (StockOutItem item : items) {
        int rows = stockMapper.deductStock(item.getItemId(), item.getQuantity());
        if (rows == 0) {
            throw new ServiceException("库存不足，用品ID: " + item.getItemId());
        }
    }
    stockOutMapper.updateStatus(outId, StockOutStatus.AUDITED);
}

记住一个关键点：事务方法里不要try-catch吞掉异常，要让异常冒泡到@Transactional的切面才能触发回滚。如果是自己抛出的业务异常，记得指定rollbackFor = Exception.class，因为Spring默认只回滚RuntimeException，如果你的异常继承的是Exception而不指定rollbackFor，事务不会回滚，能坑一晚上。

库存预警的实现逻辑相对简单。预警阈值可以做成全局默认值+单用品自定义阈值，在alert_config表里存每个用品的最低库存线。查询预警列表时写一条带LEFT JOIN的SQL，把所有当前库存低于阈值的用品捞出来，再按缺口数量排序，让库管一眼看到最该补货的物品。在列表页面，低于阈值的行高亮标红，这里我用了一个简单判断：

javascript复制row.quantity < row.lowThreshold ? 'row-danger' : ''

如果想让系统更智能一点，还可以加一个定时任务，每天上班前自动扫描库存清单，把库存不足的用品汇总成一条待办消息推给管理员。这个功能用@Scheduled注解就能实现，不复杂，但写进论文里可以让“系统设计”章节显得更完整。

月度统计报表是另一个在论文里可以重点展示的模块。按月份统计“入库总量”“出库总量”“各部门消耗排行”“供应商供货金额排行”这类指标。实现上不一定要引入复杂的报表引擎，几条聚合SQL加ECharts的前端展示就够用了。比如统计近6个月的月度采购金额：

sql复制SELECT
    DATE_FORMAT(si.create_time, '%Y-%m') AS month,
    SUM(sii.amount) AS total_amount
FROM stock_in si
JOIN stock_in_item sii ON si.id = sii.stock_in_id
WHERE si.create_time >= DATE_SUB(NOW(), INTERVAL 6 MONTH)
GROUP BY DATE_FORMAT(si.create_time, '%Y-%m')
ORDER BY month;

拿到这个结果后，前端用ECharts画一个柱状图或者折线图，效果会很直观。答辩时老师基本都会问一句“统计报表是怎么实现的”，这时候你从容地讲一下SQL聚合和图表渲染的过程，比背概念有用得多。

5. “附源码”项目的代码组织经验：不要把手写代码变成整理代码

既然标题里带了“附源码”，那就一定要谈代码组织。评审老师拿到你的源码后，第一眼不一定会去搜某个功能好不好用，但一定会看你的目录结构和代码规范。我见过太多功能正常但代码一团糟的项目：Service层几百行一个方法、Controller里塞SQL、没有统一的返回结构、异常处理散落各处。这种项目就算功能全通，答辩印象分也会大打折扣。

我的建议是严格遵循经典分层架构，并让包名结构一目了然：

code复制com.example.hotel
├── common
│   ├── result.Result
│   ├── result.ResultCode
│   ├── exception.BusinessException
│   └── exception.GlobalExceptionHandler
├── config
│   ├── MybatisPlusConfig
│   └── WebMvcConfig
├── controller
├── service
│   ├── impl
├── mapper
├── entity
├── dto
└── vo

common包里统一放返回结果、错误码、全局异常处理器。所有Controller接口一律返回Result<T>，前端拿到{ code: 200, message: "success", data: ... }这种结构后再决定渲染逻辑。全局异常处理器把异常转换为统一的错误响应，不要在Controller里到处写try-catch。这是很多公司里实际项目的标准做法，用在毕设里不仅规范，答辩时还能讲出“统一响应模型”和“全局异常处理”两个亮点。

我特意拿出下面这个示例，是我在项目里写的统一返回类，你写的时候可以参考这种结构：

java复制@Data
public class Result<T> {
    private Integer code;
    private String message;
    private T data;

    public static <T> Result<T> success(T data) {
        Result<T> result = new Result<>();
        result.setCode(200);
        result.setMessage("success");
        result.setData(data);
        return result;
    }

    public static <T> Result<T> error(String message) {
        Result<T> result = new Result<>();
        result.setCode(500);
        result.setMessage(message);
        return result;
    }
}

代码规范上还有几个实际体验很好的小细节：实体类用Lombok的@Data注解省去getter/setter；DTO和VO要区分清楚，接收前端参数用DTO，返回前端数据用VO，不要直接把实体类抛给前端；Mapper层的复杂查询SQL写XML还是注解看个人习惯，但建议保持统一，我的习惯是简单的单表查询用MyBatis Plus的Wrapper，超过三张表的关联查询写XML，这样不同场景都能找到最清晰的表达方式。

再列几个我实际开发中踩过的代码级大坑，这些在答辩现场经常被问到，提前准备好答案：

• MyBatis Plus分页查询返回的总数一直是0。这个坑很经典，原因是没有配置分页插件。光引入MyBatis Plus依赖还不够，必须注册MybatisPlusInterceptor并添加PaginationInnerInterceptor，否则分页SQL根本不会生效。
• LocalDateTime返回给前端变成了数组。因为Jackson默认序列化时把LocalDateTime转成了类似[2025, 5, 20, 10, 30, 0]的结构。解决方式是在application.yml里配置：

yaml复制spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

• insert时自动填充的创建时间没有赋值。如果用MyBatis Plus自动填充，需要在实体类的create_time字段上加上@TableField(fill = FieldFill.INSERT)，并且实现MetaObjectHandler处理器。如果不用自动填充，就直接依赖数据库默认值，不要混用，否则有的人插入的语句里带了create_time为null，数据库默认值反而失效了。

6. 从本地到部署：jar包启动、服务器配置和那些文档里不说的细节

毕设做完以后，总归要跑起来给老师演示。虽然本地IDE里点一下启动按钮很方便，但很多人一到部署环节就翻车。这里把从本地到服务器的完整路径讲清楚。

首先，打包方式默认用mvn clean package -DskipTests，生成的可执行jar包在target目录下。Spring Boot内置了Tomcat，所以不需要额外安装容器环境，服务器上只要有JDK8+就够了。启动命令也很简单：

bash复制nohup java -jar hotel-system.jar --spring.profiles.active=prod > app.log 2>&1 &

这里我特意用了--spring.profiles.active=prod，意味着在application-prod.yml里配置生产环境的数据库连接、Redis地址等信息。本地开发和服务器部署用不同的profile切换配置，既安全又清晰。很多同学把所有环境配置都写在application.yml里，在服务器上跑之前还要手动改数据库地址，这既不优雅也容易漏改。

数据库连接串中有几个参数非常关键，漏了很容易踩坑：

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/hotel_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true
    username: root
    password: yourpassword
    driver-class-name: com.mysql.cj.jdbc.Driver

这里面的useSSL=false和serverTimezone=Asia/Shanghai基本是必配的。前者避免MySQL 8.0在SSL握手时报警告或者报错，后者避免时区差8小时导致时间错乱。注意MySQL 8.0的驱动类名是com.mysql.cj.jdbc.Driver，不是以前老版本那个com.mysql.jdbc.Driver，写错启动直接失败。

服务器上还有一个高频问题：本机可以访问，但外网访问不通。排查链路通常是：先确认jar包进程在跑，再确认端口是否被防火墙拦截。

bash复制firewall-cmd --zone=public --add-port=8080/tcp --permanent
firewall-cmd --reload

如果云服务器，还要去安全组里放行8080端口。很多同学本地一切正常，部署到云上却访问不了，十有八九是安全组规则没有配置。

关于部署形态，其实我还建议你提前考虑一个问题：是单机部署一个jar包，还是用Docker跑容器。如果只是给老师和评委演示，单机jar包完全够用，可靠性也不需要苛求。但如果你想在论文的“系统部署”章节里多写一点内容，用Dockerfile构建镜像、用docker-compose up -d一键启动MySQL+Redis+Java应用，会是一个不小的加分项。展示一下自己会容器化部署，在本科毕设里属于比较突出的能力了。

7. 答辩前一定要准备的功能演示路径：让评委跟着你的思路走

最后聊聊答辩环节。很多同学系统功能做得很全，但演示的时候东点一下西点一下，评委看完一脸懵，也不知道该问什么。我建议提前设计一条演示主线，按“基础数据维护→业务单据流转→库存变化→统计报表→权限控制”这条顺序走下来。

第一步，以管理员身份登录系统，进入“用品分类”和“用品信息”模块，先展示怎么新增一个用品分类和一条用品信息。这环节讲清楚“基础数据为后续业务单据提供了可选范围”，让评委知道这些数据是后面一切操作的前提。

第二步，进入“入库管理”，创建一张入库单，添加刚才新建的用品，填写数量和单价，提交审核。然后切到库存列表，展示该用品的库存数量已经从0变为了入库数量。这里一定要展示“操作前”和“操作后”的对比，评委能看到数据变化才觉得系统靠谱。

第三步，模拟库存不足的情况。把某个用品的预警阈值调高，或者出库数量设置超过当前库存，演示系统如何拒绝扣减并给出提示。这个环节防超卖和库存预警的亮点一下就出来了。

第四步，进入“统计报表”，选择近一个月的出入库趋势，展示柱状图或折线图，说明这些图表的数据来源是哪些表、用到了什么SQL聚合。把每张表之间的关联关系说清楚，评委对你的数据库设计会有一个完整的印象。

第五步，用一个新的普通账号登录，演示他看不到系统管理菜单、只能操作自己权限范围内模块，展示权限控制的实际效果。这个环节非常加分，但前提是你的user表里确实做了角色字段，并且后端接口也做了相应的权限校验。

答辩问答环节还有一个高频问题：“这个系统最大的难点是什么，你是怎么解决的？”不要慌，可以讲“多表关联下的库存扣减一致性”，把事务和行锁的解决方案讲清楚；或者讲“出库单审核流程中的状态流转”，把状态机设计思路讲明白。这些都是你在开发过程中真正思考过的问题，讲起来自然有底气。

8. 后续还能怎么扩展：从毕设到拿得出手的完整项目

系统交付并不意味着项目就结束了。如果你时间充裕，或者想把项目放到简历上作为找工作的项目经历，我强烈建议在现在的系统基础上做两个方向的扩展，性价比很高。

方向一：移动端适配或小程序端。不需要全新开发，把“库存查询”“入库登记”“出库申请”这几个核心功能做成小程序界面，后端复用现有接口，顶多补充几个针对移动端的接口。这样项目从单一Web端变成了Web+小程序双端，简历上可以写“多端适配”和“前后端分离架构”，含金量立马不一样。

方向二：对接扫码设备。宾馆用品出入库如果每次都是手动搜索物品再填写数量，体验确实不怎么样。引入二维码扫码模块，每个用品打印单独的二维码标签，出入库时直接用扫码枪或者手机摄像头扫一下，系统自动识别用品编码并带入本次单据。这个功能听起来不高深，但非常贴近真实业务场景，而且完全能在这个系统上平滑扩展。

无论是往哪个方向发展，核心的Spring Boot后端架构不需要推倒重来，这本身就验证了这套选型的设计冗余是够的。我见过很多同学把毕设做完就扔在一边，其实只要再花几天时间做一两个这样的扩展，写简历和初筛的时候就能多出很多谈资，面试官问你项目细节时你能讲的东西也远比一个普通CRUD系统丰富得多。