做“计算机毕业设计SpringBoot房屋租赁系统”这类题目的人多半一开始都抱着一个朴素的想法把房源挂出来让租客能搜到再做一个后台房东和管理员各管一摊就算完工。但真正动手之后你会发现光是把“出租”和“求租”这两个词做成业务闭环就够你拆一阵子的。无论是叫“在线房屋出租与求租撮合平台”还是叫“SpringBootVue智慧住房租赁综合服务平台”核心都指向同一件事——这不是一个单纯的信息展示系统而是一个带有撮合逻辑的交易链条。这篇文章我想结合带毕设的实践经历把从选题定位、技术选型、数据库设计到撮合状态机、前端对接、部署踩坑的完整链路拆开讲一遍给正在做“SpringBoot房屋租赁系统”的同学一条能直接参照的路线。1. 选题定位毕设级别的租赁平台该做到什么程度1.1 “撮合”不是口号是三层业务需求房屋租赁系统最容易做成的样子是“房源版留言板”用户注册后发房源租房的人搜到号码自己打电话系统只负责展示。这种方案作为课程设计勉强能交代但放到毕业设计里答辩老师大概率会问一句“你的系统和58同城的信息广场区别在哪撮合体现在哪里”把“撮合”拆开它应该包含三层信息匹配层租客输入区域、租金、户型条件系统从房源池里筛出满足条件的结果这是最基础的一层。意图撮合层租客不只是搜房源还能发布求租需求——比如“我想在城南片区找一个两室一厅预算2500以内月底入住”。系统把这个需求推送给符合条件的房东房东也可以反向查看这批求租需求并主动联系。这一步才是“出租与求租双向撮合”的实质。交易推进层双方产生意向后系统提供预约看房、订单生成、合同签署的流程每一步都有状态记录。我见过不少项目在第三层直接放弃理由是“线下谈就可以了”。但毕业设计要有业务深度交易推进层恰恰是拉开档次的地方。哪怕不做完整电子合同把“预约看房—看房确认—生成订单”的状态流转做出来项目已经比80%的同题作品完整了。1.2 功能边界怎么划才不至于把自己埋进去毕设时间有限不能什么热就往上堆。智能推荐、实时聊天、支付接口这些模块如果缺乏前置技术基础后期联调阶段极容易翻车。我建议把功能边界明确划成四个域功能域面向角色核心操作复杂度房源管理房东发布房源、图片上传、上下架、修改中求租需求租客发布求租信息、条件筛选、需求编辑中撮合与订单双方预约看房、状态确认、订单生成高平台运营管理员用户审核、房源审核、公告发布、统计低把“撮合与订单”作为项目重心其他三个域都为核心域服务。这样到了写论文时“研究意义”和“系统设计”也有坚实的落地内容而不是空谈 “系统提高了租赁效率”这种套话。2. 技术选型逻辑SpringBootVue不是跟风是适配度问题2.1 SpringBoot版本、JDK、依赖兼容一个都不能省现在很多教程默认用 SpringBoot 2.7 配 JDK 8网上一搜一大堆报错也有现成答案。但如果你从零开始新写项目我建议直接看 SpringBoot 3.x 配 JDK 17理由很简单2024年之后大部分云厂商和中间件的官方文档都开始默认支持3.xSpring官方也宣布2.x进入维护末期。不过这里有个高频热词提到的坑——“SpringBoot版本太高”。很多同学新建项目选了 SpringBoot 3.2 或 3.3然后发现整合旧版 knife4j、activemq 等组件时用 maven 仓库里推荐的坐标报错。我的建议是固定版本而不是盲追最新目前比较稳的组合是 SpringBoot 3.1/3.2 JDK 17 MyBatis-Plus 3.5.x。选定版本后就在项目里锁定parent版本和依赖版本不要今天看到3.4出来了就顺手升级重构成本全部落在你身上。2.2 前端选Vue后的工程组织方式Vue这边我推荐用 Vue 3 Vite Pinia Vue Router。Vite的好处是启动快、配置简单写毕设比 Webpack 舒服太多。对没用过前端工程化的人来说最大的坎是“环境安装”也就是热词里反复出现的“vue安装及环境配置”“vue安装依赖”。我建议按这个顺序操作安装 Node.js 18 或 20 LTSnpm 随附。用npm create vitelatest frontend -- --template vue生成工程。cnpm install或npm install安装依赖国内网络问题优先换成淘宝镜像npm config set registry https://registry.npmmirror.com。npm run dev起本地服务默认端口 5173。Vue工程的目录我习惯这样切src/api放接口请求封装src/views按角色放页面user/house/order/adminsrc/router配路由src/stores放登录状态和用户信息。页面组件之间的复用可以适度用插槽slot做布局比如房源卡片组件、分页组件、状态标签组件这几个是你在列表页和详情页反复要用的。2.3 ORM层选择MyBatis-Plus对毕设更友好SpringBoot搭持久层有两条主路Spring Data JPA 和 MyBatis-Plus。毕设我几乎都推荐 MyBatis-Plus原因是它的条件构造器能让你用极少的代码完成多条件分页查询而 JPA 的复杂查询需要写方法命名规则或 JPQL对“Java学到能跑”的普遍水平来说门槛更高。MyBatis-Plus 还内置了分页插件、逻辑删除、自动填充。这三个功能正好对租赁系统的列表分页、房源逻辑删除、创建时间自动填充可以说是为这类管理系统的开发场景量身定做的。3. 数据库设计把“撮合”落到九张表里3.1 实体关系梳理租赁系统的实体关系其实很清晰一个用户可以是房东、租客、管理员三种角色之一。房东拥有多套房源房源拥有多张图片租客可以发布多条求租需求也可以收藏多套房源房源和租客之间通过“预约看房单”建立撮合联系预约确认后生成订单订单再引出合同。依据这个关系我建议至少建九张表user用户表含角色字段house房源主表house_image房源图片表requirement求租需求表favorite收藏表appointment预约看房表order_info租赁订单表contract合同表notice公告/通知表3.2 核心表字段细节房源表是租赁系统的地基字段设计要能支撑检索条件。我的推荐字段如下字段类型说明idbigint主键landlord_idbigint房东IDtitlevarchar(100)房源标题cover_imagevarchar(255)封面图URLregionvarchar(50)所在区域addressvarchar(255)详细地址house_typetinyint1整租 2合租bedroomstinyint室living_roomstinyint厅bathroomstinyint卫areadecimal(8,2)建筑面积平米rentdecimal(10,2)月租金depositdecimal(10,2)押金statustinyint0未上架 1已上架 2已出租 3已下架audit_statustinyint0待审核 1审核通过 2审核拒绝create_timedatetime创建时间求租需求表对应租客发布的“找房意向”字段要有requirement_id、tenant_id、region、min_rent/max_rent、house_type、bedrooms、expect_date、description、status匹配中/已匹配/已下架。3.3 状态字段设计的两个原则第一条原则不要只用状态A/B/C三个字母而是把核心流程拆成独立的数字状态。比如房源如果只用“在租/出租”两个状态你很难知道一套房源此时是“刚发布待审核”还是“已经签了合同但有租客没入住”。毕设答辩时评委喜欢问“状态怎么流转”如果你的状态枚举能清晰回答每一步就赢得了第一印象。第二条原则所有业务表加deleted逻辑删除标记不要物理删数据。MyBatis-Plus 的TableLogic注解一键处理。这样即使管理员在后台误删了某条帖子或需求你在演示时也能拿出“数据可恢复”这个卖点。4. 后端模块实现从登录到房源检索的完整链路4.1 登录认证与角色权限的最小可行方案毕设阶段用 Spring Security JWT 是常见方案但如果你对 Spring Security 的过滤器链不熟配置起来容易卡壳。我实操下来更推荐一个轻量方案用拦截器 JWT 手写一套“够用”的认证。流程很简单用户登录成功后后端生成 token可以用 jjwt 库前端把 token 存在 localStorage每次请求的Authorization头带过来。后端写一个拦截器拦截/api/**下除了/api/auth/login、/api/auth/register、/api/house/list之外的所有路径从 token 里解析用户ID和角色再放行。注意一点角色判断不能只在前端做后端的每个写操作接口都要校验角色。比如发布房源接口必须校验landlord角色审核房源接口必须校验admin角色否则任何懂接口调用的用户都能直接 POST 数据伪造权限。4.2 房源发布的完整链路事务与文件上传分开房源发布不能只 insert 一条 house 记录还要处理封面图、多张详情图、房源初始状态。我建议把发布接口拆成两步第一步前端先把图片上传到服务端写一个/api/file/upload接口保存到本地磁盘或OSS拿到图片URL列表。 第二步前端把房源表单字段 封面URL 图片URL数组一起 POST 到/api/house/add。后端接收时使用Transactional保证房源主表和图片表同时写入如果有一步失败就整体回滚Transactional public Long addHouse(HouseDTO dto) { House house new House(); BeanUtils.copyProperties(dto, house); house.setStatus(0); house.setAuditStatus(0); houseMapper.insert(house); if (!CollectionUtils.isEmpty(dto.getImageUrls())) { for (String url : dto.getImageUrls()) { HouseImage image new HouseImage(); image.setHouseId(house.getId()); image.setUrl(url); houseImageMapper.insert(image); } } return house.getId(); }这个设计的好处是上传和业务解耦、失败可重传、图片表数据可控。别把文件上传和发布合成一个大接口否则后期调接口上传OSS时你会很痛苦。4.3 检索排序用条件构造器怎么写得最快多条件检索是租赁系统的高频操作条件包括关键词、区域、价格区间、户型、出租方式。MyBatis-Plus 的 LambdaQueryWrapper 能非常直观地拼接public IPageHouse searchHouse(HouseQueryDTO query, int page, int size) { PageHouse p new Page(page, size); LambdaQueryWrapperHouse wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.hasText(query.getKeyword()), House::getTitle, query.getKeyword()) .eq(StringUtils.hasText(query.getRegion()), House::getRegion, query.getRegion()) .eq(query.getHouseType() ! null, House::getHouseType, query.getHouseType()) .between(query.getMinPrice() ! null query.getMaxPrice() ! null, House::getRent, query.getMinPrice(), query.getMaxPrice()) .eq(House::getStatus, 1) .eq(House::getAuditStatus, 1) .orderByDesc(House::getCreateTime); return houseMapper.selectPage(p, wrapper); }这里有几个容易被忽视的细节列表只展示status1已上架且auditStatus1审核通过的房源排序默认按发布时间倒序前端传参的page和size要做边界校验防止查全表时把页码传成负数。5. 撮合逻辑的状态机预约、订单、合同如何联动5.1 预约看房单的状态设计撮合的第一步是“预约看房”。租客看到心仪房源后发起预约填入期望看房时间。这里预约单的状态可以设计成四段0待确认租客发起预约等待房东响应1已同意房东同意看房时间2已拒绝房东不同意租客可以重新约3已取消租客主动取消核心动作是“状态变更必须受前序状态约束”。比如已拒绝的预约单不能直接跳到订单生成已取消的预约单不能再变成已同意。实现的简单做法是在更新SQL里带上当前状态条件UPDATE appointment SET status #{targetStatus} WHERE id #{id} AND status #{currentStatus}如果返回的影响行数为0说明状态已经被别的线程改掉了不让更新。这是防并发覆盖最简单有效的方式我后面会再展开。5.2 订单状态机与房源状态联动预约看房后双方确认房源没问题就要生成租赁订单。订单状态我建议这样设计1待签署租客和房东对订单信息确认中2生效中双方已确认租客入住3已完结租期到期正常退租4已取消签署前某一方放弃订单状态的每一步都要触发房源状态变化订单进入“生效中”房源状态必须从“已上架(1)”切到“已出租(2)”订单“已完结”或“已取消”房源如果还具备出租条件状态要能回到“已上架(1)”。这种“订单状态驱动房源状态”的设计才是撮合平台的灵魂。没有这一步你的系统就只是两张互不相干的表。5.3 撮合场景最容易忽略的边界情况复盘我带过的项目最容易出 bug 的地方集中在五处同一套房源在同一时间段被多个租客同时预约需要“预约时锁定房源”或“确认订单时加互斥”。租客发布求租需求后房东在另一端主动发起沟通这时需求表的状态要从“匹配中”变“已匹配”。一个用户既是房东又是租客角色可以切换登录态里的角色信息要能动态更新。租客对同一套房源重复发起预约应在生成预约单前查一次未取消的预约记录若存在则提示“已有进行中的预约”。合同签署时缺少合同时长字段直接导致后续租金计算没有依据。合同表里至少要放起止日期和月租金。如果你在论文里把这些边界情况写成“关键问题与解决方案”答辩含金量会明显提升。6. Vue前端实现要点页面、路由、权限与接口对接6.1 前端工程目录与路由设计Vue 前端我习惯把页面按角色和组织结构拆分src/ api/ # 接口封装auth.js, house.js, requirement.js, order.js views/ login/ # 登录、注册 home/ # 门户首页、房源列表、房源详情 landlord/ # 房东端房源管理、预约处理、我的订单 tenant/ # 租客端求租发布、收藏、我的预约 admin/ # 管理端用户审核、房源审核、订单管理、公告 components/ # 通用组件 stores/ # Piniauser store router/ # 路由配置路由这块最容易出问题的是“刷新后白屏”。原因通常是 Vue Router 用了 history 模式但生产部署时尤其是打包进 SpringBoot 后对/user/xxx这类前端路由没有做后端转发。开发环境没事生产环境一刷新就 404。解决办法后端加一个控制器把所有非/api的前端请求转发到index.html或者干脆在Router里用createWebHashHistory。毕设演示时没有强制要求去除 hash用 hash 模式可以少踩一个坑。6.2 接口请求封装与Token注入接口请求封装用 axios 实例统一处理 baseURL、token 注入和响应拦截。一个基础封装如下import axios from axios const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) config.headers.Authorization Bearer ${token} return config }) request.interceptors.response.use( res { if (res.data.code 401) { localStorage.removeItem(token) window.location.href /login } return res.data }, err { return Promise.reject(err) } )开发环境下用 Vite 的代理解决跨域生产环境下让 SpringBoot 把前端静态资源一起托管baseURL 直接写/api跨域就彻底不存在了。这也是“vue打包放进springboot中”这种需求的最干净解法。6.3 动态菜单和按钮权限的一种简单做法管理系统常需要“房东登录后显示房东菜单管理员显示管理菜单”。动态路由用后端返回角色所拥有的菜单数组前端在路由前置守卫里根据用户角色动态拼接路由可以用router.addRoute()实现。更简单的一种做法是不做动态路由而是做菜单渲染控制和按钮控制。登录后存下用户角色菜单组件根据角色v-if判断是否渲染对应入口API 层面后端二次校验。对毕设来说这种方案实现速度快、逻辑直观演示时也足够有说服力。7. 联调、打包、部署趟过去的坑才是经验7.1 开发环境跨域怎么配置前后端分离开发阶段前端 5173 端口、后端 8080 端口必然跨域。最简单的方案不是后端写 CORS 配置而是前端开 Vite 代理server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }这样前端代码里所有请求都用相对路径/api/...开发时不跨域生产打包后也不需要改一行代码。如果某些情况下必须用后端 CORS 配置注意设置allowCredentials(true)时allowedOrigins不能写通配符*否则浏览器会拦截。这个细节让我之前浪费过半小时。7.2 前后端日期与JSON格式的坑SpringBoot 默认把 LocalDateTime 序列化成 ISO 字符串Vue 端拿到的是2024-05-01T10:00:00JS 的 new Date() 能解析但展示时格式不好看。更烦的是前端传回来的日期字符串如果格式不对后端反序列化直接 400 报错。解决办法是在application.yml里统一格式并配好时区spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8同时Vue 端提交日期字段时先用 dayjs 格式化成YYYY-MM-DD HH:mm:ss再提交两边就不会因为格式打架。7.3 前端打包进SpringBoot的静态资源路由“vue打包放进springboot中”这个热搜词背后的需求本质上就是生产部署时希望只启一个进程。做法分三步npm run build生成dist目录。把dist里的内容拷贝到src/main/resources/static下。打包运行后前端页面由 SpringBoot 直接托管。需要注意如果你的前端是 history 模式刷新二级路由会 404。我一般加一个简单的转发配置Controller public class SpaForwardController { RequestMapping(value {/, /house/**, /user/**, /admin/**, /landlord/**}) public String forward() { return forward:/index.html; } }这个配置有个前提转发路径不能和RestController的/api/**冲突。这也是为什么所有后端接口都要统一挂/api前缀的另一个原因。7.4 关于“SpringBoot版本太高”引发的连锁问题热词里那句“SpringBoot版本太高”我猜八成是代码生成器、文档依赖或插件版本不兼容导致的。举几个常见的SpringBoot 3.x 要求 Java 17如果你本机还是 Java 8IDE 里编译就过不去knife4j 早期版本不兼容 SpringBoot 3.x 的路径匹配策略导致接口文档白屏Lombok 版本太旧也会在高版本 JDK 下报错。稳妥路径先看官方文档确认你选的 SpringBoot 大版本对应的 JDK 要求再把核心依赖MyBatis-Plus、JWT、Lombok按“SpringBoot3.x适配版”查找。不要一上来就latest毕设项目的核心目标是稳定跑通而不是追求最新版本。8. 从项目完成到答辩展示把系统讲成“有思考的项目”8.1 架构讲解要有一条故事线答辩时最容易犯的错是“照着功能清单念”。正确的讲法是从核心痛点出发——房东无法精准触达租客、租客找房效率低、平台缺乏交易闭环然后引出你的三块核心设计第一双向撮合房源检索之外新增求租需求发布与匹配第二业务闭环预约看房到订单生成再到合同流程用状态机保证状态不混乱第三权限隔离房东、租客、管理员三端入口由后端角色权限统一管控。每讲一块都打开对应页面做一次演示配合一两张数据库表关系图。故事线有了评委就顺着你的思路走而不是打断追问。8.2 提前准备三到五个高频追问我建议你在答辩前把下面几个问题写下来并排练好回答“预约看房遇到房东和租客同时操作怎么办”——答状态更新SQL带当前状态条件防止并发覆盖。“房源数据量大了之后检索怎么优化”——答目前是简化的SQL分页检索可扩展方向包括加索引、增加缓存Redis或切Elasticsearch做全文检索。“为什么不直接用现成的租房平台”——答毕设的核心是完整复现业务链路和技术实现系统设计上保留了支付扩展、地图展示的接口。“你的项目里哪个模块最有含金量”——答状态机和房源-订单联动的业务设计以及多条件检索的封装。把这些问题想透比多写一万行代码更能体现你的工程思考能力。回到文章开头那个问题房屋租赁系统凭什么作为毕业设计的“智慧住房租赁综合服务平台”而存在关键在于你有没有把“出租”和“求租”这两个动作真正撮合起来并且用一套可控的状态机制保证交易流程不乱。技术栈选型、表结构设计、接口封装、前端路由所有工作都围绕这条主线展开。我操作这个题目的最大体会是功能可以裁剪代码可以不漂亮但业务链路必须闭环。只要你把双向撮合这条线讲清楚把状态流转的细节处理到位这个系统在答辩和求职作品集里都能站稳脚跟。