简介这份资源是面向计算机相关专业毕业生与课程设计学习者的房屋租赁系统完整项目包对应《房屋租赁系统的设计与实现》课题融合程序设计、管理系统与人工智能应用适合需要完成毕设或综合实训的开发者参考。压缩包共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 需求边界哪些功能必须有哪些可以砍房屋租赁系统的功能看起来很多但真正构成「最小可演示闭环」的只有四条主线房源发布、房源检索、租赁下单、订单管理。围绕这四条主线角色分三种管理员、房东、租客。管理员管用户和审核房源房东发布和维护房源租客浏览和下单。下面这张表是我建议的功能边界划分左边是必须做的右边是可以砍掉或者放到「未来工作」里的模块必须实现可以砍掉或简化用户注册、登录、角色区分第三方登录、找回密码邮件房源发布、编辑、上下架、图片上传地图选点、VR 看房检索按区域/价格/户型筛选全文搜索、推荐算法订单下单、取消、状态流转在线支付、自动续租合同生成合同记录、查看电子签章、PDF 导出后台用户管理、房源审核数据大屏、操作日志审计砍功能不是偷懒是保证核心链路能跑通。答辩老师最常问的是「你这个下单流程是怎么保证房源不会被重复租出去的」而不是「你为什么没做地图」。把并发和状态流转讲清楚比堆十个半成品功能有用得多。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 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 房源表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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单表状态流转是核心后面会重点讲 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有两个设计点值得单独说。第一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 idsearchHouses resultTypeHouseVO SELECT h.*, u.username AS ownerName FROM house h LEFT JOIN user u ON h.owner_id u.id where h.status 1 !-- 只查已上架的 -- if testaddress ! null and address ! AND h.address LIKE CONCAT(%, #{address}, %) /if if testminRent ! null AND h.rent gt; #{minRent} /if if testmaxRent ! null AND h.rent lt; #{maxRent} /if if testroomType ! null and roomType ! AND h.room_type #{roomType} /if /where ORDER BY h.create_time DESC LIMIT #{offset}, #{pageSize} /select逻辑说明where标签会自动处理第一个条件前的AND省得你写WHERE 11。status 1写死在 SQL 里而不是作为参数是为了防止前端传个status0把待审核房源也查出来。分页用LIMIT offset, pageSizeoffset在 Service 层算好传进来。参数方面minRent和maxRent要做非负校验pageSize建议限制上限比如 50防止有人传pageSize100000拖垮数据库。如果用的是 MyBatis-Plus可以用QueryWrapper链式写法效果一样代码更短QueryWrapperHouse 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); PageHouse 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 MapInteger, SetInteger 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(订单不存在); } // 校验流转是否合法 SetInteger 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带了一个status1的条件只有房源当前是已上架才能改成已租出返回 0 说明被别人抢先了直接抛异常回滚。这就是用数据库的原子更新解决并发问题的思路比先查再改可靠。参数方面operatorId用来做权限校验比如只有房东能确认订单这个校验要加在调用changeStatus之前。4. 避坑与排查毕设里最容易翻车的五个地方4.1 房源重复下单现象是同一房源出现两条有效订单现象两个租客同时点下单数据库里出现两条status0的订单房源被重复租出去。原因先查房源状态再插入订单两步之间有时间窗口并发时都查到「可租」。解决在house表上加乐观锁版本号或者用条件更新。我一般用后者UPDATE house SET status3 WHERE id? AND status1根据影响行数判断是否成功失败就提示「手慢了」。这个思路在 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连接串加characterEncodingutf8SpringBoot 的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.activeprod \ app.log 21 # 查看启动日志确认端口监听成功 tail -f app.log | grep Started参数说明-DskipTests跳过测试加快打包但正式提交前建议跑一遍测试。--spring.profiles.activeprod指定生产配置把数据库密码等敏感信息放在application-prod.yml里不要提交到代码仓库。nohup加让进程后台运行关掉终端也不影响。tail -f看日志确认Started ... in x seconds出现说明启动成功。如果启动失败先看日志里的Caused by十有八九是数据库连不上或者端口被占用。5.2 演示脚本按这条路径走不会卡壳答辩演示时间通常只有 5 到 10 分钟提前写好脚本按顺序点别现场发挥。我一般会按这条路径先用管理员登录展示用户列表和房源审核然后退出用房东登录发布一套房源上传两张图展示待审核状态再用管理员审核通过最后用租客登录检索到这套房下单展示订单状态从待确认变成已确认。这条路径覆盖了三种角色和核心状态流转老师一看就明白系统是通的。演示前一定要清空数据库里的测试数据或者准备一套干净的演示数据。我见过有同学演示时列表里全是「测试1」「aaa」这种数据观感很差。准备三条真实感的房源数据地址写学校附近的真实小区名租金写合理区间演示效果会好很多。5.3 论文里值得展开写的三个技术点毕设论文不是代码说明书要有技术分析。房屋租赁系统里值得展开写的点有三个一是订单状态机的设计把状态流转表和代码实现对应起来写体现设计能力二是并发下单的处理讲清楚条件更新和乐观锁的区别与选择理由三是多条件动态查询的 SQL 优化讲索引怎么加、LIKE前缀匹配为什么用不上索引。这三点写透论文的技术含量就够了比堆一堆「系统测试」的截图有用。最后说个我自己的习惯每次改完核心逻辑我都会用 Postman 或者 curl 把接口单独跑一遍不依赖前端页面。这样出问题时能快速定位是前端还是后端省得在浏览器控制台里翻半天。毕设时间紧但这个习惯能帮你少熬几个通宵。希望帮到你。本文还有配套的精品资源点击获取 房屋租赁系统毕业设计：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 需求边界哪些功能必须有哪些可以砍房屋租赁系统的功能看起来很多但真正构成「最小可演示闭环」的只有四条主线房源发布、房源检索、租赁下单、订单管理。围绕这四条主线角色分三种管理员、房东、租客。管理员管用户和审核房源房东发布和维护房源租客浏览和下单。下面这张表是我建议的功能边界划分左边是必须做的右边是可以砍掉或者放到「未来工作」里的模块必须实现可以砍掉或简化用户注册、登录、角色区分第三方登录、找回密码邮件房源发布、编辑、上下架、图片上传地图选点、VR 看房检索按区域/价格/户型筛选全文搜索、推荐算法订单下单、取消、状态流转在线支付、自动续租合同生成合同记录、查看电子签章、PDF 导出后台用户管理、房源审核数据大屏、操作日志审计砍功能不是偷懒是保证核心链路能跑通。答辩老师最常问的是「你这个下单流程是怎么保证房源不会被重复租出去的」而不是「你为什么没做地图」。把并发和状态流转讲清楚比堆十个半成品功能有用得多。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 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 房源表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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单表状态流转是核心后面会重点讲 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有两个设计点值得单独说。第一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 idsearchHouses resultTypeHouseVO SELECT h.*, u.username AS ownerName FROM house h LEFT JOIN user u ON h.owner_id u.id where h.status 1 !-- 只查已上架的 -- if testaddress ! null and address ! AND h.address LIKE CONCAT(%, #{address}, %) /if if testminRent ! null AND h.rent gt; #{minRent} /if if testmaxRent ! null AND h.rent lt; #{maxRent} /if if testroomType ! null and roomType ! AND h.room_type #{roomType} /if /where ORDER BY h.create_time DESC LIMIT #{offset}, #{pageSize} /select逻辑说明where标签会自动处理第一个条件前的AND省得你写WHERE 11。status 1写死在 SQL 里而不是作为参数是为了防止前端传个status0把待审核房源也查出来。分页用LIMIT offset, pageSizeoffset在 Service 层算好传进来。参数方面minRent和maxRent要做非负校验pageSize建议限制上限比如 50防止有人传pageSize100000拖垮数据库。如果用的是 MyBatis-Plus可以用QueryWrapper链式写法效果一样代码更短QueryWrapperHouse 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); PageHouse 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 MapInteger, SetInteger 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(订单不存在); } // 校验流转是否合法 SetInteger 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带了一个status1的条件只有房源当前是已上架才能改成已租出返回 0 说明被别人抢先了直接抛异常回滚。这就是用数据库的原子更新解决并发问题的思路比先查再改可靠。参数方面operatorId用来做权限校验比如只有房东能确认订单这个校验要加在调用changeStatus之前。4. 避坑与排查毕设里最容易翻车的五个地方4.1 房源重复下单现象是同一房源出现两条有效订单现象两个租客同时点下单数据库里出现两条status0的订单房源被重复租出去。原因先查房源状态再插入订单两步之间有时间窗口并发时都查到「可租」。解决在house表上加乐观锁版本号或者用条件更新。我一般用后者UPDATE house SET status3 WHERE id? AND status1根据影响行数判断是否成功失败就提示「手慢了」。这个思路在 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连接串加characterEncodingutf8SpringBoot 的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.activeprod \ app.log 21 # 查看启动日志确认端口监听成功 tail -f app.log | grep Started参数说明-DskipTests跳过测试加快打包但正式提交前建议跑一遍测试。--spring.profiles.activeprod指定生产配置把数据库密码等敏感信息放在application-prod.yml里不要提交到代码仓库。nohup加让进程后台运行关掉终端也不影响。tail -f看日志确认Started ... in x seconds出现说明启动成功。如果启动失败先看日志里的Caused by十有八九是数据库连不上或者端口被占用。5.2 演示脚本按这条路径走不会卡壳答辩演示时间通常只有 5 到 10 分钟提前写好脚本按顺序点别现场发挥。我一般会按这条路径先用管理员登录展示用户列表和房源审核然后退出用房东登录发布一套房源上传两张图展示待审核状态再用管理员审核通过最后用租客登录检索到这套房下单展示订单状态从待确认变成已确认。这条路径覆盖了三种角色和核心状态流转老师一看就明白系统是通的。演示前一定要清空数据库里的测试数据或者准备一套干净的演示数据。我见过有同学演示时列表里全是「测试1」「aaa」这种数据观感很差。准备三条真实感的房源数据地址写学校附近的真实小区名租金写合理区间演示效果会好很多。5.3 论文里值得展开写的三个技术点毕设论文不是代码说明书要有技术分析。房屋租赁系统里值得展开写的点有三个一是订单状态机的设计把状态流转表和代码实现对应起来写体现设计能力二是并发下单的处理讲清楚条件更新和乐观锁的区别与选择理由三是多条件动态查询的 SQL 优化讲索引怎么加、LIKE前缀匹配为什么用不上索引。这三点写透论文的技术含量就够了比堆一堆「系统测试」的截图有用。最后说个我自己的习惯每次改完核心逻辑我都会用 Postman 或者 curl 把接口单独跑一遍不依赖前端页面。这样出问题时能快速定位是前端还是后端省得在浏览器控制台里翻半天。毕设时间紧但这个习惯能帮你少熬几个通宵。希望帮到你。本文还有配套的精品资源点击获取