Spring Boot租房平台毕设全攻略：从选型到部署

1. 为什么选租房平台做毕设：一个不上不下的选择题

每年到毕设选题季，后台咨询最多的问题不是"老师，这个功能怎么做"，而是"老师，我到底该选个什么题目"。Java方向的题库里翻来翻去就那么几类：电商系统、博客系统、管理系统、预约平台。你要是选个图书管理，答辩评委大概率会问一句"这项目除了CRUD还有什么"；你要是选个电商，功能堆得多但做不完，最后打包一个半成品上去，反而更难看。

我当时给这个学生定大学生在线租房平台，考虑的是三个点：

第一，业务场景足够贴近真实生活。租房平台的用户角色天然就是房东、租客、管理员三种，权限边界清晰，业务链条完整，从房源发布、浏览检索、下单预约到合同签订、评价反馈，整个链路做下来，CRUD不再是零散的操作，而是被业务串成了一条线。这在答辩的时候特别好讲，评委问"你这个项目解决了什么问题"，你不用绕弯子，直接说"学生租房信息不透明、找房效率低、中介费高"，一句话就能交代清楚。

第二，技术难度处于一个恰到好处的位置。比纯管理系统多了一些需要动脑的地方，比如多条件组合检索、图片上传、预约订单的状态流转、登录拦截与权限控制，但也远没有到秒杀系统、分布式事务那种给自己挖坑的程度。对于本科毕设来说，这个难度曲线非常友好，既有能展示技术深度的点，又不至于做不完。

第三，资源复用率高。房产信息、订单、收藏、评价、公告这些模块几乎是所有交易类系统的通用模板，做完这个项目，后续如果你想扩展一个二手交易平台或者校园服务平台，改改表结构就能复用一大半代码。我甚至遇到过学生拿着这个项目改了改，变成"大学生兼职平台"去投简历用的——它的业务骨架本身就带扩展性。

当然，选型的时候也踩过一个坑。2023年之后Spring Boot 3.x已经比较普及了，很多学生一看最新版就直接上3.x，结果发现自己本地JDK还是8，或者项目里整合的某个第三方组件不支持Jakarta命名空间，折腾几天下载依赖都过不去。我在这个项目里用的是Spring Boot 2.7.x，配JDK 1.8，这套组合是当前Java毕设场景下兼容性最好、网上方案最多的搭配。关于这一点，后面第三节我会展开说为什么别追新版本。

2. 从需求到模块：系统功能边界是怎么划出来的

选题定下来之后，第二步就是把需求拆成能落地的功能模块。这里最容易犯的毛病是"什么都想要"——学生一听说租房平台，恨不得把58同城、贝壳找房的功能全抄一遍。我一般会压一压，告诉他：毕设的功能设计首要原则是可完成、可演示、可讲清楚，而不是大而全。

2.1 三个端口的角色划分

这个平台的核心是三类角色，每一类的功能我按下表划了一条严格的分界线，避免角色之间的权限交叉：

注意一个细节：普通用户和房东在数据模型上是同一个用户表，通过角色字段区分。很多初学者会下意识地建两张用户表，一张学生表一张房东表，这是典型的"用表结构绑架业务设计"的错误思路。一个用户完全可以既是租客又是房东——学生毕业后可以把自己租的房子转租出去，这时候他同时拥有两种身份。所以用户表里加一个role字段（0管理员/1普通用户/2房东），要比拆表灵活得多，登录后根据角色动态渲染不同的侧边菜单和路由即可。这个设计在答辩里是加分项，因为说明你思考过真实业务中的用户画像，而不是只会照搬表结构。

2.2 房源模块的设计边界

房源是整个系统的主数据，它承载的信息量最大，也最容易在下钻的时候堆字段。我在设计时把房源信息拆成三层：

• 基础属性层：标题、描述、租金、户型（几室几厅）、面积、所在校区/商圈、楼层、朝向、配套标签，这些是列表页和详情页都会用到的字段，直接挂在house_info主表上。
• 展示资源层：房源图片。这里我单独建了一张house_image表，存图片的URL和排序值，而不是把多张图片拼成一个逗号分隔的字符串存在主表里。好处有两个：一是图片数量不固定的时候不需要去改主表；二是后续如果要做"首图大图、其余小图"这种展示逻辑，一条SQL按排序值取第一条就行，代码写起来很干净。
• 运营状态层：审核状态（待审核/已通过/已拒绝）、上下架状态、出租状态（已租/未租）。这三者是有先后约束的，审核不通过的房源不允许上架，已经出租的房源不能被预约。这个约束要在Service层写判断逻辑，不能只在前端隐藏按钮，原因后面讲权限的时候会说。

这三层拆开之后，前端列表页加载缩略图的时候就不会去全表扫描图片字段，详情页按房源ID单独查图片表也快。面试的时候如果被问到"大字段和主表要不要拆"，你把这个设计讲出来，比背诵《高性能MySQL》目录要管用得多。

2.3 预约订单的状态流转

预约看房是整个系统里业务最生动的部分。很多同学做订单只会做"下单-付款-完成"这种线性流程，但租房业务里预约一个房源，状态是可以来回弹的。我在设计时定义了这样一个状态机：

code复制待确认 -> 已确认 -> 已完成
   |        |
   |        +-> 已取消
   +-> 已取消

• 租客发起预约时，订单状态为待确认，此时房东还没看到或者还没处理；
• 房东看到预约请求后，可以同意（状态变为已确认，同时把预约时间锁定）或拒绝（状态变为已取消，并填写拒绝理由）；
• 租客在待确认状态下也可以主动取消预约；
• 确认看房之后，系统提供"完成看房"按钮，点击后状态变为已完成，同时开启评价入口。

这个状态机不复杂，但特别适合用来讲"为什么我们要用状态字段而不是靠删除记录来实现取消"——因为业务上需要留痕，取消必须知道是谁在什么时间取消的，所以订单表里我会加cancel_reason、cancel_time两个字段，拒绝理由展示给租客看，这是整个流程里最体现"需求分析能力"的一处小细节。

3. 表结构设计：一版就被我否掉的初始方案

数据库设计是这个项目里返工最多的地方。学生最初给我的建表脚本里有一张表叫orders，用来存预约订单，但这张表里居然没有house_id，而是直接存了一个house_title字符串。他的理由是"这样查询的时候不用关联房子表，列表页直接显示"。这是典型的新手思路——为了查询方便，牺牲了数据的完整性和一致性。

如果房东把房源标题从"阳光两室一厅"改成"阳光两室一厅（近东门）"，那之前所有订单里记录的house_title就全部过期了，统计报表也做不了按房源维度的聚合。这种用冗余字段替代关联关系的方案，在这个场景下是绝对不划算的。最终表结构里，预约订单表必须包含的是house_id和tenant_id，通过外键逻辑关联房源和用户；显示名称在查询的时候用JOIN去取实时数据。

3.1 核心表的角色与关系

这个项目一共设计了8张核心表，我用一个表格列清楚它们的职责，方便你对照理解：

这里我想多说一下house_order表的order_no字段。很多同学做订单喜欢直接用自增主键当单号给用户看，但主键是自增的，用户之间可以通过ID差值推测出平台的订单量，这属于商业数据泄露；而且如果以后做多表分片，全局自增ID根本拼接不出来。所以我在订单表里加了一个业务单号字段，生成规则是日期+随机数的变体，比如20250416XXXXXX，在代码里通过UUID去掉横线截取一段拼上去。这个字段不参与任何业务关联，纯粹是给用户看和查询用的。答辩的时候主动提一句"自增ID不暴露给前端，业务上使用独立单号"，评委是能听出你做过工程的。

3.2 敏感字段的类型选择

还有两个字段非常容易踩坑，我在代码评审的时候被改过无数次：

第一个是价格字段。千万别用double或者float来存租金和押金，浮点数在数据库里的二进制转换会带来精度问题。我见过有人存了500.9，查出来变成500.8999999。正确做法是用decimal(10,2)，在Java实体里对应BigDecimal。这一点如果你练过算法题、刷过Java基础面试题，应该很清楚，但到了真正建表的时候非常容易疏忽。

第二个是时间字段。MySQL 5.7之后建议用datetime而不是varchar存时间，并且要统一设置时区。我记得当时学生本地连接数据库报"Server returns invalid timezone"错误，排查了半天，最后发现是MySQL的时区默认是UTC，而本机是东八区。解决方式是在JDBC连接串上加serverTimezone=Asia/Shanghai，或者在MySQL配置里把default-time-zone设置成+08:00。这类问题在毕设答辩的时候几乎年年出现，提前知道能省下大把调试时间。

还有一个Java侧的对应问题：实体类里日期字段用什么类型。我建议统一用java.time.LocalDateTime，不要再用老旧的java.util.Date。LocalDateTime配合Jackson的@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")注解，前后端传参非常直观，不会出现那种"日期变成一个长整型数字"的灵异现象。

4. SpringBoot核心实现：写代码时最值得讲给评委听的地方

技术栈定的是Spring Boot 2.7.x + MyBatis Plus + MySQL 8.0 + Redis + Vue 2 + Element UI。移动端适配不用做，毕设演示一般就是PC浏览器全屏放。下面这几个实现点，是我认为这个项目里"含金量"最高的，也是答辩时评委最爱追问的地方。

4.1 为什么Spring Boot版本不要追新

先说一个很多学生忽略的问题：Spring Boot 3.x 和 2.x 之间不是平滑升级，而是半条断桥。Spring Boot 3.0 基于 Spring Framework 6，强制要求 JDK 17，并且把 Java EE 的 javax.* 包换成了 jakarta.*。你如果习惯依赖某个老版本PageHelper、Shiro或者某个网上找的验证码工具类，它们内部写的是javax.servlet，放到Spring Boot 3.x下面直接编译报错，改起来非常痛苦。

对于毕设来说，时间比技术先进性宝贵得多。Spring Boot 2.7.18是2.x系列的最终版本，它支持JDK 8，兼容绝大多数网上的教程和报错方案，整合MyBatis Plus、Redis、JWT都是一行依赖加几行配置就能跑通。选型的第一原则是"你能掌控"，而不是"它最新"。这个道理放在你以后工作里也成立，能把一个稳定版本用到极致，比天天追新版本但遇到问题没人可问要务实得多。

4.2 MyBatis Plus的LambdaQueryWrapper

持久层用的MyBatis Plus，它的最大优势是单表操作不需要写XML，直接用LambdaQueryWrapper。比如房东查询自己发布的房源列表，代码长这样：

java复制public List<HouseInfo> listByLandlord(Long landlordId, Integer publishStatus) {
    LambdaQueryWrapper<HouseInfo> wrapper = Wrappers.lambdaQuery();
    wrapper.eq(HouseInfo::getLandlordId, landlordId)
           .eq(publishStatus != null, HouseInfo::getPublishStatus, publishStatus)
           .orderByDesc(HouseInfo::getCreateTime);
    return houseInfoMapper.selectList(wrapper);
}

注意这里eq的第二个参数传了publishStatus != null作为条件，意思是"只有当publishStatus不为空的时候才拼这个条件"。这个写法比写一堆if判断要优雅很多，也是MyBatis Plus官方推荐的动态SQL处理方式，面试时是加分项。

4.3 用JWT做登录鉴权，而不是Session

用户登录后的会话保持，我采用的是JWT（JSON Web Token）方案。核心流程是：

• 用户输入用户名密码，后端校验通过后生成一个Token，把用户ID和角色塞到Token的payload里；
• 前端拿到Token后存在localStorage里，每次请求在请求头带Authorization: Bearer <token>；
• 后端用拦截器统一解析Token，把当前登录用户放到ThreadLocal或请求上下文里，Service层直接取。

JWT的优点是服务端不存Session，天然支持多实例部署——虽然毕设用不上集群，但可以讲出来说明你理解无状态设计。缺点也存在，Token一旦签发，在过期之前是没法主动作废的。解决方案是给Token设置一个短过期时间（比如2小时），并配合Redis做一个黑名单，用户主动退出时把Token加入黑名单。为了防止每次请求都查Redis导致性能损耗，我在拦截器里加了一层本地缓存，用Caffeine存黑名单前缀，过期时间30秒。这个设计对于毕设来说已经是"锦上添花"级别了，答辩的时候主动讲出来，评委一般不会再追着问别的。

拦截器里有个非常关键的细节：放行登录接口、注册接口、房源列表页和详情页，因为未登录用户也应该能浏览房源列表和详情（这是真实产品的标准——你不可能让用户先注册才能看房）。判断逻辑是检查请求的URI是否命中白名单，不在白名单里的才去解析Token。这个白名单在WebMvcConfig里集中配置，不要散落在各个Controller上。

4.4 文件上传的本地路径与访问映射

房源图片上传是毕设里最常见的功能，但也是问题重灾区。我之前见过一个学生把图片存进MySQL的longblob字段里，说"这不也能显示吗"，后来项目一开图片全崩，数据库直接膨胀到好几个G。正确的做法是：图片上传到服务器的本地磁盘目录，数据库只存文件相对路径，前端拼一个URL去访问。

Spring Boot对静态资源映射提供了很简单的配置，在application.yml里加：

yaml复制spring:
  mvc:
    static-path-pattern: /upload/**
  web:
    resources:
      static-locations: file:D:/upload/

然后上传接口把文件写到D:/upload/目录，给前端返回/upload/20250416/xxxx.jpg这样的相对路径，数据库存的就是这个路径。前端拿到后直接拼接域名访问即可。

这里有个坑必须提醒：如果项目部署到服务器，别把上传目录写在 resources 或 classes 下面。Spring Boot打包成jar后，classes目录是只读的，运行时往里面写文件要么失败，要么重启后文件丢失（因为jar包没有真正解压）。我把所有文件写到独立的磁盘路径，既方便备份，也方便后续迁移到OSS或MinIO。答辩时如果有评委问"上传的文件重启后还在吗"，你就能给他讲清楚为什么选了本地磁盘而不是classpath。

4.5 定时任务清理过期预约

预约看房有一个业务场景：租客发起了预约，但房东三天没处理，这个预约就会一直挂着。真实平台肯定不会让这种脏数据无限堆积，所以我在项目里加了一个Spring自带的定时任务，每天早上2点跑一次：

java复制@Component
public class OrderCleanTask {
    @Scheduled(cron = "0 0 2 * * ?")
    public void autoCancelExpiredOrders() {
        // 找到状态为待确认且创建时间超过72小时的订单
        // 批量更新为已取消，取消原因写"超时未处理，系统自动取消"
    }
}

@Scheduled是Spring内置的轻量级定时任务注解，配合cron表达式就能跑，不需要引入Quartz。这个功能看起来不大，但它向评委展示了你对"系统自我维护"的考虑，不是只会写CRUD。另外，既然用了定时任务，别忘了在启动类上加@EnableScheduling注解，这是新手最容易漏的一步。

5. 部署与远程调试：跑不起来才是毕设最大的坑

项目写完了，登录页也做好了，本地IDEA里一把梭哈跑起来，诶，正常。结果到了要给老师演示的那天，换了一台电脑，数据库没配上，Redis没启动，端口被占用——演示直接翻车。这不是个别现象，而是每年毕设季的高频事故现场。下面这套流程是我让每个学生都按部就班做一遍的，做完之后项目"换电脑也能跑"的概率大大提升。

5.1 环境标准化：把"我本地能跑"变成"到哪都能跑"

环境问题有一大半来自"本地能跑"这个幻觉。你以为你的项目启动依赖的是MySQL，其实它还悄悄依赖了Redis——登录成功后Token的key要存Redis，你要是没装Redis或者没启动Redis服务，登录功能看着是好了，但换个环境秒挂。所以我要求项目里所有中间件的启动和配置都必须写进部署文档，逐条核对：

1. JDK版本：统一JDK 1.8，Maven配置<java.version>1.8</java.version>，本机java -version验证。
2. MySQL版本：8.0或5.7均可，但字符集要统一，建库时指定utf8mb4，避免中文乱码。
3. Redis：Windows下用redis-server.exe启动，Linux下用systemd或命令行启动，配置文件中不要写死单机IP，用localhost。
4. Maven依赖下载：如果公司或学校的网络环境访问Maven中央仓库慢，配置阿里云镜像。

我把这些写成一个环境准备清单.md，放在项目根目录，任何一个人拿到项目先看这个文档。这一点对毕设尤其重要——因为你的评委老师、你的队友不一定有和你一样的开发环境。

5.2 远程调试：人不在机房，也能把问题定位到行号

这个项目的卖点里有"远程调试"这个词。很多同学一听远程调试就发怵，觉得是高端操作，其实Spring Boot的远程调试非常简单，本质是JVM对外暴露一个调试端口，IDEA作为客户端连上去，像本地调试一样打断点、看变量。

实现步骤就两条：

• 服务端启动时加JVM参数：

bash复制java -jar project.jar --spring.profiles.active=prod -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005

• 本机IDEA配置"Remote JVM Debug"运行配置，Host填服务器IP，Port填5005，然后以Debug模式启动，就能连上远程运行中的项目。

这个能力在毕设场景下用处非常大。比如项目部署在阿里云服务器上，本地代码跑得好好的，远程一到某个接口就报错，这时候你连上远程调试，直接把断点打在Controller入口，一眼就能看出是参数没传过来还是数据库连接串没配对。比起一顿乱猜、到处打印日志，远程调试能帮你把问题定位精确到行号。不过要提醒一句：生产环境绝对不能开着调试端口，调试完第一时间把该参数去掉，因为调试端口等于给攻击者开了一扇后门，这一点我在文档里加粗标注了。

5.3 跑项目过程中的"高频翻车点"

把学生在部署过程中遇到过的报错汇总一下，几乎每次都能归到下面这几类，我列出来供你对照排查：

每一条都对应真实的调试经历，而不是书上抄来的。建议你把这张表也贴进项目文档里，答辩老师翻文档看到这种"面向实际问题的排错表"，比看一堆环境截图有说服力得多。

5.4 演示环境的"定妆照"

项目做完之后，我还会让学生专门做一遍"演示环境和正式开发环境分离"。开发环境用本地的MySQL和Redis，演示环境用服务器上的MySQL和Redis，两者通过application-dev.yml和application-prod.yml区分，启动时用--spring.profiles.active=dev/prod指定。

为什么要这么做？因为毕设答辩那天，现场的网络状况是不可控的。如果你现场演示连的是本地数据库，万一老师电脑接的是校园网，你的项目启动时又去连外网数据库，卡顿一下，体验就差了。稳妥做法是：演示环境的MySQL和Redis全装在一台机器上，项目也打包部署在那台机器上，全程不依赖外网。实测下来，这种方式在答辩现场最稳，几乎不会出幺蛾子。

6. 文档三件套：代码之外的半壁江山

毕设评分从来不是只看代码，文档和答辩表现通常占30%-40%的比重。很多学生代码写完了，觉得万事大吉，结果开题报告、任务书、毕业论文堆到答辩前两周才开始动笔，最后只能东拼西凑。我的建议是：文档和代码同步推进，代码写完一个模块，就更新一次文档。

6.1 开题报告与任务书的核心是"问题-方案"

开题报告最容易写空。通篇"为了解决大学生租房难的问题，本系统基于SpringBoot开发……"，写了两页全是套话。评审老师一眼就能看出来你没想清楚。正确写法是：

• 背景部分：用数据或调研证据说明现状，比如"某高校周边租房信息主要发布在QQ群和贴吧，信息格式不统一，价格和实景往往不符"；
• 国内外现状：对比现有产品（贝壳、自如、58），指出它们在校园场景下的不足，以及你的系统做了什么差异化（比如面向本校学生、简化流程、学号认证）；
• 研究内容：直接列功能模块和核心技术点，不要再用"研究与实现XX系统"这种话来回说；
• 预期成果：需要具体到"一个可运行的Web系统、一份完整的数据库设计文档、一篇不少于1.5万字的毕业论文"。

任务书相对格式化，把每个阶段要交的东西写清楚就行，比如第二周完成需求分析和原型设计，第四周完成数据库设计与基础框架搭建，第六周完成核心模块编码并自测，第八周完成论文初稿。

6.2 毕业论文的结构先定在这里

毕业论文建议用这个标准结构，既能满足大多数学校的要求，又容易写：

很多学生怕写论文，其实关键就一句话：把代码实现翻译成别人能看懂的语言，不用炫技，但要说清楚"我为什么这么写"。比如第5章里讲到房源检索，不要只贴一堆查询代码，要先说"为了支持多条件组合筛选，我设计了HouseQueryDTO类承载查询参数，在Service层通过LambdaQueryWrapper动态拼接SQL"——这就是从"敲代码的人"到"做方案的人"的转变，论文的评分标准也恰恰看这个。

6.3 答辩PPT和演示脚本

答辩PPT页数以10-12页为佳，重点排序是：项目背景（2页）、技术架构（2页）、功能演示的截图或录屏（4页）、核心代码或难点讲解（2页）、总结与心得（1页）。功能演示部分最好提前录一段视频，防止现场网络或浏览器出问题。我还要求学生写一个"演示脚本"，就是每一页PPT要讲什么、点哪个按钮、展示什么功能，提前对着讲三遍。这个脚本看着笨，但到了答辩紧张的时候，你照着讲就能稳住节奏，不会出现"嗯，这个，然后那个"的尴尬停顿。

配套的还有PPT里放一张清晰的系统功能架构图，用简单的分层结构就行：

code复制表现层: Vue前端页面
接口层: Spring Boot RESTful API
业务层: 房源/订单/用户/权限/公告
数据层: MySQL(主数据) + Redis(缓存/Token)

这张图能帮你把所有内容串起来，每次讲到模块之间的关系时，指着图说会比凭空描述直观得多。

7. 定制扩展：这个项目还能长成什么样

最后说一点关于"定制"和"后续完善"的思路。很多学生拿到一个毕设项目之后，需求是"做完就行"，但如果你想让项目在答辩中脱颖而出，或者之后写进简历里去面试，下面这几个方向改动成本不高，但提升效果非常明显。

7.1 增加预约看房的时段选择功能

目前预约订单只是"某天去看房"，粒度比较粗。可以在订单表加一个visit_time字段，前端做成日期+时间段选择（上午/下午/晚上），房东在后台可以设置每周可预约的时段，租客只能选房东开放的时间段。实现起来就是在房源表加一个visit_schedule字段，存JSON字符串，后端用Jackson解析，改动量不大，但功能体验会明显更完整。这也能顺势讲一讲"为什么用JSON字段存这类结构不固定的小配置"——因为不方便建子表去存，但JSON的校验和解析成本都很低，适合这种低频小配置的场景。

7.2 多条件组合检索的索引优化

房源列表页会支持按区域、价格区间、户型、朝向、发布时间排序等条件组合查询。当前实现用的是LambdaQueryWrapper动态拼接，数据量几百条时完全没问题。但如果你想让项目更有深度，可以在house_info表的常用查询字段上建联合索引，比如：

sql复制ALTER TABLE house_info ADD INDEX idx_area_price (area_id, price);

然后主动聊一聊联合索引的最左前缀原则——为什么索引里area_id要放在price前面，因为业务查询一定是先有区域再有价格范围，这符合最左前缀的匹配规则。这个知识点在Java面试八股文里也是常客，写在毕设里等于提前预习了。

7.3 接入简单的消息通知

用户视角下，房东同意或拒绝预约、管理员下架了房源，都应该收到系统通知。当前我可以只做到在列表页有一个"我的消息"入口，展示来自通知表的数据，但如果你想让项目互动感更强，可以引入WebSocket，房东拒绝预约后，前端租客页面实时弹出一条消息。Spring Boot整合WebSocket非常方便，写一个Handler类加一个配置类就能用。答辩的时候现场演示"房东在后台点拒绝，租客页面右上角红色气泡+1"这个效果，冲击力是很大的。

我个人在带着学生打磨这个项目的过程中最大的体会是：毕设项目真正的价值不在于它多新颖、多复杂，而在于你能否把每一个设计和每一次排错用别人能听懂的方式讲清楚。一个能把"为什么订单状态要单独用一个字段而不是删除记录"讲明白的同学，和一个能写出复杂算法题却说不清业务逻辑的同学，后者在实际工作中反而会更吃力。所以这篇文章里我刻意花了很多篇幅在"为什么这么做"上面，而不是只给技术方案。希望它对你完成自己的毕设、或者在答辩中拿到一个不错的成绩，能真正帮上忙。