房屋租赁系统毕业设计：SpringBoot+MySQL最小闭环与避坑指南

简介：这份资源是面向计算机相关专业毕业生与课程设计学习者的房屋租赁系统完整项目包，对应《房屋租赁系统的设计与实现》课题，融合程序设计、管理系统与人工智能应用，适合需要完成毕设或综合实训的开发者参考。压缩包共578个文件，约24.66MB，以png、gif、jpg等图片资源，js、jsp、java、jar等前后端与依赖文件，less、css、html等样式与页面文件，以及xml、properties等配置为主，另含少量字体、swf与说明文档，覆盖前端界面、后端逻辑、数据库交互与部署配置等模块。系统涉及权限管理、房源发布与查询、预约签约支付退租流程，并引入智能推荐、自然语言处理与图像识别等思路，同时兼顾HTTPS、JWT安全与缓存、索引优化等性能要点。已有117人学习，可作为完整赛题方案与排错参考。

1. 房屋租赁系统毕业设计：从选题到能跑通的最小闭环

每年到了毕设季，计算机毕业设计选题里「房屋租赁系统」几乎是出现频率最高的那一类。原因很直接：业务场景人人能理解，房东、租客、房源、合同、订单这几个实体一摆出来，需求文档半小时就能写完，答辩时老师也不会追问「你这个东西到底解决什么问题」。但真正动手做的时候，很多人会卡在同一个地方——功能列表列了二十条，代码写到一半发现表结构对不上，最后交上去的是一个只能登录、只能看列表、点进去报错的半成品。

这篇笔记面向的是正在做房屋租赁系统毕业设计、或者准备选这个题的同学，也适合已经写了一半但结构混乱、想推倒重来的情况。我会按「先定技术栈和边界 → 再落数据库和核心接口 → 最后讲部署和答辩会被问什么」的顺序，把一套能真正跑起来、能演示、能写进论文的最小闭环讲清楚。不追求功能多，追求每一步都能复现，遇到坑知道往哪查。基于 SpringBoot 的房屋租赁系统是这几年最常见的技术路线，下面就以它为主线展开，中间会说明为什么这么选，以及换成其他栈时哪些地方要改。

2. 技术选型与需求边界：先砍功能再写代码

2.1 为什么是 SpringBoot + MyBatis + MySQL 这套组合

房屋租赁系统毕业设计的技术栈选择，本质上不是选最先进的，而是选资料最多、出问题最容易搜到答案的。SpringBoot 在这几年一直是 Java 毕业设计的默认选项，原因有三个：一是自动配置省掉了大量 XML，一个application.yml就能把数据源、端口、日志配完；二是生态成熟，遇到问题搜索引擎里全是现成答案；三是答辩时老师听得懂，不会因为技术太偏而质疑你「是不是自己写的」。

数据库层面，MySQL 几乎是唯一合理选择。房屋租赁系统的数据关系清晰——用户、房源、订单、合同，都是典型的关系型数据，用 MySQL 建表、加外键、写联表查询，正好能体现你学过数据库。MyBatis 或者 MyBatis-Plus 负责持久层，前者适合想展示 SQL 能力的场景，后者适合想快速出功能的场景。如果时间紧，我一般会推荐 MyBatis-Plus，单表 CRUD 几乎不用写 SQL，能把精力留给业务逻辑。

前端部分，如果是纯后端方向，用 Thymeleaf 或者简单的 Vue 前后端分离都行。这里有个现实建议：如果你的论文重点是系统设计，前端用现成的后台管理模板改一改就够了，不要从零写页面，时间成本太高。把省下来的时间花在数据库设计和接口健壮性上，答辩时更经得起问。

2.2 需求边界：哪些功能必须有，哪些可以砍

房屋租赁系统的功能看起来很多，但真正构成「最小可演示闭环」的只有四条主线：房源发布、房源检索、租赁下单、订单管理。围绕这四条主线，角色分三种：管理员、房东、租客。管理员管用户和审核房源，房东发布和维护房源，租客浏览和下单。

下面这张表是我建议的功能边界划分，左边是必须做的，右边是可以砍掉或者放到「未来工作」里的：

砍功能不是偷懒，是保证核心链路能跑通。答辩老师最常问的是「你这个下单流程是怎么保证房源不会被重复租出去的」，而不是「你为什么没做地图」。把并发和状态流转讲清楚，比堆十个半成品功能有用得多。

2.3 数据库表设计：五张核心表撑起整个系统

房屋租赁系统的表不用多，五张核心表就能撑起来：user（用户）、house（房源）、order（订单）、contract（合同）、house_image（房源图片）。下面给出建表 SQL，字段和类型都是实际能用的：

-- 用户表：三种角色用 role 字段区分 CREATE TABLE `user` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `username` VARCHAR(50) NOT NULL UNIQUE COMMENT '登录名', `password` VARCHAR(100) NOT NULL COMMENT '加密后的密码', `role` TINYINT NOT NULL DEFAULT 0 COMMENT '0租客 1房东 2管理员', `phone` VARCHAR(20) COMMENT '联系电话', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 房源表：status 控制上下架，owner_id 关联房东 CREATE TABLE `house` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `title` VARCHAR(100) NOT NULL, `address` VARCHAR(200) NOT NULL, `area` DECIMAL(8,2) COMMENT '面积，平米', `rent` DECIMAL(10,2) NOT NULL COMMENT '月租金', `room_type` VARCHAR(20) COMMENT '户型，如 2室1厅', `status` TINYINT DEFAULT 0 COMMENT '0待审核 1已上架 2已下架 3已租出', `owner_id` BIGINT NOT NULL, `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_owner (`owner_id`), INDEX idx_status (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 订单表：状态流转是核心，后面会重点讲 CREATE TABLE `order` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `house_id` BIGINT NOT NULL, `tenant_id` BIGINT NOT NULL, `start_date` DATE NOT NULL, `months` INT NOT NULL COMMENT '租期月数', `amount` DECIMAL(10,2) NOT NULL, `status` TINYINT DEFAULT 0 COMMENT '0待确认 1已确认 2已取消 3已完成', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_house_active (`house_id`, `status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里有两个设计点值得单独说。第一，house表的status用整数而不是字符串，查询效率高，前端做映射也方便。第二，order表上的uk_house_active唯一索引，是为了防止同一房源被重复下单——这个索引配合后面的状态判断，是解决并发问题的关键，答辩时能讲出来会加分。注意这个唯一索引的写法在实际中要配合业务逻辑，因为已取消的订单不应该占用唯一性，更稳妥的做法是用「房源状态 + 乐观锁」，后面避坑章节会展开。

3. 核心接口实现：从房源发布到订单状态流转

3.1 房源发布接口：图片上传与参数校验

房源发布是房东侧的第一个核心接口，涉及表单提交和图片上传两件事。图片上传单独做一个接口，返回 URL，房源发布接口只存 URL，这样职责清晰，也方便前端做预览。下面是房源发布的 Controller 和 Service 关键代码：

@RestController @RequestMapping("/api/house") public class HouseController { @Autowired private HouseService houseService; // 发布房源：只有房东角色能调用 @PostMapping("/publish") public Result publish(@RequestBody @Valid HousePublishDTO dto, @RequestAttribute Long userId) { // 校验角色，非房东直接拒绝 if (!houseService.isOwner(userId)) { return Result.fail("只有房东可以发布房源"); } Long houseId = houseService.publish(dto, userId); return Result.ok(houseId); } }

@Service public class HouseServiceImpl implements HouseService { @Autowired private HouseMapper houseMapper; @Override @Transactional(rollbackFor = Exception.class) public Long publish(HousePublishDTO dto, Long ownerId) { House house = new House(); BeanUtils.copyProperties(dto, house); house.setOwnerId(ownerId); // 新发布的房源默认待审核，管理员审核后才上架 house.setStatus(0); houseMapper.insert(house); // 图片单独存，一个房源多张图 if (dto.getImages() != null) { for (String url : dto.getImages()) { houseMapper.insertImage(house.getId(), url); } } return house.getId(); } }

逻辑说明：@Transactional保证房源和图片要么一起成功要么一起回滚，避免出现房源插入成功但图片丢失的脏数据。参数校验用@Valid配合 DTO 上的注解，比如@NotBlank、@Min，把校验前置到 Controller 层，Service 里就不用写一堆 if。参数方面，rent建议加@DecimalMin("0")，area加@Positive，这些细节在论文里写出来能体现工程意识。

图片上传接口我一般用本地存储加时间戳重命名，避免文件名冲突：

@PostMapping("/upload") public Result upload(@RequestParam("file") MultipartFile file) { // 限制大小和类型，防止上传可执行文件 if (file.getSize() > 5 * 1024 * 1024) { return Result.fail("图片不能超过5MB"); } String original = file.getOriginalFilename(); String ext = original.substring(original.lastIndexOf(".")); String fileName = System.currentTimeMillis() + ext; // 按日期分目录，避免单目录文件过多 String datePath = new SimpleDateFormat("yyyyMMdd").format(new Date()); File dir = new File(uploadPath + datePath); if (!dir.exists()) dir.mkdirs(); file.transferTo(new File(dir, fileName)); return Result.ok("/upload/" + datePath + "/" + fileName); }

这里的关键是限制文件大小和类型，很多同学的毕设上传接口不校验，答辩时被问「用户上传一个 1G 的文件怎么办」就答不上来。按日期分目录也是实际项目里的常见做法，单目录文件过万后ls都会变慢。

3.2 房源检索接口：多条件动态查询怎么写

房源检索是租客侧用得最多的接口，需求是按区域、价格区间、户型组合筛选，还要分页。这种多条件动态查询，用 MyBatis 的<if>标签最合适，不要用字符串拼接 SQL，会有注入风险。下面是 Mapper XML 的写法：

<select id="searchHouses" resultType="HouseVO"> SELECT h.*, u.username AS ownerName FROM house h LEFT JOIN user u ON h.owner_id = u.id <where> h.status = 1 <!-- 只查已上架的 --> <if test="address != null and address != ''"> AND h.address LIKE CONCAT('%', #{address}, '%') </if> <if test="minRent != null"> AND h.rent &gt;= #{minRent} </if> <if test="maxRent != null"> AND h.rent &lt;= #{maxRent} </if> <if test="roomType != null and roomType != ''"> AND h.room_type = #{roomType} </if> </where> ORDER BY h.create_time DESC LIMIT #{offset}, #{pageSize} </select>

逻辑说明：<where>标签会自动处理第一个条件前的AND，省得你写WHERE 1=1。status = 1写死在 SQL 里而不是作为参数，是为了防止前端传个status=0把待审核房源也查出来。分页用LIMIT offset, pageSize，offset在 Service 层算好传进来。参数方面，minRent和maxRent要做非负校验，pageSize建议限制上限比如 50，防止有人传pageSize=100000拖垮数据库。

如果用的是 MyBatis-Plus，可以用QueryWrapper链式写法，效果一样，代码更短：

QueryWrapper<House> wrapper = new QueryWrapper<>(); wrapper.eq("status", 1); if (StringUtils.hasText(address)) { wrapper.like("address", address); } if (minRent != null) { wrapper.ge("rent", minRent); } if (maxRent != null) { wrapper.le("rent", maxRent); } wrapper.orderByDesc("create_time"); Page<House> page = houseMapper.selectPage(new Page<>(pageNum, pageSize), wrapper);

两种写法选一种就行，论文里写清楚为什么选它。我一般推荐 MyBatis-Plus，因为毕设时间有限，少写 XML 能省不少调试时间。

3.3 订单状态流转：用状态机思路避免逻辑混乱

订单是房屋租赁系统里最容易写乱的部分，因为状态多、流转条件多。很多同学用一堆 if-else 判断，写着写着就不知道某个状态能不能取消了。正确做法是把状态流转画成一张表，代码按表来实现。订单状态定义：0 待确认、1 已确认、2 已取消、3 已完成。允许的流转是：0→1（房东确认）、0→2（租客或房东取消）、1→3（租期结束完成）、1→2（双方协商取消）。

@Service public class OrderServiceImpl implements OrderService { // 定义每个状态允许的下一步操作 private static final Map<Integer, Set<Integer>> ALLOWED = Map.of( 0, Set.of(1, 2), 1, Set.of(2, 3), 2, Set.of(), 3, Set.of() ); @Override @Transactional(rollbackFor = Exception.class) public void changeStatus(Long orderId, Integer targetStatus, Long operatorId) { Order order = orderMapper.selectById(orderId); if (order == null) { throw new BizException("订单不存在"); } // 校验流转是否合法 Set<Integer> allowed = ALLOWED.get(order.getStatus()); if (allowed == null || !allowed.contains(targetStatus)) { throw new BizException("当前状态不允许此操作"); } // 确认订单时，把房源状态改为已租出，防止重复下单 if (targetStatus == 1) { int updated = houseMapper.updateStatus(order.getHouseId(), 1, 3); if (updated == 0) { throw new BizException("房源已被租出"); } } order.setStatus(targetStatus); orderMapper.updateById(order); } }

逻辑说明：ALLOWED这个 Map 把状态流转规则集中管理，加新状态只改这一处，不用满代码找 if。houseMapper.updateStatus带了一个status=1的条件，只有房源当前是已上架才能改成已租出，返回 0 说明被别人抢先了，直接抛异常回滚。这就是用数据库的原子更新解决并发问题的思路，比先查再改可靠。参数方面，operatorId用来做权限校验，比如只有房东能确认订单，这个校验要加在调用changeStatus之前。

4. 避坑与排查：毕设里最容易翻车的五个地方

4.1 房源重复下单：现象是同一房源出现两条有效订单

现象：两个租客同时点下单，数据库里出现两条status=0的订单，房源被重复租出去。原因：先查房源状态再插入订单，两步之间有时间窗口，并发时都查到「可租」。解决：在house表上加乐观锁版本号，或者用条件更新。我一般用后者，UPDATE house SET status=3 WHERE id=? AND status=1，根据影响行数判断是否成功，失败就提示「手慢了」。这个思路在 3.3 的代码里已经体现，答辩时能讲清楚是加分项。

4.2 图片上传后访问 404：路径配置对不上

现象：上传成功返回了 URL，但前端<img>加载不出来，控制台 404。原因：上传目录和静态资源映射目录不一致，或者用了相对路径，项目重启后工作目录变了。解决：在application.yml里配置绝对路径，同时加一个WebMvcConfigurer把上传目录映射成静态资源：

@Configuration public class WebConfig implements WebMvcConfigurer { @Value("${upload.path}") private String uploadPath; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { // 把 /upload/** 映射到本地上传目录 registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadPath); } }

注意file:前缀不能少，少了会当成 classpath 路径找不到。upload.path建议配成绝对路径，比如/data/upload/，不要用./upload。

4.3 中文乱码：数据库、连接、页面三处都要对

现象：房源标题存进去变成问号，或者页面显示乱码。原因：MySQL 建表时字符集不是utf8mb4，或者 JDBC 连接串没指定编码。解决：建表统一用utf8mb4，连接串加characterEncoding=utf8，SpringBoot 的server.servlet.encoding.charset设为 UTF-8。三处缺一处都可能乱码，排查时按「数据库 → 连接 → 应用」顺序查。用SHOW CREATE TABLE house能直接看到表的字符集。

4.4 登录状态丢失：Session 和前后端分离的冲突

现象：前后端分离时，登录后下一个请求就提示未登录。原因：前端用 axios 默认不带 cookie，后端 Session 拿不到。解决：要么配置 axios 的withCredentials: true并处理跨域，要么干脆用 JWT，把 token 放请求头。毕设里我更推荐 JWT，无状态，部署到不同端口也不容易出问题。JWT 的坑是过期时间要设合理，太短演示时老要重新登录，太长又不安全，一般设 2 小时。

4.5 答辩被问「并发」答不上来：提前准备三个点

现象：老师问「如果很多人同时抢一套房怎么办」，答「加锁」但说不清加什么锁。原因：只写了功能没想过并发。解决：提前准备三个层次——数据库层用唯一索引或条件更新，应用层用@Transactional保证原子性，必要时用 Redis 分布式锁。毕设里讲到数据库条件更新这一层就够了，能说清楚「UPDATE 带条件判断影响行数」的原理，比背概念强。注意不要吹自己用了分布式锁但代码里没有，被追问会很难看。

5. 部署上线与答辩演示：把系统跑在真实环境里

5.1 打包部署：从 jar 到能访问的完整命令

毕设演示最好别只在 IDE 里跑，用命令行打包部署一次，答辩时更有底气。SpringBoot 项目打包命令：

# 跳过测试打包，生成可执行 jar mvn clean package -DskipTests # 后台运行，日志输出到文件 nohup java -jar house-rental-0.0.1.jar \ --spring.profiles.active=prod \ > app.log 2>&1 & # 查看启动日志，确认端口监听成功 tail -f app.log | grep "Started"

参数说明：-DskipTests跳过测试加快打包，但正式提交前建议跑一遍测试。--spring.profiles.active=prod指定生产配置，把数据库密码等敏感信息放在application-prod.yml里，不要提交到代码仓库。nohup加&让进程后台运行，关掉终端也不影响。tail -f看日志确认Started ... in x seconds出现，说明启动成功。如果启动失败，先看日志里的Caused by，十有八九是数据库连不上或者端口被占用。

5.2 演示脚本：按这条路径走不会卡壳

答辩演示时间通常只有 5 到 10 分钟，提前写好脚本按顺序点，别现场发挥。我一般会按这条路径：先用管理员登录，展示用户列表和房源审核；然后退出，用房东登录，发布一套房源，上传两张图，展示待审核状态；再用管理员审核通过；最后用租客登录，检索到这套房，下单，展示订单状态从待确认变成已确认。这条路径覆盖了三种角色和核心状态流转，老师一看就明白系统是通的。

演示前一定要清空数据库里的测试数据，或者准备一套干净的演示数据。我见过有同学演示时列表里全是「测试1」「aaa」这种数据，观感很差。准备三条真实感的房源数据，地址写学校附近的真实小区名，租金写合理区间，演示效果会好很多。

5.3 论文里值得展开写的三个技术点

毕设论文不是代码说明书，要有技术分析。房屋租赁系统里值得展开写的点有三个：一是订单状态机的设计，把状态流转表和代码实现对应起来写，体现设计能力；二是并发下单的处理，讲清楚条件更新和乐观锁的区别与选择理由；三是多条件动态查询的 SQL 优化，讲索引怎么加、LIKE前缀匹配为什么用不上索引。这三点写透，论文的技术含量就够了，比堆一堆「系统测试」的截图有用。

最后说个我自己的习惯：每次改完核心逻辑，我都会用 Postman 或者 curl 把接口单独跑一遍，不依赖前端页面。这样出问题时能快速定位是前端还是后端，省得在浏览器控制台里翻半天。毕设时间紧，但这个习惯能帮你少熬几个通宵。希望帮到你。

本文还有配套的精品资源，点击获取