医疗设备租赁管理系统SpringBoot实战：从表结构到部署全解析

1. 这个系统到底在解决什么问题

1.1 医疗设备租赁的典型业务场景

医疗设备租赁管理系统，这个名字在计算机毕业设计里出现频率相当高，尤其当成型为“SpringBoot + 源码30036”这套组合时，几乎已经变成一种标准参考。第一次看到这个题目，可能觉得无非就是后台增删改查，但真正把租赁业务跑通之后会发现，这里面的状态流转、费用计算、库存联动，比图书管理系统复杂一个层级，也更有训练价值。

实际业务中，医疗器械公司、医院辅助科室、第三方检测机构都会遇到短期设备使用需求。一台中大型医疗设备采购成本高，科室如果只是临时用两三个月，直接买新设备不划算；而设备经营企业也需要把自己闲置的设备盘活，提升利用效率。于是租赁这种模式就出现了：设备出库、签合同、收押金、按天或按月计费、到期归还、续租、逾期处理、维修保养，这些动作如果靠表格管理，很容易出现漏单、错算、状态不一致的情况。

1.2 毕业设计选题为什么要选它

这个题目的优势在于业务闭环完整，技术栈又相对主流。一个合格的系统需要覆盖用户权限、设备档案、客户信息、租赁订单、财务记录、统计报表，几乎把课程里学的数据库设计、面向对象建模、Web开发、前端交互全部用上了。做出来的东西既不是纯理论demo，也不是过于复杂的企业级平台，工作量放在一个毕业设计周期内正好合适。

而且它对“业务逻辑”的要求比普通管理系统高。设备从空闲到已租再到归还，状态不能乱，订单金额不能算错，库存和订单要联动。把这些细节处理清楚，答辩时候能讲的东西非常多。这也是为什么很多人在简历里写“熟练掌握SpringBoot开发”之后，实际问项目细节时容易露馅，因为只做了四张表的简单CRUD，根本经不起追问。如果能把租赁订单的状态流转、费用计算、逾期逻辑讲明白，面试官至少会觉得你是真的做过系统，而不是背了概念。

2. 核心技术选型：SpringBoot方案为什么够用

2.1 后端框架选择的理由

这套系统的技术核心选SpringBoot非常合理，也是当前大多数毕业设计的主流选择。相比传统的SSH或者纯Servlet，SpringBoot把配置大幅简化，内置Tomcat，打一个jar包直接启动，省去繁琐的Web容器部署。对于不追求分布式、面向单机业务的管理系统来说，它足够稳定，生态又成熟，遇到问题随便搜索就有大量资料。

具体版本上，建议用Spring Boot 2.7.x配合JDK 8或11。Spring Boot 3.x虽然新，但要求JDK 17，部分老依赖和新版本兼容性会出幺蛾子，对毕设来说没必要冒险。ORM层可以选MyBatis-Plus，也可以选Spring Data JPA。我个人更推荐MyBatis-Plus，原因很直接：单表增删改查它能自动生成，代码量少，而复杂报表又可以直接写SQL，灵活度高。JPA虽然也能做，但很多人对它的懒加载、级联操作不够熟悉，往往写着写着出现懒加载异常，反而增加排错成本。

2.2 数据库与前端搭配方案

数据库选MySQL 5.7或8.0，这是最稳妥的组合。字符集统一用utf8mb4，否则遇到特殊字符入库会报错或乱码。前端有两种路线：一种是用Thymeleaf做服务端渲染，项目结构简单，不用额外起前端工程；另一种是前后端分离，Vue3加Element-Plus，通过API交互。如果时间充裕，建议选择后者，因为现在企业里的实际开发基本都是前后端分离，答辩展示起来也更像正规项目。

不过前后端分离也意味着要处理跨域、Token鉴权、前端打包部署这些问题。千万别觉得这些是“多余”的东西，它们恰恰是工程能力的体现。比如跨域配置，后端写一个CorsFilter或者在gateway层面统一处理，前端再配一层开发代理，双保险才不会在联调时反复踩坑。

3. 数据库设计：租赁业务的表结构与关键状态机

3.1 核心数据表与字段设计

数据库设计是这个项目的地基。我的建议是不要一上来就写代码，先把表结构画清楚。核心表至少有这些：用户表、角色表、设备分类表、设备表、客户表、租赁订单表、收款记录表、维修保养记录表。

设备表是整个库存管理的基础，字段上除了基本信息，还要带上“日租金、月租金、押金、状态、存放位置”。设备状态这里强烈建议用int类型存枚举code，而不是直接存“空闲”“已租”这种中文，因为中文一旦改了叫法，所有历史数据都变得不可控。

sql复制CREATE TABLE device (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  device_code VARCHAR(50) NOT NULL UNIQUE COMMENT '设备编号',
  device_name VARCHAR(100) NOT NULL COMMENT '设备名称',
  category_id BIGINT COMMENT '分类ID',
  daily_rent DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT '日租金',
  monthly_rent DECIMAL(10,2) DEFAULT 0 COMMENT '月租金',
  deposit DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT '押金',
  status TINYINT NOT NULL DEFAULT 0 COMMENT '0空闲 1已租 2维修 3停用',
  location VARCHAR(100) COMMENT '存放位置',
  create_time DATETIME NOT NULL,
  update_time DATETIME NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='医疗设备表';

租赁订单表需要单独说一下。订单不是简单记录“哪个设备租给谁”，而是要保留计费快照。什么叫计费快照？就是订单创建那一刻的设备租金、押金都要原样存到订单里，不能只存设备ID再去关联设备表查租金。因为以后设备租金可能调整，如果关联查询，历史订单金额就变了，这是业务上的严重错误。

sql复制CREATE TABLE lease_order (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  order_no VARCHAR(32) NOT NULL UNIQUE COMMENT '订单编号',
  customer_id BIGINT NOT NULL COMMENT '客户ID',
  device_id BIGINT NOT NULL COMMENT '设备ID',
  device_name VARCHAR(100) COMMENT '设备名称快照',
  daily_rent DECIMAL(10,2) COMMENT '日租金快照',
  start_date DATE NOT NULL COMMENT '租赁开始日期',
  end_date DATE NOT NULL COMMENT '租赁结束日期',
  actual_return_date DATE COMMENT '实际归还日期',
  total_amount DECIMAL(10,2) COMMENT '应收总金额',
  deposit DECIMAL(10,2) COMMENT '押金金额',
  status TINYINT NOT NULL COMMENT '0待支付 1租赁中 2逾期 3已完成 4已取消',
  remark VARCHAR(500),
  create_time DATETIME NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='租赁订单表';

3.2 租赁状态流转与费用计算逻辑

状态机是整个系统里最容易被忽略但又最重要的部分。设备状态有四种：空闲、已租、维修、停用。订单状态有：待支付、租赁中、逾期、已完成、已取消。两个状态要联动，不能出现设备已经“已租”，订单却是“待支付”这种脏数据。

我习惯把状态流转写成一份清单：

• 创建订单并支付成功后，设备状态从“空闲”改为“已租”，订单进入“租赁中”。
• 超过截止日期还没归还，订单状态改成“逾期”，设备仍然保持“已租”。
• 归还设备且结算完成后，订单状态改成“已完成”，设备状态恢复为“空闲”。
• 设备在空闲状态下发现故障，可以手动改成“维修”，维修完成再改回“空闲”。
• 订单未支付前可以取消，取消后设备不能动，必须保持“空闲”。

费用计算同样要提前约定规则。最常用的算法是按自然日计费，天数公式是结束日期减去开始日期再加1。比如3月1日开始，3月5日结束，实际天数就是5天。租金总额等于日租金快照乘以天数。逾期费用则按超出的自然天数乘以日租金再乘一个整数倍或者1.5倍系数，这笔钱单独记到收款记录里。

注意：所有涉及金额的字段一律使用 DECIMAL，不要用 double，也不要在Java代码里用 Float。金额计算出现0.1加0.2不等于0.3的问题，在答辩现场非常难看。

4. 后端核心模块实现要点

4.1 认证与权限控制

管理系统必须做登录认证，不能直接裸奔。推荐使用Spring Security加JWT的方式。用户表设计得简单一点，分管理员和普通操作员两种角色即可，答辩时不需要搞得像RBAC权限模型那么复杂。但如果表结构里已经有角色表，可以适当做角色和用户的关联，后续扩展菜单权限会方便。

自定义一个JwtUtil工具类，负责生成和解析Token。登录接口校验用户名密码，通过后生成Token返回给前端。Spring Security配置类里放行登录接口，其他接口统一拦截，受保护接口要求请求头携带 Authorization: Bearer xxx。同时写一个自定义UserDetailsService，从数据库查询用户和角色。

java复制@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.csrf().disable()
            .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
            .and()
            .authorizeRequests()
            .antMatchers("/api/auth/login", "/api/captcha").permitAll()
            .antMatchers("/api/admin/**").hasRole("ADMIN")
            .anyRequest().authenticated();
    }
}

当然，如果你的项目用的是Spring Boot 3.x，配置类写法会变成SecurityFilterChain加Lambda风格，但核心思路不变。这里不展开。

4.2 租赁下单与归还结算流程

租赁下单是事务性最强的一个接口，必须加 @Transactional。流程大概是：先校验设备是否存在且状态为空闲，然后根据请求参数计算租金总额，插入订单记录，再更新设备状态为已租。这里最容易出错的是顺序，应该先锁定并校验设备状态，再写订单，最后更新设备。如果把顺序搞反，可能出现订单创建失败但设备已经被置为已租，或者设备被两台机器同时下单的并发问题。

并发问题在毕设答辩中常被问到。最简单可行的做法是利用数据库行锁，在查询设备时使用 SELECT ... FOR UPDATE，保证同一个设备同时只能被一个下单请求拿到。MyBatis-Plus里可以通过自定义SQL实现，也可以使用 @Version 乐观锁。我建议在答辩里讲乐观锁方案，因为它不需要数据库锁等待，思路也更现代。

归还结算是反向流程。根据实际归还日期重新计算金额，生成一条收款记录，然后更新订单状态，把设备状态置为空闲。如果设备在租用期间有维修记录，可以把维修费用一起算进结算单。

java复制public void completeOrder(Long orderId, LocalDate actualReturnDate) {
    LeaseOrder order = leaseOrderMapper.selectById(orderId);
    if (order == null) {
        throw new BusinessException("订单不存在");
    }
    BigDecimal total = calcOrderAmount(order, actualReturnDate);
    order.setActualReturnDate(actualReturnDate);
    order.setTotalAmount(total);
    order.setStatus(LeaseOrderStatus.COMPLETED.getCode());
    leaseOrderMapper.updateById(order);
    deviceMapper.updateStatus(order.getDeviceId(), DeviceStatus.IDLE.getCode());
}

4.3 设备状态管理与库存联动

设备管理模块除了常规增删改查，还要有批量导入、状态变更、维修记录三个功能。批量导入通常用Excel模板，后端解析后逐行校验，校验失败的行要返回错误信息，不能整个文件导入失败。状态变更不是简单改字段，比如设备想从“已租”改成“维修”，系统必须阻止，因为已租设备还在客户手里，不能直接维修。正确的链路是先走归还流程，设备变成“空闲”，再改成“维修”。

维修记录表记录故障描述、维修费用、维修时间、设备ID，这块可以做，也可以简化。但从系统完整度来说加上会好看很多，尤其是统计模块里还能计算维修成本占比。

5. 前端页面与接口对接的操作细节

5.1 页面结构与路由规划

前端用Vue3加Element-Plus，目录结构按模块划分：views、router、store、api、utils。页面至少包括登录页、工作台、设备列表、设备分类管理、客户列表、租赁订单列表、订单详情、财务收款记录、统计报表、用户管理。

路由需要做权限控制，比如普通操作员看不到用户管理页面。这里不需要特别复杂，路由配置里标注需要 ROLE_ADMIN，配合路由守卫判断当前用户角色即可。菜单根据角色动态生成，既要展现在前端菜单里，也要在接口层拦截，防止有人绕过前端直接调接口。

5.2 接口联调常见坑

前后端联调时最容易遇到的问题排序如下：路径不对、跨域、日期格式、Long型精度丢失。

路径建议统一 /api/module/operation 风格。跨域问题，后端写一个CorsFilter，前端Vite开发服务器再配一个proxy，两边都放行，基本不会出问题。日期格式，前后端默认序列化方式不一样，建议后端全局配置Jackson的日期格式，用 LocalDateTime 代替 Date，并通过 @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss") 统一输出。

Long型精度丢失是一个隐藏坑。设备表主键如果直接用 Long 雪花ID，前端JavaScript的 Number 精度不够，超过16位会自动四舍五入，导致最后两位变了，再去查询就会查不到数据。解决办法是在后端JackSon配置里把 Long 转成 String，或者实体主键直接用自增 Long 且关闭雪花ID。毕设用自增ID完全够用，没必要为了炫技引入雪花算法。

6. 从源码到本地运行：部署配置与踩坑记录

6.1 环境准备与配置文件详解

要把这套源码跑起来，环境版本必须对得上。推荐组合：JDK 8或11，Maven 3.6以上，MySQL 5.7以上，Node.js 14以上。有些人代码下载下来启动失败，十有八九是版本问题，比如JDK版本过高导致Lombok报错，或者MySQL驱动版本和数据库版本不匹配。

后端配置文件集中在 application.yml，核心是数据源配置。以下几点尤其要注意：useSSL 必须设为false，serverTimezone 要设置成 Asia/Shanghai，characterEncoding 设成 utf8，否则会出现中文乱码和数据库连接报错。

yaml复制server:
  port: 8080

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/device_lease_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false
    username: root
    password: 123456
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: Asia/Shanghai

mybatis-plus:
  configuration:
    map-underscore-to-camel-case: true
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

数据库初始化一般有一个 sql 目录，先执行 create database device_lease_db;，再选择该库后执行SQL脚本。如果SQL脚本里有中文注释，终端执行时需要确认编码为UTF-8，否则可能出现乱码。

6.2 启动与打包的完整步骤

后端启动有两种方式。开发模式下直接在IDE里运行主类即可。命令行模式下，先执行 mvn clean package -DskipTests，然后运行 java -jar target/device-lease-0.0.1-SNAPSHOT.jar。如果Maven依赖下载特别慢，检查一下本地的settings.xml，配置国内镜像仓库，这个经验能节省大量时间。

前端启动也有固定顺序。先 npm install 安装依赖，如果安装过程报错，可以删除 node_modules 目录重新安装，或者清理npm缓存。开发模式运行 npm run dev，浏览器访问提示的地址。生产环境部署时执行 npm run build，把生成的 dist 目录放到后端的静态资源目录，或者用Nginx托管，再把API请求反向代理到后端端口。

6.3 排查高频报错清单

7. 个人实操体会与后续扩展方向

7.1 做完这个项目最值得留意的几个点

如果只让我说一句话，那就是：先把业务状态流转彻底想清楚，再动手写代码。很多同学看到这个题目就直接建四张表，然后写增删改查，结果做到归还功能时发现订单和设备的联动关系根本对不上，只能回头改表结构，费力不讨好。

费用计算这一块不要在代码里写死规则。把日租金、起租时间和计费方式抽成可配置参数，以后调整规则只需要改配置而不是动代码。金额类型坚持用 BigDecimal，所有除法运算记得指定精度和舍入方式，比如 setScale(2, RoundingMode.HALF_UP)。

另外，整个项目的日志打得越规范，后期调试越省力。在关键接口加一个操作日志，记录谁在什么时间对哪个订单做了什么操作，虽然不是核心功能，但对理解系统整个流转过程特别有帮助，答辩时也能顺手展示。

7.2 系统可以往哪些方向继续扩展

如果时间充裕，可以给设备增加二维码标签，手机扫码直接查看设备信息、租赁历史；或者在订单到期前通过邮件或站内消息提醒管理员。统计报表部分可以对接图表组件，把设备利用率、月收入趋势、逾期率这些指标画出来，视觉效果会很好。再往下可以加入消息队列做异步通知，引入Redis缓存设备列表，但这些已经超出毕设必要范围，反而容易因为代码量膨胀而失控。

这套系统做完整之后，不仅是个毕业设计，更是一个能讲清楚“业务需求到数据库设计再到前后端实现”的完整案例。把这些内容内化掉，比多抄几个源码都更有价值。