每年到了毕设季，我都会收到不少"求助信号"：能不能帮我看看SpringBoot做房屋租赁系统的思路？需求文档写什么？表怎么建？说白了，大多数人的毕设题目都是"XX管理系统"，最后做出来就是一个增删改查的壳子，答辩时一问业务流程就露馅。房屋租赁系统算是这类题目里比较有代表性的——看着不复杂，但真正动手后你会发现，它里面装着角色权限、房源状态流转、租赁合同、租金账单这些"真业务"问题。这篇文章就围绕这个项目展开，讲清楚你是怎么一步步把它设计出来、实现出来，以及实测中那些教科书上不会写的问题。

这套系统面向三类使用者：租客、房主（管理员）、后台运营人员。租客端负责找房、预约、签约、交租；房主端负责发房、管理预约和处理退租；后台负责审核房源和用户、监控合同与账单。整个项目的核心价值不在于"把数据存进数据库"，而在于用一套清晰的状态机、一套可靠的权限模型，把租赁这件事从"发布房源"到"退租离场"的完整链路管起来。下面按实际开发顺序，把设计和实现过程完整拆一遍。

1. 开工之前先定边界：租房系统的核心业务场景拆解

1.1 三类角色和三条贯穿全局的业务链路

拿到题目第一步，不是去下载一个乱七八糟的项目模板，而是把业务规则写清楚。房屋租赁系统表面上的用户是"租客"和"房主"，但实际真正撑起系统后台的是管理员。我习惯把角色分成三种：

• 租客（普通用户）：注册登录、浏览房源、收藏房源、线上预约看房、发起租赁请求、在线签订合同、查看租金账单、提交退租申请。
• 房主：发布新房源、编辑房源、托管房源上下架、处理预约看房请求、查看租赁中的合同和账单流水。
• 管理员：审核房主和房源、封禁违规用户、查看全站合同状态、处理投诉和退款纠纷、维护区域/户型等基础字典。

这里有一个很容易被忽略的设计点：房主和管理员不应该只是"用户表里加一个角色字段"，因为他们的操作域完全不同。房主核心操作的是"我的资产"，管理员操作的是"平台秩序"，这两类数据权限如果混在同一个接口里，后期每一个查询都要写很多重复的角色判断代码。

三条全局链路是：房源发布审核链、租赁交易链、租后退租链。项目的一切功能模块，都能挂在这三条链路的某个节点上。我在需求分析阶段做的最有用的一件事，就是画了一张"状态-动作-责任人"的表格（后面第4节会展开讲），把它贴在了项目文档最前面。后续所有接口设计、建表、权限注解，都以这张表为准。

1.2 需求里的"智能化"到底落在哪里

标题里有"智能化"三个字，很多同学会纠结要不要上推荐算法、爬虫抓房价数据之类的东西。我的意见是，毕设体量里真正的"智能化"要落在三件实际的事上：

• 租金价格合理性提示：房主发布房源时，系统根据同区域、同户型的平均租金给一个建议价位区间，防止离谱定价；
• 房源推荐排序：租客端首页不用按时间排序，而是根据区域热度、房源浏览量、价格匹配程度做一个带权重的推荐列表；
• 租赁到期自动提醒：合同快到期时自动生成账单和站内通知，不需要人工盯。

这三件事的技术含量都在可完成范围内，又能让答辩老师看到你不是只写了CURD。尤其第一点，本质上就是一个分组聚合查询，加上一个简单的标准差计算，性价比非常高。

1.3 明确边界：这个版本明确不做的事

同样重要的是划掉"不做的事"。我给自己定的底线是：不做地图找房（高德API缺乏备案）、不做在线支付对接（涉及商户资质）、不做电子签章（涉及CA接口）。这些功能如果硬做，单是资质和调试成本就能耗掉一个月。

为了避免后续自我膨胀加需求，我在项目里把它们全部延后为"二期规划"，只预留了bill表中的pay_status字段和payment_order_no字段，方便以后扩展支付回调。这一步对于控制毕设进度非常重要。

2. 技术选型思路：为什么SpringBoot在这一类系统里是"合适"而不是"跟风"

2.1 技术栈对比：解决什么问题，而非追逐新框架

很多同学一上来就问"要不要用微服务""是不是该用Redis存Session"。我的回答往往是：先看问题规模。房屋租赁这类管理信息系统，核心诉求是：稳定地增删改查、清晰地权限控制、快速地开发迭代、方便地打包部署。在这个前提下，SpringBoot不是"标配"，而是"性价比匹配"。

• 对于单体应用，SpringBoot的自动配置极大减少了XML配置量，一个内嵌Tomcat就能直接跑起来；
• Spring生态里Security、Validation、Data等组件能无缝整合，做权限和参数校验不用东拼西凑；
• 相比SSM框架，SpringBoot的起步依赖机制能把你需要的库锁定到兼容版本，少踩很多版本冲突的坑。

这里我不建议为了"炫技"强行把Nginx、Redis、RabbitMQ全部堆上去。如果Redis唯一用途是存登录状态，而项目本身部署在低配服务器上，那它带来的收益几乎可以忽略，却增加了答题时被追问"如果Redis挂了怎么降级"的风险。当然，如果后续要把房源信息缓存起来缓解数据库压力，Redis可以作为优化项加入，但那是性能测试之后的事情。

2.2 我的实际选择与依赖清单

我的最终技术栈是：SpringBoot 2.7.x + MyBatis-Plus 3.5.x + MySQL 8.0 + Spring Security（配合JWT）+ Redis（只做验证码缓存和远期优化预留）+ Vue 3（前端分离开发）。需要说明的是，如果前端基础一般，也可以直接用Thymeleaf做服务端渲染，减少跨域联调成本。但考虑到毕设答辩时"前后端分离"往往是一个加分展示点，我还是选了Vue 3 + Element Plus。

Maven依赖里最核心的几项：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-api</artifactId> <version>0.11.5</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency>

2.3 项目骨架初始化的几个关键动作

初始化SpringBoot项目，我习惯用Spring Initializr。有三个细节值得注意：第一，Java版本选8或11，不要选太高，不然部署环境的兼容性是个隐患；第二，Spring Security和Validation必须一起引入，否则后面写参数校验会反复补依赖；第三，MyBatis-Plus的版本一定要和SpringBoot版本匹配好，我用的2.7.x搭配3.5.x没有任何冲突。

其次，一定要在application.yml里把数据库连接和MyBatisPlus配置写清楚，尤其是下划线转驼峰、逻辑删除这两项，它们是后续所有表操作的基础。

spring: datasource: url: jdbc:mysql://localhost:3306/house_rent?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

配置好之后，先写一个最简单的用户查询接口跑通全链路，再做后续模块。

2.4 选择持久层框架的另一个原因

MyBatis-Plus在CRUD上几乎不需要写SQL，这对开发效率提升非常大。但这不意味着你要完全放弃SQL。像"根据区域热度生成推荐房源""统计每月租金收入"这类稍复杂的查询，手写XML里的自定义SQL仍然是最可靠的方式。

举个例子，同区域平均租金对比功能，最初我用Java代码把同区域所有租金查出来，再在内存里求平均值，结果房源多了以后接口响应直接从100ms涨到了600ms。后来改成一条SQL聚合查询，时间降回70ms。这个教训说明：ORM解决的是"常规操作别重复写SQL"，真正的统计和聚合还是要回到数据库。

3. 数据库设计：这九张表决定了业务能做多深

3.1 核心表的组织方式

一个房屋租赁系统的数据库，我最终落成了九张核心表和两张辅助表。这里按业务模块分组：

• 用户模块：user（用户表）、user_verify（身份认证信息表）
• 房源模块：house（房源表）、house_audit（审核记录表）、house_favorite（收藏表）
• 租赁模块：appointment（预约看房表）、lease_contract（租赁合同表）、rent_bill（租金账单表）
• 基础配置：region（区域表）、house_type（户型字典表）

设计原则有一条：凡是需要"可追溯"的数据，就不能只留下最终状态，还要留一张操作记录表。比如房源审核，如果没有house_audit这张表，出了问题你只能看到房子现在审核通过，却根本不知道管理员什么时候、因为什么理由通过的。这在真实业务中是致命伤，在答辩时也是一个"我考虑了业务可追溯性"的极佳展示点。

3.2 用户表和房源表的字段设计细节

user表的关键字段：

CREATE TABLE `user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '登录账号', `password` varchar(100) NOT NULL COMMENT 'BCrypt加密后密码', `phone` varchar(20) DEFAULT NULL, `avatar_url` varchar(200) DEFAULT NULL, `role` tinyint(4) NOT NULL DEFAULT 1 COMMENT '1租客 2房主 3管理员', `status` tinyint(4) NOT NULL DEFAULT 0 COMMENT '0正常 1封禁', `deleted` tinyint(1) NOT NULL DEFAULT 0, `create_time` datetime NOT NULL, `update_time` datetime NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

house表的关键字段会多一些：

CREATE TABLE `house` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `owner_id` bigint(20) NOT NULL COMMENT '房东用户ID', `title` varchar(100) NOT NULL, `region_id` bigint(20) DEFAULT NULL COMMENT '区域ID', `address` varchar(255) NOT NULL, `house_type_id` bigint(20) DEFAULT NULL COMMENT '户型ID', `area` decimal(10,2) DEFAULT NULL COMMENT '面积（平方米）', `rent_price` decimal(10,2) NOT NULL COMMENT '月租金（元）', `status` tinyint(4) NOT NULL DEFAULT 0 COMMENT '0待审核 1已上架 2已预订 3已出租 4已下架 5审核驳回', `audit_remark` varchar(255) DEFAULT NULL, `cover_url` varchar(255) DEFAULT NULL, `detail` text, `view_count` int(11) NOT NULL DEFAULT 0, `deleted` tinyint(1) NOT NULL DEFAULT 0, `create_time` datetime NOT NULL, `update_time` datetime NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='房源表';

这里有一个踩过坑的细节：租金必须用DECIMAL(10,2)，绝对不能使用DOUBLE。原因是金额计算对精度极其敏感，用浮点数存钱，累计几个月后会出现0.01元的不可控误差。这在财务类业务里是红线。

3.3 租赁合同与账单表：联动设计

lease_contract表除了基本的双方用户ID和house_id之外，至少要包含：start_date、end_date、monthly_rent、deposit（押金）、contract_status、sign_time。合同状态可以设计为：待签署、履约中、已到期、已退租、已作废。

rent_bill表和lease_contract的关系是"账单跟随合同生成"。我在设计时让账单表存储了snapshot字段（账单生成时的租金快照），而不是每次计算都去合同表关联查金额。这样设计的好处是：即使未来合同金额变更，历史账单也不受影响。这就是一种"冗余一致性"思量，在写业务文档时可以专门说明。

CREATE TABLE `rent_bill` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `contract_id` bigint(20) NOT NULL, `house_id` bigint(20) NOT NULL, `tenant_id` bigint(20) NOT NULL, `bill_month` varchar(7) NOT NULL COMMENT '账单月份，如2025-06', `amount` decimal(10,2) NOT NULL, `status` tinyint(4) NOT NULL DEFAULT 0 COMMENT '0未支付 1已支付 2已退款', `pay_time` datetime DEFAULT NULL, `payment_order_no` varchar(64) DEFAULT NULL COMMENT '支付单号（预留）', `create_time` datetime NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='租金账单表';

3.4 关于冗余字段与数据同步的取舍

新手容易犯的错是"一张表存Everything"，比如在appointment预约表里把房主的手机号和租客的手机号都冗余了。我的建议是：缓存性冗余可以，业务性冗余要克制。比如预约表只存user_id和house_id，展示时通过关联查询拿到姓名电话，这种实时联表查询在以单机MySQL为主的系统中完全够用。反过来，如果每次显示合同列表都要连查五张表，那就该考虑在合同表冗余一个"房屋标题"这样的展示字段。

4. 业务逻辑的核心难点：房源状态与租赁合同的状态机设计

4.1 为什么一个"增删改查"的系统还需要状态机

如果房源表只有"已上架/已下架"两种状态，那确实用不着状态机。但真实的租赁业务不是这样的：房源从发布到最终出租，至少要经历"待审核 → 已上架 → 已预订 → 已出租 → 已退租"，每一步都有前置条件和操作者权限。更麻烦的是，这些状态之间不能随意跳转——你不能让一个"待审核"的房源直接变成"已出租"，也不能让一个"已出租"的房间被下架。

在代码层面，如果不做状态校验，仅靠Controller里if-else判断，很快会出现组合爆炸：状态有六种，操作有十几种，判断逻辑会被拆得七零八落。状态机就能把这种复杂校验收敛到一处。

4.2 状态节点和流转条件定义

我定义了这样一张状态流转控制表：

有了这张表，写Service的时候就变成了"查当前状态 -> 校验操作是否允许 -> 变更状态 -> 记录操作日志"，逻辑非常清爽。

4.3 代码实现：状态枚举和流程服务类

状态枚举中用普通Java枚举即可，但要注意把"允许迁移到哪些状态"也封装进去，形成一个自解释的规则集合：

public enum HouseStatus { PENDING_AUDIT(0, "待审核"), ON_SALE(1, "已上架"), RESERVED(2, "已预订"), RENTED(3, "已出租"), OFF_SHELF(4, "已下架"), REJECTED(5, "审核驳回"); private final int code; private final String desc; // 构造函数与getter省略 }

核心的状态检查方法放在HouseService里：

public void rentHouse(Long houseId, Long tenantId) { House house = houseMapper.selectById(houseId); // 状态机校验 if (house.getStatus() != HouseStatus.ON_SALE.getCode()) { throw new BizException("当前房源状态不允许发起租赁申请"); } // 并发控制：乐观锁版本号 int rows = houseMapper.updateStatusWithVersion(houseId, HouseStatus.ON_SALE.getCode(), HouseStatus.RESERVED.getCode(), house.getVersion()); if (rows == 0) { throw new BizException("房源已被其他租客预订，请刷新后重试"); } }

4.4 并发下的"两租一房"问题

上面代码里那个updateStatusWithVersion很重要。假如两个租客同时看到同一套"已上架"房源并发起租赁，如果不加限制，两个都会读到ON_SALE状态，然后都更新成RESERVED，结果就是一套房被两个订单占用。

我在实现时用了两种方式兜底：一是对(house_id, status)做一个条件更新的乐观锁；二是给house表加一个version字段，在关键状态流转时校验版本号。这里的要求是宁可让一个租客看到"手慢了，房源已被预订"，也不能让两个订单同时成功。

合同签订的逻辑与之类似。我设计合同状态为：初始创建（0）→ 房主确认（1）→ 租客确认（2）→ 生效（3）。任何一方没确认，合同都不算生效。每次确认都是一个原子更新操作，防止双方同时提交导致状态错误。

5. 权限模型设计：三种角色混用一套登录体系的正确姿势

5.1 用RBAC还是简单靠"角色字段判断"

最简单粗暴的做法是：用户表加一个role字段，然后Controller里判断"if(role==2)"决定能不能调这个接口。如果项目只有两三个角色、每个角色几十个接口，这个做法勉强能跑。但只要你加一个"运营专员"角色，或者要给管理员细分权限（比如只能审核房源、不能删用户），这套方案就崩了。

我采用的是轻量级RBAC模型：user、role、user_role（用户-角色关联表）、permission（权限点表）、role_permission（角色-权限关联表）。不过，坦白讲，对于毕设体量，"角色表三件套"完全够用，再多就会显得过度设计。

具体实现上，我在Spring Security的过滤器链中把每次请求的用户身份解析为LoginUser对象，并把它放入SecurityContext。每个需要权限的接口只检查一个自定义注解，比如@RequireRole(role = RoleConstants.ADMIN)。

5.2 Spring Security + JWT 的整合要点

我选择的登录方案是：用户输入账号密码 → 校验通过后生成JWT Token → 前端后续请求在Authorization Header携带Token → 后端过滤器解析Token并设置认证信息。

JWT工具类中关键的是 payload 部分应该放什么。我放了userId、username、role、expireTime。注意不要把密码、手机号这种敏感信息放进去，因为JWT的payload只是Base64编码，任何人拿到Token都能轻易解码看到这些字段。

public class JwtUtils { // 生成token public static String generateToken(LoginUser user) { return Jwts.builder() .setSubject(user.getUserId().toString()) .claim("username", user.getUsername()) .claim("role", user.getRole()) .setExpiration(new Date(System.currentTimeMillis() + 24*3600*1000L)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); } }

过滤器里的逻辑要处理好"token过期"和"token非法"两种情况，统一返回401和自定义错误码，不要让前端只能看到一个白屏。

5.3 权限注解与拦截器

自定义注解：

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RequireRole { int[] value(); }

在AOP切面里实现校验：

@Aspect @Component public class RoleAspect { @Before("@annotation(requireRole)") public void check(JoinPoint point, RequireRole requireRole) { LoginUser loginUser = SecurityUtils.getLoginUser(); boolean pass = false; for (int role : requireRole.value()) { if (loginUser.getRole() == role) { pass = true; break; } } if (!pass) { throw new BizException(403, "权限不足"); } } }

这样Controller里只需要一行注解：@RequireRole({RoleConstants.OWNER, RoleConstants.ADMIN})，可读性极高，答辩时也容易讲。

5.4 数据权限：房主只能动自己的房源

角色权限之外，还有一层"数据权限"问题：房主A不能删除房主B的房源。这一层的实现我放在了Service层，每次根据house_id先查owner_id，再和当前登录用户比对。有人建议在SQL里直接加and owner_id = ?，我认为对于毕设来说更建议先查后改。虽然多一次查询，但因为业务简单、数据量不大，安全性反而更高，不容易出现"SQL注入拼接错误"的问题。

6. 实测阶段的坑：联调时被这四个"小问题"卡了整整一周

6.1 跨域问题：前后端分离的第一个拦路虎

Vue跑在8080端口，SpringBoot跑在8081端口，浏览器直接拒绝请求，报CORS错误。这个坑几乎人人都会踩。我用了SpringBoot的全局跨域配置解决：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

注意：allowCredentials(true)和allowedOriginPatterns("*")必须配合使用，如果写成allowedOrigins("*")，Chrome会直接报错。

6.2 BigDecimal的序列化精度丢失

租金用了BigDecimal，正常情况下存到数据库没问题。但前端拿到的JSON中出现了100.00，前端传回给后端时，如果用到JavaScript处理浮点，某些情况下会出现精度丢失。解决办法是在返回实体时统一格式化为字符串。我通过全局Jackson配置解决了这类问题。

6.3 时间格式不一致导致"前端显示0点"

数据库里存的是2025-06-15 14:30:00，后端返回的是2025-06-15T14:30:00这种带T的ISO格式，前端显示一下，日期就多了个T，很难看。在application.yml中加入时间格式统一配置即可：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

这个坑虽然小，但是不配置的话，整站所有时间字段都会有问题。

6.4 MyBatis-Plus联合查询的N+1问题

列表页需要显示house.region_name、house.owner_name这类关联字段，新手最容易的做法是循环里逐条查询。当房源数量达到200条时，接口响应可能会慢到3秒。

我的做法是：列表只从主表查，然后用stream收集所有regionId到集合里，一次性查出区域字典，再在内存中做映射。这样数据库查询次数从N+1降成了2次。千万不要小看这个问题，答辩演示时数据少可能没问题，但被问到"数据量大的时候呢"就危险了。

6.5 逻辑删除与唯一索引冲突

这个坑比较隐蔽。我user表里设置了username唯一索引，用户删除后，逻辑删除只是把deleted字段设为1，记录还在表里，再来一个同名用户注册时直接撞了唯一索引。解决办法是：把唯一索引从username改为(username, deleted)，或者注册时先检查是否有未删除的同名用户。我用的是前者，但因为MySQL的唯一索引中NULL值可以重复，因此可以把deleted字段的默认值设为NULL，已删除的记录设为1，这样就能绕开冲突。

7. 如果让我把这个项目再往前推一步：三个性价比很高的扩展方向

7.1 搜索与筛选的体验优化

目前的房源列表搜索是用MySQL的LIKE实现的，字段一多、数据一大就会慢。最轻量的升级方案是用Redis做搜索缓存，或者引入Elasticsearch做全文检索。但个人建议，如果不是答辩硬性要求，做业务层面的"筛选器"更好：区域、户型、价格区间、朝向、面积做成多维度组合筛选，标签式筛选的体验感和技术含量反而更容易在答辩时讲清楚。

7.2 定时任务：租赁到期与账单自动生成

合同到期前7天，每天凌晨自动检查一次合同列表，生成"即将退租提醒"；每月1号自动为履约中的合同生成当月租金账单。这个需求用SpringBoot自带的@Scheduled注解就能实现。

@Component public class RentBillScheduler { @Scheduled(cron = "0 0 2 * * ?") // 每天凌晨2点执行 public void generateMonthlyBills() { // 查询所有履约中的合同，为每个合同创建当月账单 } }

定时任务虽然简单，却能把系统从"手动管理"推向"自动运营"，这个视角在答辩时很加分。

7.3 消息通知服务

预约成功、审核通过、租约到期，这些关键节点都应该给用户发通知。轻量的做法是写一个通知记录表，在业务操作位置调用通知Service插入记录，租客端做一个"消息中心"的列表页。如果要做主动触达，可以接邮件或者短信服务，但考虑到成本，毕设阶段做站内信即可。

我在实际操作中的体会是：做完上述这些，这套房屋租赁系统的代码量已经不小了，但它依然能保持清晰的模块边界。你完全不用把它当成一个"课程作业"，而是可以当成一个真实产品来迭代。每次状态机出问题、每次并发量预估，都是真正在逼自己思考业务背后的逻辑。如果你也正在做类似的SpringBoot管理系统，我建议你从业务链路拆解开始，优先搞定状态机和权限模型，再把页面填上——顺序对了，整个项目的产出质量会完全不一样。