Spring Boot网上租赁系统毕设：从数据库设计到订单状态机完整实现

又到一年毕设季，每年这个时候都有不少同学在后台问我选题的事。说实话，"网上租赁系统"这类题目几乎是年年都会出现的常青树，原因很简单——它业务场景真实、功能边界清晰、技术栈主流，而且做完之后能讲的东西很多。一套基于 Spring Boot 的租赁系统，既能覆盖增删改查这些基本功，又能涉及订单状态流转、库存并发扣减、定时任务这类有含金量的点，用来做毕设非常合适。这篇文章就把这套系统从设计到实现完整拆一遍，包括数据库设计、核心业务逻辑、环境配置流程，以及我在实际开发中踩过的坑，给准备做毕设或者想快速上手 Spring Boot 项目的同学一个可参考的模板。

1. 租赁系统到底做些什么：从业务梳理到模块拆解

1.1 需求定位：这个系统解决什么问题

很多人拿到题目第一反应是"租赁系统不就是把商品挂上去，然后有人下单嘛"。如果只做到这一步，那这个系统也就停留在 CRUD 层面，答辩的时候根本扛不住问。我们先想清楚一件事：线下租赁场景的真实痛点是什么。

租东西和买东西最大的区别在于"物要归还"。线下租一本书、租一套工具、租一辆车，核心要管三件事：东西现在在谁手里、什么时候该还、还回来的时候有没有损坏。所以网上租赁系统的本质不是电商，而是一套"借出—归还—结算"的闭环管理工具。用户把物品发布到平台上，租客浏览并下单，系统记录租赁周期，到期后确认归还，按实际情况完成押金抵扣和结算，这才是一个完整的业务闭环。

围绕这个闭环，系统的核心模块就清晰了：用户与权限、物品管理、租赁订单、归还结算、公告与留言。每一项都有明确的业务意义，不存在为了凑功能硬加的情况。

1.2 角色权限与核心业务流转

在设计权限时我建议采用两级角色：管理员和普通用户，不要急着搞商家、平台运营一堆角色。毕设的核心是讲清楚业务逻辑，角色越多代码越乱，答辩时反而说不清楚。我见过太多人把系统功能表列得特别长，实际代码里全是一堆半成品页面，这个观感非常差。

普通用户能做的事：注册登录、浏览物品、发布闲置租赁物品、下单租用物品、确认归还、查看自己的订单列表、留言评论。管理员能做的事：用户管理、物品审核与上下架、所有订单的查看与干预、公告发布。

核心业务流转可以归纳为一条主线：用户发布物品 → 物品上架 → 另一用户下单租用 → 支付（模拟） → 物品处于租用状态 → 到期归还 → 租金结算、押金处理 → 订单完成。这条主线就是系统中最值得讲的业务逻辑，后面第 3 部分我会详细展开。

1.3 功能模块清单

为了便于落地，我把功能拆成一张表，开发的时候对照着做，避免漏项：

这个模块清单覆盖了"用户、物品、订单、交互"四个层面，既有核心业务又有周边设施，作为毕设的功能体量刚刚好，既不会单薄到显得没工作量，也不至于战线拉太长做不完。

2. 技术选型和数据库设计：为什么这样搭最稳

2.1 版本组合：Spring Boot 2.7 + JDK 8 为什么是首选

说到技术栈，先解决一个最重要的选择题——用哪个版本的 Spring Boot。现在网上搜教程，搜到 Spring Boot 3.x 和 2.x 的结果各占一半，很多同学一上来就装最新的，结果到处报错。我的建议非常明确：毕设老老实实用 Spring Boot 2.7.x + JDK 1.8。

原因有三个。第一，JDK 8 是当前生产环境占有率最高的版本，技术栈基础最稳；第二，Spring Boot 2.7 的教程、博客、视频资料最多，遇到问题随便一搜就有答案；第三，Spring Boot 3.x 把 javax 包迁移到了 jakarta，这个命名空间的变动会让很多老代码直接编译失败，新手排查起来非常痛苦。

依赖版本选定之后，核心依赖就这么几个：Spring Boot 2.7.14、MyBatis-Plus 3.5.x、MySQL 8.0（也可以是 5.7）、Lombok，前端模板用 Thymeleaf 或者直接 Spring Boot 返回 JSON + 简单页面。我个人推荐不要强行拆前后端分离，毕设时间有限，单体应用加模板引擎或者直接一个简洁的 HTML 页面集合，足够展示能力。如果后期想加分，用 Vue 单独写一个前端页面来对接接口，那是后话，先把后端跑通。

2.2 表结构设计：五张核心表

数据库设计是答辩时的重点提问区域，这里不能含糊。我设计的这套结构，源于一个非常朴素的思考过程：系统里有谁参与、他们要操作什么数据、这些数据之间的关系是什么。

用户表 user 管的是登录账号和基本资料：

sql复制CREATE TABLE `user` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `username` varchar(50) NOT NULL COMMENT '登录账号',
  `password` varchar(100) NOT NULL COMMENT '密码（BCrypt加密）',
  `nickname` varchar(50) DEFAULT NULL COMMENT '昵称',
  `phone` varchar(20) DEFAULT NULL COMMENT '联系电话',
  `role` tinyint(4) NOT NULL DEFAULT '2' COMMENT '角色：1管理员，2普通用户',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

物品表 item 管的是租赁物品信息，注意要有发布者外键、每日租金、押金、库存和上下架状态：

sql复制CREATE TABLE `item` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `user_id` bigint(20) NOT NULL COMMENT '发布者ID',
  `title` varchar(100) NOT NULL COMMENT '物品名称',
  `description` text COMMENT '物品描述',
  `price` decimal(10,2) NOT NULL COMMENT '每日租金',
  `deposit` decimal(10,2) NOT NULL DEFAULT '0.00' COMMENT '押金',
  `stock` int(11) NOT NULL DEFAULT '1' COMMENT '可租库存',
  `image` varchar(200) DEFAULT NULL COMMENT '物品图片',
  `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态：1上架，0下架',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

订单表 rent_order 是最核心的一张表，记录每一次租赁行为，状态字段我会单独定义：

sql复制CREATE TABLE `rent_order` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `order_no` varchar(32) NOT NULL COMMENT '订单编号',
  `item_id` bigint(20) NOT NULL COMMENT '物品ID',
  `user_id` bigint(20) NOT NULL COMMENT '租客ID',
  `days` int(11) NOT NULL COMMENT '租赁天数',
  `total_amount` decimal(10,2) NOT NULL COMMENT '租金总额',
  `deposit_amount` decimal(10,2) NOT NULL COMMENT '押金金额',
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '状态：0待支付，1租赁中，2待归还，3已完成，4已取消',
  `start_time` datetime DEFAULT NULL COMMENT '租赁开始时间',
  `end_time` datetime DEFAULT NULL COMMENT '租赁结束时间',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_order_no` (`order_no`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

另外还有公告表 announcement 和留言表 message，结构相对简单，前者管理标题内容和发布时间，后者记录用户对物品的评论关联物品 ID，这里不再赘述 SQL。

关于金额字段，有一点必须强调：不用 float 和 double，一律用 decimal(10,2)。浮点数在计算金额时有精度丢失问题，涉及钱的数据绝不能有误差。这是我反复跟做毕设的同学强调的一点，也是答辩时一个很好的加分细节。

2.3 代码分层：单模块或者多模块都行，重点是职责单一

对于这个体量的项目，我推荐用 Spring Boot 标准的单模块结构，按 controller / service / mapper / entity 四层分包，这是最经典也最容易理解的结构。

我的项目结构是这样的：

code复制com.example.rental
├── controller        # 控制层，接收请求
├── service           # 业务层，核心逻辑
│   └── impl          # service 实现类
├── mapper            # MyBatis-Plus Mapper 接口
├── entity            # 实体类
├── config            # 配置类（跨域、拦截器等）
├── common            # 通用类（返回结果、异常处理、常量）
└── RentalApplication.java   # 启动类

实体类用 Lombok 的 @Data 注解自动生成 getter/setter，Mapper 接口继承 BaseMapper<T>，基础的增删改查就全有了。业务层写核心逻辑，控制层只做参数接收和返回封装。这个分层一开始可能觉得多此一举，但到后期调 bug 的时候就能体会到好处——知道问题在哪一层，就直接进那层去找，不用满项目翻。

3. 核心业务从下单到归还的完整实现

3.1 订单状态机设计：避免代码越写越乱

订单是最容易写乱的模块，关键就是状态管理没有提前设计。我的办法是先定义清晰的状态常量，定死流转规则。

状态有五个：待支付、租赁中、待归还、已完成、已取消。流转规则是这样的：

• 创建订单 → 待支付，用户取消则进 已取消，模拟支付成功后进 租赁中
• 租赁中的订单，到达归还日进入 待归还（或者说这里的含义是"租期结束、等待双方确认归还"）
• 用户确认归还或管理员确认归还后 → 已完成
• 任何未支付状态的订单，超时之后可以由用户主动取消，管理端也可以强制取消

把这套状态流转画成一张状态图（答辩的时候可以直接用手画，不需要任何工具），代码里的逻辑就非常清晰了。我在 OrderStatusEnum 里定义常量，然后用 switch 或 if 判断当前状态决定下一步操作，避免出现订单能从这个状态跳到任意另一个状态的失控局面。

3.2 下单与金额计算：并发扣库存的正确写法

下单接口是核心中的核心。每笔订单要算租金总额：totalAmount = price * days，押金直接取物品的 deposit 字段。这个计算不要在前端完成，前端传过来的金额一律不信任，后端根据数据库里的物品单价重新计算，这一点是金融级系统的基本素养，也是答辩加分项。

下单时的库存扣减，我见过太多人这样写：先 select 出库存，判断大于 0，然后 update 减一。这样写在小流量下没问题，但并发场景下会超卖，因为两个请求同时读到库存为 1，都往下走了。

正确做法是用一条 SQL 完成"判断 + 扣减"：

sql复制UPDATE item SET stock = stock - 1 WHERE id = #{itemId} AND stock > 0

用 MyBatis-Plus 执行这条更新语句，返回值是受影响的行数。如果返回 1 说明扣减成功，返回 0 说明库存不足，直接抛出业务异常，提示"该物品库存不足"。这个过程是原子的，数据库的行锁保证了不会超卖。

对应的 Service 关键代码大概是这样的：

java复制@Override
@Transactional(rollbackFor = Exception.class)
public RentOrder createOrder(Long itemId, Long userId, Integer days) {
    // 1. 查询物品信息
    Item item = itemMapper.selectById(itemId);
    if (item == null || item.getStatus() != 1) {
        throw new BusinessException("物品不存在或已下架");
    }
    // 2. 原子扣减库存
    int rows = itemMapper.deductStock(itemId);
    if (rows == 0) {
        throw new BusinessException("库存不足");
    }
    // 3. 构建订单，状态设为待支付
    RentOrder order = new RentOrder();
    order.setOrderNo(generateOrderNo());
    order.setItemId(itemId);
    order.setUserId(userId);
    order.setDays(days);
    order.setTotalAmount(item.getPrice().multiply(BigDecimal.valueOf(days)));
    order.setDepositAmount(item.getDeposit());
    order.setStatus(0);
    rentOrderMapper.insert(order);
    return order;
}

注意方法上的 @Transactional 注解——扣库存和创建订单是两个数据库操作，要么都成功，要么都失败，绝对不能出现库存扣了但订单没建成的脏数据。这个点也要在答辩时主动讲出来，老师一听就知道你理解事务。

3.3 归还结算与押金处理逻辑

到了归还环节，要处理的事情就多了。用户发起归还，系统要判断是否超期。如果当前时间晚于 end_time，就产生滞纳金，从押金里扣除，剩余押金退回（这里我们用模拟金额，不接入真实支付渠道），然后订单状态变为已完成。

判断超期需要用到 LocalDateTime 的比较：

java复制public void confirmReturn(Long orderId, Long userId) {
    RentOrder order = rentOrderMapper.selectById(orderId);
    // 校验订单归属和状态
    if (!order.getUserId().equals(userId)) {
        throw new BusinessException("无权限操作该订单");
    }
    if (order.getStatus() != 2) {
        throw new BusinessException("当前订单状态不允许归还确认");
    }
    LocalDateTime now = LocalDateTime.now();
    BigDecimal penalty = BigDecimal.ZERO;
    if (now.isAfter(order.getEndTime())) {
        long overdueDays = ChronoUnit.DAYS.between(order.getEndTime(), now);
        if (overdueDays <= 0) {
            overdueDays = 1;
        }
        penalty = order.getDepositAmount() // 滞纳金，示例为每天押金的10%
                .multiply(BigDecimal.valueOf(0.1))
                .multiply(BigDecimal.valueOf(overdueDays));
    }
    // 模拟退还押金：押金 - 滞纳金
    BigDecimal refundAmount = order.getDepositAmount().subtract(penalty);
    order.setStatus(3); // 已完成
    rentOrderMapper.updateById(order);
    // 释放库存
    itemMapper.addStock(order.getItemId());
    // 实际项目中此处应调用支付平台退款接口
    log.info("订单 {} 归还完成，退还押金 {}", order.getOrderNo(), refundAmount);
}

这段代码里有几个细节：第一，归还成功后要恢复库存，否则物品会凭空消失；第二，超期天数计算时如果差不足一天要按一天算，否则用户超期 3 小时不用付任何滞纳金，规则会形同虚设；第三，归还操作要校验订单归属和当前状态，防止用户操作别人的订单，或者重复归还。

3.4 超期订单的定时任务：让系统自动发现问题

订单超期不能光靠用户自觉归还，需要一个定时任务每天扫描一次，把所有"租赁中且已过 end_time"的订单状态改为"待归还"，同时给用户发送站内通知，这样系统才算是"活"的。

Spring Boot 里做这个非常简单，一个注解就搞定：

java复制@Component
@Slf4j
public class OrderOverdueTask {

    @Resource
    private RentOrderMapper rentOrderMapper;

    @Scheduled(cron = "0 0 2 * * ?")
    public void processOverdueOrders() {
        List<RentOrder> overdueOrders = rentOrderMapper.selectList(
                new LambdaQueryWrapper<RentOrder>()
                        .eq(RentOrder::getStatus, 1) // 租赁中
                        .lt(RentOrder::getEndTime, LocalDateTime.now())
        );
        for (RentOrder order : overdueOrders) {
            order.setStatus(2);
            rentOrderMapper.updateById(order);
            log.info("订单 {} 超期，已更新为待归还状态", order.getOrderNo());
        }
    }
}

用 LambdaQueryWrapper 条件构造器结合 .lt() 方法，查所有结束时间小于当前时间的租赁中订单，一次性更新状态。定时任务建议定在凌晨 2 点跑，避开用户操作高峰。

使用定时任务之前记得在启动类上加 @EnableScheduling 注解开启支持，漏掉这个细节的人非常多。另外，定时任务的 cron 表达式也可以换成 Spring 的 interval 参数，但 cron 表达式的可读性明显更好，维护起来也更方便。

4. 从零跑通项目：环境配置与启动细节

4.1 环境准备：版本匹配是第一步

拿到源码之后，第一步不是直接打开 IDEA 点运行，而是先检查本机环境。这个项目基于 Spring Boot 2.7，要求 JDK 8 及以上、Maven 3.6 以上、MySQL 5.7 或 8.0、IDEA 2020 及以上版本。

这里最常出现的坑是 JDK 版本不匹配。如果你的电脑之前装过 JDK 17 甚至更高，项目的编译级别还停留在 8，IDEA 会报一堆奇怪的错误。热词里那个"java: 警告: 源发行版 17 需要目标发行版 17"就是指这个——本机 JDK 是 17，但项目里的 pom.xml 指定的 source/target 是 8，两边对不上。

解决办法是在 IDEA 里同时检查三处地方：项目结构里的 Project SDK 和 Language Level、Settings 里的 Java Compiler 的 -parameters 与 target bytecode version、Maven 的 settings.xml 里的 JDK。确保全部统一为 8，IDEA 的 Maven 面板里再 Reload All Projects 一次，基本就能解决。

4.2 核心配置文件：这些参数必须改

项目里的 application.yml 是启动的关键，90% 的启动失败都出在这。数据库连接串、用户名、密码必须改成你自己的：

yaml复制server:
  port: 8080

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/rental_system?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
    username: root
    password: 123456
  servlet:
    multipart:
      max-file-size: 10MB

mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

有几个点要特别说明。serverTimezone=Asia/Shanghai 一定要配，否则 MySQL 8.0 会报时区错误。useSSL=false 是开发环境省去安全握手的提示。log-impl 配置成 StdOutImpl 后，控制台会打印每条 SQL，开发调试时能看到实际执行的语句，排查问题特别方便，但是上线前要记得关掉。

另外 password 字段如果你本机 MySQL 设置了密码，就改成你自己的，这看着是废话，但每年都有同学问我为什么连不上数据库，最后发现是把别人的配置原样留下了。

4.3 初始化数据库与启动验证

数据库初始化步骤很简单。先在 MySQL 里创建数据库：create database rental_system default character set utf8mb4;。然后执行项目里附带的 sql/init.sql 脚本，建表、插入测试数据（包括管理员账号和几个样例物品）。

启动流程是：用 IDEA 打开项目 → 等待 Maven 依赖下载完成 → 修改配置文件里的数据库账号密码 → 运行 RentalApplication.java 的 main 方法 → 控制台出现 Started RentalApplication 即为成功。

启动成功之后，建议先测试几个关键接口，别急着写代码。比如 POST /api/user/login 发一个登录请求，看能不能正常返回 token；GET /api/item/page?page=1&size=10 看物品分页是否正常；再测一个下单接口看订单状态流转是否正常。把核心链路验证通了，后面的开发才安心。

5. 高频报错与排查实录

5.1 版本过高和 JDK 编译组错误

这是遇到最多的一类问题。Spring Boot 的版本选择和 JDK 版本强相关：Spring Boot 2.x 系列跑在 JDK 8 上没有任何问题，但如果你下载的是 Spring Boot 3.x 的代码，那就必须用 JDK 17 或更高版本启动。热词里说的"springboot版本太高"，本质上就是这个矛盾。

我建议所有毕设场景都把目标锁定在 Spring Boot 2.7.x + JDK 8，不要为了追新给自己挖坑。如果已经下载了高版本的项目，有两个选择：一是退回到低版本（对毕设来说成本最低），二是在 pom.xml 里把 <java.version> 改成 17 并把所有 javax 改成 jakarta（工作量不小，不建议新手碰）。

5.2 循环依赖导致的启动失败

Spring Boot 2.6 开始，默认不允许循环依赖，报错信息是 The dependencies of some of the beans in the application context form a cycle。网上很多老项目的代码可能在 2.5 及以前能跑，到了 2.6 直接挂了。

出现循环依赖说明 Service 之间的引用关系设计不合理，比如 OrderService 里面注入了 UserService，而 UserService 又注入了 OrderService。正确的解法是重构，把相互调用的逻辑抽离到第三层，或者用事件机制解耦。临时方案是在 application.yml 里允许循环依赖，但这只是暂时绕过，不建议用到毕设里，答辩时被问到会很尴尬。

5.3 MySQL 连接异常导致的启动失败

这类报错的特征很明显，启动日志里出现 Cannot create PoolableConnectionFactory。原因不外乎几个：MySQL 服务没启动、端口不是默认的 3306、账号密码不对、时区配置缺失。

排查思路从日志入手，URL 里的库名是否存在，账号是否能登录 MySQL，防火墙是否拦截了端口。本地开发基本就是前两种，改对 application.yml 里 url、username、password 三项就解决了。

5.4 Lombok 与 JDK 新版本的兼容问题

如果在 IDEA 里看到"you aren't using a compiler supported by lombok, so lombok will not work with your project"这类的提示，说明 Lombok 版本和你用的 JDK 不匹配。JDK 8 + Lombok 1.18.20 的搭配是经过大量项目验证的稳定组合。如果你用了 JDK 17，需要把 Lombok 升级到 1.18.30 或更高，否则 @Data 生成的 getter/setter 会失效，编译期不报错但运行时空指针满天飞。

口诀就是：版本组合要对齐，缺了什么先看版本，再查代码。很多报错表面上五花八门，根因都是版本不匹配。

5.5 端口占用与资源不够

启动时提示 Port 8080 was already in use，说明本机 8080 端口被其他进程占了。要么换个端口，要么找到占用进程关掉。命令行里 netstat -ano | findstr 8080 可以查到 PID，Windows 的 taskkill /PID xxx /F 直接结束。这里我不展开细说，属于非常基础的问题。

另外如果项目启动很慢或者卡住不动，看一下 Db 数据库是否真的建好了。之前有同学启动没有任何报错但访问页面一直转圈，最后发现控制台显示找不到 rental_system 数据表——就是因为建库脚本没执行。

6. 几个拿来即用的加分功能（可选）

如果你的毕设想要有点亮点，在把基础功能跑通之后，可以选一两个方向做扩展，但注意优先级：先把主链路稳定，再做加法。

第一个推荐加分点是图片上传。物品发布时上传图片是最常见不过的需求，用 Spring Boot 的 MultipartFile 接收文件，存到本地某个目录，再把访问路径存到数据库，配合一个静态资源映射配置就能实现。代码量不大但是非常实用，答辩展示效果好。

第二个是数据图表统计。管理员后台用 ECharts 做一个简单的柱状图或饼图，展示每个月的租赁订单量、热门租赁物品 TOP5。后端提供一个统计接口，前端用图表库渲染，前后端联动的效果会让项目整体观感提升一个档次。

第三个是登录验证码。用 HUTOOL 工具库里的 CaptchaUtil 生成图形验证码，登录时校验。这个功能在电商系统和运营后台中很常见，做进去之后可以讲"系统安全性"的话题，比干巴巴地说密码用了 BCrypt 加密要自然得多。

第四个方向是Excel 导出订单报表。用 EasyExcel 库把订单列表导出成 Excel 文件，方便管理员做线下留档。同样是工具集成类功能，代码量不大但内容很充实。

做这些扩展功能的时候，记得遵循一个原则：每个功能都要能讲清楚它解决了什么业务问题。不要为了凑功能而堆代码，答辩的时候老师问"这个功能有什么用"，你能给出一个合理的业务场景，这就是加分项。

写在最后

这套基于 Spring Boot 的网上租赁系统，核心价值不在于代码多复杂，而在于业务流程完整、模块边界清晰、技术选型务实。从设计之初的数据库建模，到订单状态的流转控制，再到并发扣库存、超期定时任务这些细节，每一步都有明确的业务驱动，正是这样的设计思路让它在毕设答辩中站得住脚。

我个人在实际操作中的体会是：拿别人的源码跑通只是第一步，真正吃透一个项目，一定要看完核心模块的每一行代码，然后自己动手改几个功能。你可以试试把滞纳金的规则改成一个更复杂的阶梯计费，或者新增一个"收藏物品"的功能，这些改造会让你对系统的理解完全不同。当你对订单状态流转、库存扣减这些细节都能张口就来的时候，这个项目才是真正属于你的东西。源码本身是免费的，但通过它学到的设计思路和排查问题的方法，才是花钱买不来的收获。