Spring Boot在线房屋出租系统毕设实战：从设计到部署全解析

做毕设选方向时，我最后定在了基于Spring Boot的在线房屋出租系统。这个题目看起来常见，但房屋出租天然包含用户、房源、订单、预约几条核心业务线，既能覆盖常规的增删改查，又能往权限控制、状态流转、文件上传、条件检索这些方向做深度拓展，不管是应付答辩还是往简历上写，都有东西可讲。这套系统我完整从零写了一遍，从数据库设计到前后端联调，再到打包部署，中间踩了不少坑。今天把整个设计思路和落地过程整理出来，给正在选型、开工或者已经写到一半的同学做一个完整参考。

1. 项目定位与需求分析

1.1 毕设选题的现实考量

选“在线房屋出租系统”作为毕设题目，理由其实很实在。房屋出租这个场景足够生活化，不需要额外解释业务背景，评委老师一看就懂。找房的人需要快速浏览房源、按价格和区域筛选、预约看房；房东需要发布房源、管理上架下架、处理租客的预约和订单；平台管理员负责审核房源、统计运营数据。这个三角色模型，正好把系统分成了前台租房端和后台管理端，功能边界非常清晰。

更关键的是，这个项目的技术点能刚好卡在“有难度但不至于失控”的位置上。纯CRUD显得单薄，高并发分布式又不切实际。房屋出租系统只要把搜索筛选、预约流程、订单状态机、图片上传这几块做好，技术上就已经能撑起一篇不错的毕设论文了。如果还能加上JWT登录鉴权、逻辑删除、数据统计，那在答辩时谈技术亮点就有了充足素材。

我最终的项目选型是前后端分离架构：后端Spring Boot + MyBatis-Plus + MySQL，前端Vue 3 + Element Plus + Axios。源码工程编号51207，整体结构是标准的前后端分离目录，开发时用Vite代理解决跨域，部署时后端打包成jar包，前端打包成静态资源交给Nginx托管。

1.2 系统业务角色与核心流程

系统一共有三类角色，权限完全隔离，登录后进入的页面也完全不同。

• 租客用户：注册登录、浏览房源、按条件筛选、收藏房源、在线预约看房、提交租赁订单。
• 房东用户：房源管理（发布、编辑、上架、下架）、查看预约请求并确认、处理订单签约和退租。
• 平台管理员：用户管理、房源审核（决定是否允许上架）、订单监督、租金成交数据统计、公告管理。

三种角色的核心业务闭环是这样流转的：房东发布房源 -> 管理员审核通过 -> 房源自动上架展示 -> 租客搜索筛选并预约看房 -> 房东确认预约 -> 租客下单并支付定金（模拟） -> 系统生成正式租赁订单 -> 到期退租。

这个闭环把订单状态和房源状态绑在了一起，比如房源被下单后不能再被其他人重复下单，状态要自动变成“已租出”，退租后又回到“上架中”。这一套状态联动是整个系统的业务核心，也是答辩时最容易展现设计思路的地方。

1.3 功能模块表

模块列表看着多，但每个模块并没有做得特别复杂，都是在围绕“房子租出去”这条主链服务。

2. 技术架构与核心设计

2.1 为什么是Spring Boot而不是SSM或Spring Cloud

一开始我也纠结过要不要用SSH那套老框架，后来直接否了。Spring Boot最核心的价值就是自动配置和内置服务器，让人能把精力放在业务逻辑上而不是XML配置上。对于一个毕设项目来说，Spring Boot能大大缩短环境搭建时间，出问题的概率也低。相比之下，SSM框架光是配Spring和MyBatis的XML就要半天，Spring Cloud对毕设来说又明显超纲，微服务拆分、注册中心这些概念在单机演示环境下毫无意义。

我使用的是Spring Boot 2.7.18，配合JDK 8。这个版本组合在2024年依然是最稳妥的，网上资料多，遇到问题搜索时能找到大量现成答案。如果非要用Spring Boot 3.x，那JDK版本必须升到17，某些老版本的第三方依赖也会出现兼容性问题，没必要给自己加风险。

2.2 后端整体分层结构

后端工程采用经典的三层架构，在我在源码工程中是这样组织的：

com.house.rent ├── controller // 接口层，接收请求参数并返回R对象 ├── service // 业务层，处理核心逻辑 │ └── impl ├── mapper // 数据访问层，继承BaseMapper ├── entity // 数据库实体类 ├── dto // 请求参数对象 ├── vo // 响应结果对象 ├── config // 配置类（跨域、拦截器、资源映射、MyBatis-Plus分页） ├── common // 通用类（R统一返回体、异常处理、常量） └── utils // 工具类（JWT工具、文件上传工具）

controller层很薄，只负责接收参数和调用service，不允许直接写SQL或业务逻辑。service层承载核心业务，比如下单时校验房源状态、生成订单号、更新房源状态，这些都是事务方法，需要加@Transactional。mapper层就继承MyBatis-Plus的BaseMapper，复杂查询用LambdaQueryWrapper构造，特殊统计SQL就自己写注解SQL或XML。

2.3 数据库表设计

数据库设计是这套系统的地基，我踩过最大的坑就是一开始把字段类型和状态字段设计得太随意，导致后面前端显示和统计查询到处出问题。最后的表结构包含7张核心表。

用户表 sys_user：

密码必须加密存储，我在项目里用了Spring Security Crypto模块的BCryptPasswordEncoder，不需要引入全套Spring Security，拿过来就能用。明文密码入库这种事在答辩时被问到会很尴尬。

房源表 house_info：

房源状态字段用数字枚举而不是字符串，理由很简单：数字比较效率高、存储省空间、前端映射也方便。我在VO层统一做数值到文本的转换，比如0转“待审核”，1转“上架中”，这样前端拿到的直接是可读文案。

预约表 appointment、订单表 lease_order、收藏表 favorite 的设计核心是状态字段：

• 预约状态：0-待确认 1-已确认 2-已取消 3-已完成
• 订单状态：0-待支付 1-生效中 2-已退租 3-已取消
• 支付状态：0-未支付 1-已支付

订单号我用时间戳加随机数生成，格式如“LO202405201530001234”，保证唯一，还方便用户和管理员快速识别。

3. 核心功能模块详细拆解

3.1 用户注册、登录与JWT鉴权

登录模块如果只做一个简单的Session存取，那答辩时基本没有亮点可讲。我在项目里用了JWT方案，后端登录成功后签发一个token返回给前端，前端把它存在localStorage里，每次请求通过Authorization请求头带过来。后端写了一个拦截器，拦截除登录、注册、房源列表、房源详情以外的所有接口，校验token是否有效。

JWT的核心配置就几行：

jwt: secret: house-rent-secret-key-2024 expire: 86400000

拦截器里校验token时，把解析出来的userId和role放进ThreadLocal或Request attribute里，后续service层就能直接拿到当前登录人信息，不需要每次从数据库查。要注意的是JWT的secret不要写得太短，否则容易被暴力破解，项目里这个只是演示用，实际生产必须用足够长的随机字符串。

密码加密的逻辑很简单：

String rawPassword = "123456"; String encoded = new BCryptPasswordEncoder().encode(rawPassword); // 校验时 boolean matches = new BCryptPasswordEncoder().matches(rawPassword, encoded);

这个方案的好处在于，即使数据库泄露，攻击者拿到的也是不可逆的加密串，无法反推出原始密码。答辩时老师如果问“密码安全怎么做的”，这已经是一个合格的回答。

3.2 房源发布与图片上传

房东发布房源是这个系统里交互最重的功能。前端表单包括标题、描述、价格、面积、户型、朝向、区域、详细地址、租赁方式、房源图片，一张表单提交后后端需要同时保存房源信息和图片URL。

图片上传我采用本地磁盘存储方案，在application.yml里配置上传路径：

file: upload-path: D:/house-rent/upload/ access-path: /images/**

后端写一个FileUploadConfig，通过WebMvcConfigurer把本地上传目录映射成虚拟访问路径。这样前端img标签可以直接使用/images/xxx.jpg访问图片，不需要经过接口转发。上传接口接收MultipartFile，按日期加UUID生成文件名，避免重名覆盖。

这里有个坑要注意：Spring Boot默认上传文件大小限制是1MB，随便一张手机照片就超了。必须在配置里放开：

spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB

不配这个，前端上传图片时总会莫名其妙报文件大小超限，而且错误信息还不直观，排查起来浪费时间。

3.3 房源搜索与多条件筛选

搜索筛选是前台的核心功能，我做成了动态条件构造。用户可以在前端同时勾选区域、价格区间、户型、租赁方式，还能输入标题关键词。这些条件全部通过GET请求参数传递，后端用LambdaQueryWrapper动态拼接SQL条件。

核心查询代码大致是这个形态：

LambdaQueryWrapper<HouseInfo> wrapper = Wrappers.lambdaQuery(); wrapper.eq(HouseInfo::getStatus, 1); // 只查上架中 if (StringUtils.hasText(keyword)) { wrapper.like(HouseInfo::getTitle, keyword); } if (StringUtils.hasText(district)) { wrapper.eq(HouseInfo::getDistrict, district); } if (StringUtils.hasText(houseType)) { wrapper.eq(HouseInfo::getHouseType, houseType); } if (rentType != null) { wrapper.eq(HouseInfo::getRentType, rentType); } if (minPrice != null) { wrapper.ge(HouseInfo::getPrice, minPrice); } if (maxPrice != null) { wrapper.le(HouseInfo::getPrice, maxPrice); } wrapper.orderByDesc(HouseInfo::getCreateTime);

用LambdaQueryWrapper的好处是不用手写SQL，而且字段名是强类型引用，编译期就能发现字段名拼写错误，这种查询在毕设项目里比写XML更不容易出bug。分页就交给MyBatis-Plus的Page对象：

Page<HouseInfo> page = new Page<>(pageNum, pageSize);

响应中返回总条数、总页数、当前页数据，前端分页组件直接绑定即可。

3.4 预约看房与租赁订单状态流转

预约流程看起来只是插入一条记录，其实要考虑状态联动。租客提交预约时，系统要校验房源是否存在且处于“上架中”状态，同时要检查当前用户是否已经预约过这套房源，避免重复提交。房东端看到预约请求后，可以选择确认或取消；确认后租客就会收到状态更新，同时系统自动生成一条待支付的租赁订单。

订单创建这个操作非常典型，涉及多张表的联动，我用一个事务方法搞定：

@Transactional public LeaseOrder createOrder(CreateOrderDTO dto) { // 1. 校验房源状态必须是上架中 HouseInfo house = houseMapper.selectById(dto.getHouseId()); if (house == null || house.getStatus() != 1) { throw new BusinessException("房源不存在或未上架"); } // 2. 计算租金总额 BigDecimal total = house.getPrice().multiply(new BigDecimal(dto.getMonths())); // 3. 生成订单号 String orderNo = generateOrderNo(); // 4. 创建订单记录 LeaseOrder order = new LeaseOrder(); // ... 设置订单字段 leaseOrderMapper.insert(order); // 5. 更新房源状态为已租出 house.setStatus(3); houseMapper.updateById(house); return order; }

注意@Transactional在这里为什么重要：如果订单插入成功但房源状态更新失败，事务会回滚，不会出现“订单存在但房子还能被其他人租”这种数据不一致的情况。这个设计在答辩时非常加分，建议作为重点讲给评委听。

订单状态流转我专门画了一张状态表（不是流程图，是一个简洁的文字描述）：

• 创建订单（待支付） -> 租客点“模拟支付” -> 已支付（生效中）
• 生效中 -> 租客申请退租 / 到期自动退租 -> 已退租（房源重新上架）
• 待支付超时或租客取消 -> 已取消（房源回到上架中）

每变更一次订单状态，都要同步更新对应房源的状态。这个一致性约束是系统最关键的逻辑，评审老师大概率会围绕它提问。

4. 关键实操环节与部署配置

4.1 环境准备与工程初始化

后端开发环境我用了IDEA + Maven 3.8 + JDK 8 + MySQL 5.7（或8.0均可），前端用VS Code + Node 16 + npm。项目初始化不需要从零敲代码，直接在Spring Initializr选择Spring Boot 2.7.18，勾选Web、MySQL Driver、MyBatis-Plus、Lombok依赖即可。

如果你拿到的源码里没有初始依赖，手动在pom.xml补上这几块核心依赖：

<dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency> <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-crypto</artifactId> </dependency> <dependency> <groupId>cn.hutool</groupId> <artifactId>hutool-all</artifactId> <version>5.8.22</version> </dependency>

Hutool这个工具包强烈建议加上，生成随机验证码、日期格式化、ID生成、文件类型判断都有现成方法，能省下很多重复代码。毕设项目追求的不一定是代码行数，而是逻辑清晰，能用成熟工具解决的问题不要自己造轮子。

4.2 数据库初始化脚本

源码里自带SQL脚本，直接导入MySQL即可。如果没有脚本，按前面章节的表结构建表，注意几点：

• 所有表的主键用bigint自增，不要用varchar当主键。
• 金额字段必须用decimal，不要用double或float，不然算钱时出现0.1+0.2不等于0.3的问题会很尴尬。
• 创建时间字段统一叫create_time，更新时间叫update_time，不要有的表叫createDate有的叫gmtCreate，统一命名能少很多无谓的查错。
• 状态字段统一加注释说明枚举含义，不然半年后自己都看不懂0和1分别代表什么。

4.3 application.yml 核心配置解析

整个后端最关键的就是这个配置文件，很多同学项目起不来、图片访问不了、时间格式不对，都是配置问题：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/house_rent?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: root servlet: multipart: max-file-size: 10MB max-request-size: 20MB jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

datasource的URL里serverTimezone=Asia/Shanghai非常重要。数据库连接时如果时区不匹配，查出来的时间会比实际时间少8小时。这个坑我踩过，后来排查了很久才发现是时区问题。

MyBatis-Plus的逻辑删除配置也在这里配好。给需要保留痕迹的表加上deleted字段，执行delete操作时就会自动变成update，这比物理删除更安全，也方便以后做数据恢复和分析。

4.4 前端Vue渐进配置与代理

前端使用Vue 3 + Vite + Element Plus + Axios。页面结构大致是：登录注册页、首页（房源列表）、房源详情页、个人中心（我的预约/我的订单/我的收藏）、房东后台、管理后台。

Vite开发服务器需要配置代理，把前端的/api请求转发到后端8080端口：

export default defineConfig({ server: { port: 3000, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } })

Axios统一封装请求，在每个请求的拦截器里读取localStorage中的token并添加到请求头：

axios.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = token } return config })

后端接口路径统一带/api前缀，这样代理和部署时的路径都很好配。

4.5 项目打包与部署

后端打包非常简单，在Maven面板执行package命令，或者命令行运行：

mvn clean package -DskipTests

打包后在target目录生成一个可执行jar包，服务器上安装JDK后直接运行：

java -jar house-rent-0.0.1.jar

前端打包：

npm run build

打包生成的dist目录就是纯静态文件，交给Nginx托管，配置一个localtion指向dist目录。如果是单台服务器演示，还可以让Nginx把/api请求反向代理到8080端口，实现前后端一体访问。

如果只是本地跑一版用于演示和答辩，完全可以跳过Nginx，后端跑起来后前端用开发模式npm run dev，通过Vite代理请求后端接口。这个方案最省事，适合答辩现场的备用演示方案。

5. 常见问题与避坑实录

5.1 高频Bug排查清单

其中跨域问题是最常见也最容易被忽视的。前端跑在3000端口，后端跑在8080端口，直接请求必然会有跨域限制。我的做法是后端统一加了一个CorsFilter允许所有来源，前端开发时再用Vite代理，双保险。

5.2 为什么数据库时间格式显示异常

之前提到过时区问题，这里详细解释一下。MySQL连接的serverTimezone参数如果不设置，默认使用的时区可能和本地时区不一致，数据库里存的是UTC时间，查询出来转换后就差了8小时。Spring Boot在返回JSON时，Jackson序列化又把时间对象格式化成utc，前端显示自然就错乱了。

最稳妥的做法是三管齐下：

1. 数据源URL加serverTimezone=Asia/Shanghai
2. Spring Boot配置里设置jackson的time-zone为GMT+8
3. MySQL建表时时间字段直接定义成datetime并交给后端处理

只要这三处保持一致，时间显示就不会出幺蛾子。

5.3 代码规范与命名建议

毕设代码虽然不需要达到生产级标准，但命名规范做得好不好，答辩老师扫一眼就知道态度。我的建议是：

• 类名用名词，方法名用动词开头。比如HouseService、createOrder()、deleteAppointment()。
• 接口返回统一用R对象，结构为code、message、data三个字段。所有接口都遵循这个格式，前端处理起来非常一致。
• controller方法的映射路径用复数资源名，如/api/houses、/api/orders、/api/appointments。
• 常量不要散落各处写魔法值，统一放到常量类中管理。比如房源状态的1和3，定义成公共常量后，代码可读性会高很多。
• service方法必须写注释，说明业务规则。比如创建订单方法要标明“校验房源上架中、计算总额、联动更新房源状态”这几个步骤。

这些细节不会直接让系统跑得更快，但会让代码看起来更像一个规范的工程，而不是应付交差的demo。

5.4 答辩高频问题准备清单

答辩的时候老师最喜欢问的几个方向，我把题库和参考答案都整理出来了。

问：为什么选择Spring Boot？

答：Spring Boot的自动配置机制降低了项目搭建成本，内置Tomcat让部署更简单，开发时不用再像SSM那样写大量的XML配置。对于房屋出租这种业务边界清晰的系统，Spring Boot能让我把主要精力放在核心业务逻辑上。

问：数据库表之间的关系是怎样的？

答：用户和房源是一对多（一个房东可以发布多套房源），用户和预约是一对多（一个租客可以预约多套房源），预约和房源是多对一，订单和房源和用户分别多对一。核心是房源表作为中间业务的载体，订单和预约都通过外键关联到用户ID和房源ID。

问：如何保证订单数据的一致性？

答：创建订单的操作使用@Transactional事务注解，Spring会在运行时把插入订单和更新房源状态放到同一个数据库事务中。任何一步失败，整个事务回滚，不会出现订单存在但房源状态没更新的情况。同时在下单前做了状态校验，只有上架中的房源才能被下单。

问：系统如何防止SQL注入？

答：项目使用MyBatis-Plus的LambdaQueryWrapper构造查询条件，参数通过预编译绑定，不会直接拼接SQL。对于自定义SQL，也统一使用#{}占位符。这样从框架层面规避了SQL注入风险。

问：密码为什么用BCrypt加密？

答：BCrypt算法内置随机盐，相同密码每次生成的密文都不同，而且算法本身设计为慢速哈希，能有效抵抗彩虹表攻击和暴力破解。相比MD5直接加密，安全性高很多。

6. 项目延展方向与后续优化空间

这套系统作为毕设自然没有问题，但如果想在工作面试时把项目作为谈资，还有几个方向可以继续优化。

第一是引入Redis。目前预约时间和房源数据都是直接查数据库，如果数据量上来，热点房源的高频浏览会对数据库产生压力。可以把房源详情缓存到Redis，设置过期时间；预约状态变更时，先更新数据库再删除缓存，保证数据最终一致。

第二是消息通知。目前的“房东确认预约”“订单创建成功”都是靠用户在页面上刷新才能看到。可以引入WebSocket或者使用Spring的事件机制，在这个动作发生时主动推送通知，让用户体验更好。

第三是支付模块。现在模拟支付就是点一下按钮把支付状态改成已支付。如果要接近真实业务，可以接入沙箱环境，对接支付回调接口，这里涉及签名验证和回调幂等处理，含金量比模拟支付高不少。

第四是数据可视化。管理后台目前只有表格和简单统计，可以引入ECharts把每月成交订单量、热门区域房源数、租金价格分布做成折线图、柱状图和饼图，一眼就能看懂运营情况。这个在答辩现场演示效果很好。

我做这套系统最有价值的心得是：不要追求技术栈的新和全，而是把一个闭环业务真正跑通，把每个关键决策都讲得出理由。Spring Boot在线房屋出租系统看起来是个常见的题目，但只要把状态联动、事务一致性、权限控制、安全防护这些点讲透，它完全有潜力成为一份高分毕设，也能为后续的项目经验积累打下扎实基础。如果你们也在做类似的系统，欢迎按这篇文章的思路试着重构一遍，或者在做完后想一想那些延展方向，体验会很不一样。