SpringBoot前后端分离租房管理系统：三端协同与状态流设计实践

简介：基于SpringBoot的智能租房全流程管理系统，面向需要快速搭建房屋租赁平台的开发者、高校毕业设计或中小型项目实践者。资源集成管理端、屋主端、租客端三端协同，覆盖房源上下架、订单处理、预约看房、评价反馈、通知公告等核心业务，并采用前后端分离架构，便于二次开发与部署。压缩包共816个文件，以Java源码、Vue/HTML前端、JavaScript逻辑、CSS样式为主，另含SQL脚本、配置文件和说明文档，整体约26.43MB，结构清晰，适合按模块学习。已有45人学习下载。配套内容包含完整的项目工程、前端页面、静态资源与构建脚本，可根据文件目录快速定位后端接口、前端组件与数据库设计，有助于理解权限控制、多租户支持及数据安全等进阶实现，是一套实用的全流程系统参考方案。

1. 基于SpringBoot的智能租房全流程管理系统到底在解决什么

很多租房项目立项时都低估了一件事：房源、订单、预约、评价、公告这些功能单个拆开都不难，难的是让管理端、屋主端、租客端三套界面同时操作同一批数据，还要保证流程不乱。比如屋主维护了一条房源，管理端审核通过后租客才能看到；租客提交预约看房，屋主确认时间后订单自动进入待签约；签约后租客才能评价，评价内容又要回写房源评分，同时推送通知给管理端。这套链路只要中间断一环，前后端分离的架构反而会变成排查问题的障碍。

这个基于SpringBoot的智能租房全流程管理系统，核心价值是把“房源信息管理 + 订单处理 + 预约看房 + 评价反馈 + 通知公告”串成一个带状态约束的全流程闭环，而不是做成五个孤立模块。适合三种人读：一是用SpringBoot做Java毕设或个人项目、需要一套完整业务线撑起代码量的开发者；二是刚接手前后端分离租房类项目、想搞清权限与状态流转怎么设计的初级工程师；三是团队里要把这套流程从单体改造成微服务前、先讨论数据边界的技术负责人。

2. 前后端分离架构与三端协同的模型设计（管理端/屋主端/租客端）

2.1 为什么要用前后端分离，而不是传统的Thymeleaf模板渲染

传统SpringBoot + Thymeleaf的做法不是不能做租房系统，但一旦出现管理端、屋主端、租客端三套界面，模板渲染的劣势就很明显：每个角色一套页面意味着Controller里要写大量视图跳转逻辑，改一个按钮要重启整个后端。前后端分离后，SpringBoot只负责输出JSON，前端用Vue或React按角色拆路由，接口可以按权限粒度复用。

从工程角度看，前后端分离还解决了三端协同开发时的并行问题：前端团队拿到Swagger或YApi接口文档就可以开工，后端只管把API契约稳定下来。租房系统里典型的三端接口分配如下表所示，开发时可以按这个分工建包结构，避免每个人都去改同一个Controller。

这里有一个容易踩的坑：不要把所有业务都塞在/api/**下只靠注解区分角色，因为前端路由守卫和后端接口鉴权需要镜像对应。前端根据登录角色生成动态路由，后端根据JWT中的Role拦截请求，两边的规则一旦不一致，就会出现“按钮能看到但接口403”或者“接口能通但页面没入口”的怪问题。我一般的做法是让前端路由的meta字段和后端方法上的@PreAuthorize保持同一套角色字符串，代码评审时重点核对这个映射。

2.2 数据库模型设计：把三端操作落到同一份状态字段上

设计表结构时最忌讳每个端各建一套表。租客预约看房、屋主确认、管理端查看记录，本质上操作的应该是同一张预约表，只是过滤条件和更新字段不同。建议核心表拆成这几张：house（房源）、house_appointment（预约看房）、rent_order（订单）、house_evaluation（评价）、notice（公告），外加sys_user做统一账户表。

下面给出房源表与订单表的关键字段设计，其余表可以参照这个风格扩展：

CREATE TABLE house ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '房源ID', owner_id BIGINT NOT NULL COMMENT '屋主用户ID', title VARCHAR(100) NOT NULL COMMENT '房源标题', address VARCHAR(255) NOT NULL COMMENT '详细地址', price DECIMAL(10, 2) NOT NULL COMMENT '月租金', area DECIMAL(8, 2) COMMENT '面积平米', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待审核 1已上架 2已下架 3已拒绝', audit_remark VARCHAR(255) COMMENT '审核意见', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); CREATE TABLE rent_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(64) UNIQUE NOT NULL COMMENT '订单编号，前端展示用', house_id BIGINT NOT NULL, tenant_id BIGINT NOT NULL, owner_id BIGINT NOT NULL COMMENT '冗余屋主ID，省一次JOIN', amount DECIMAL(10, 2) NOT NULL COMMENT '成交金额', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待签约 1已签约 2已退租 3已取消 4已拒绝', sign_time DATETIME COMMENT '签约时间', check_in_time DATE COMMENT '入住日期', check_out_time DATE COMMENT '退租日期', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

设计这套状态字段时有三个点要特别说明。第一，owner_id在rent_order里的冗余不是多余设计，三端协同场景里租客查看订单列表要显示屋主昵称，屋主端要看自己名下所有订单，冗余字段能直接过滤数据而不必多次关联house表。第二，status不要用字符串，用TINYINT加注释，避免前端传过来“已签约”和“签约成功”这种无法统一的脏数据。第三，所有状态变更必须走后端服务方法而不是前端直接UPDATE，原因在下一章展开。

2.3 角色与权限模型：三种角色共用一张用户表

推荐用sys_user+user_role的方案。sys_user存登录名（手机号或邮箱）、密码密文、昵称、头像；user_role存user_id和role_code。这样设计的好处是将来一个用户同时是屋主又是租客时，只需往user_role多加一条记录。

用SpringBoot实现时，基于UserDetailsService重写loadUserByUsername，登录成功后生成带角色信息的JWT。权限校验用方法级别的@PreAuthorize("hasRole('OWNER')")比在Controller里手动判断request.getHeader("role")更安全。前端部分，Vue Router的全局前置守卫里读取本地存储的角色字段，每次路由跳转时比对meta.roles数组。

// router/index.js 前端三端路由守卫伪代码 router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') const roles = JSON.parse(localStorage.getItem('roles') || '[]') if (to.path === '/login') { next() return } if (!token) { next('/login') return } if (to.meta.roles && !to.meta.roles.some(r => roles.includes(r))) { next('/403') return } next() })

这段代码的关键在于meta.roles的定义：管理端路由写meta: { roles: ['ADMIN'] }，屋主端路由写meta: { roles: ['OWNER'] }，租客端写meta: { roles: ['TENANT'] }。如果某个页面三种角色都能访问，就不要写roles字段，让它默认放行，然后由后端接口的精确校验兜底。

3. SpringBoot核心功能落地：房源、订单、预约、评价、公告

3.1 房源信息管理：状态机驱动审核与上下架流程

房源模块是整个系统里逻辑最直白但坑最多的地方。核心思路是：房源不能直接从“已上架”变成“已下架”，中间要经过操作者的角色判断。比如屋主主动下架是允许的，但管理端驳回后屋主修改重新提交，状态必须从3已拒绝回到0待审核，不能直接跳回1已上架。

实现上建议建一个HouseStatusChangeService专门负责状态迁移，所有Controller都通过它来改状态：

@Service public class HouseStatusService { @Resource private HouseMapper houseMapper; @Transactional public void submitAudit(Long houseId, Long operatorId, String operatorRole) { House house = houseMapper.selectById(houseId); if (!house.getOwnerId().equals(operatorId) && !"ADMIN".equals(operatorRole)) { throw new BizException("无权操作该房源"); } // 待审核或已拒绝状态下才能提交审核 if (house.getStatus() != 0 && house.getStatus() != 3) { throw new BizException("当前状态不可提交审核"); } House update = new House(); update.setId(houseId); update.setStatus(0); update.setAuditRemark(null); houseMapper.updateById(update); } }

这段代码把改状态时最常见的两个问题一并挡住了：垂直越权（普通租客拿houseId就能改别人房源）和状态非法跳转。@Transactional保证多表更新时不产生半截数据。后面的订单、预约模块也使用同样的模式，所以建议把BizException统一封装成全局异常处理器，返回给前端的格式固定为{code, message, data}。

房源列表查询要注意一个隐藏坑：租客搜索时状态条件必须是status=1（已上架），但管理端和屋主端要能看到status=0待审核。千万不要在House实体上写一个getStatus()返回脱敏值，而是查询接口按角色拼接条件，否则管理端会误以为租赁业务不活跃。数据量大时，房源列表配合参数current和size做分页，返回体里带上total给前端分页组件使用。

3.2 订单处理与签约：状态机加幂等控制

订单模块是租房系统的核心，因为预约看房、评价、支付（如果有）都围着订单转。订单状态设计成五个：0待签约、1已签约、2已退租、3已取消、4已拒绝。注意这里没有“待支付”状态，多数校园或毕设级租房系统不接真实支付，所以签约动作直接是屋主或管理端操作“确认”。

设计订单状态机时，我建议把每个转换关系写进一张枚举表，而不是散落在if/else里，方便后续维护和排查。如下表所示，状态转换必须无歧义。

订单处理的另一个重点是幂等。前端按钮防连点只是体验层面的优化，后端的幂等控制必须落在数据库。最稳妥的方案是在rent_order表加unique_key字段，由前端创建订单时生成UUID传入，后端插入时命中唯一索引则直接返回“订单已存在”，而不是报错。创建订单的Service可以用一张下单记录表做前置检查，也可以依赖数据库唯一约束做兜底。

@Transactional public RentOrder createOrder(Long houseId, Long tenantId, BigDecimal amount, String uniqueKey) { // 幂等检查：同一租客对同一房源只能有一个待签约订单 LambdaQueryWrapper<RentOrder> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(RentOrder::getTenantId, tenantId) .eq(RentOrder::getHouseId, houseId) .eq(RentOrder::getStatus, 0); Long exists = rentOrderMapper.selectCount(wrapper); if (exists > 0) { throw new BizException("您已有该房源的待签约订单，请勿重复提交"); } // 业务校验：房子必须是上架状态 House house = houseMapper.selectById(houseId); if (house == null || house.getStatus() != 1) { throw new BizException("房源已下架或不存在"); } RentOrder order = new RentOrder(); order.setOrderNo(generateOrderNo()); order.setHouseId(houseId); order.setTenantId(tenantId); order.setOwnerId(house.getOwnerId()); order.setAmount(amount); order.setStatus(0); order.setUniqueKey(uniqueKey); rentOrderMapper.insert(order); return order; }

这里的参数uniqueKey建议后端生成订单号的同时由前端本地生成并携带，不要在后端重新生成，否则前端多次重试时每次都是新值，幂等就失效了。业务上还要避免“租客给同一个房源下单两个待签约订单”的情况，所以增加了上面的组合条件查询。

3.3 预约看房+评价反馈+通知公告的闭环实现

预约看房是整个系统里最容易被人忽略的一块。常见的需求是租客选择时间段（比如“明天上午10点到11点”），屋主在屋主端确认后租客才能到访。实现时建议house_appointment表里加三个字段：expected_time（期望时间段）、appointment_time（确认后的具体时间）、status（0待确认、1已确认、2已取消、3已完成）。

屋主确认后，系统要“顺便”做事：给租客发通知公告，写入notice表的同时标记已读状态。这里适合用SpringBoot的@Async异步发布事件，避免租客创建预约时因为发通知慢导致接口超时。常见做法是定义一个AppointmentConfirmedEvent，监听器里写推送逻辑。

@Component public class AppointmentEventListener { @Async @EventListener public void onAppointmentConfirmed(AppointmentConfirmedEvent event) { Notice notice = new Notice(); notice.setUserId(event.getTenantId()); notice.setTitle("看房预约已确认"); notice.setContent("您预约的房源【" + event.getHouseTitle() + "】已确认，时间：" + event.getAppointmentTime()); notice.setStatus(0); noticeMapper.insert(notice); // 此处可以扩展接入短信或邮件推送 } }

评价反馈的坑在于数据关联关系。租客只能评价“已签约过且未退租”的订单，评价内容必须实时更新房源的平均评分。实现时不要每次查平均分都SELECT AVG(score) FROM evaluation WHERE house_id = ?，性能在小规模业务里不是大问题，但一致性问题更重要。建议house表冗余一个avg_score字段，评价新增或删除时用@Transactional同步更新该字段。

公告模块相对独立，但要注意区分“站内信”和“系统公告”。系统公告是全体可见，站内信是个人维度的，在notice表里用target_type区分：0全员、1租客、2屋主、3管理端。租客登录后查target_type=0 OR (target_type=1 AND user_id=当前用户)，配合read_status做已读未读标记。

4. Vue前端Token处理与三端路由复用、跨域联调

4.1 SpringBoot后端Token签发与统一鉴权

前后端分离后，登录状态一般用JWT而不是Session。SpringBoot端先用Spring Security + JWT或者简单的拦截器实现，后者更适合学习型项目。用拦截器时，核心代码是重写HandlerInterceptor的preHandle方法，把解析JWT和提取用户信息放到这里，而不是在每个Controller里重复写。

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { throw new BizException(401, "未登录"); } try { Claims claims = Jwts.parser() .setSigningKey(secretKey) .parseClaimsJws(token.substring(7)) .getBody(); request.setAttribute("userId", claims.get("userId", Integer.class)); request.setAttribute("role", claims.get("role", String.class)); } catch (ExpiredJwtException e) { throw new BizException(401, "登录已过期"); } catch (JwtException e) { throw new BizException(401, "无效的Token"); } return true; } }

拦截器为什么要用Bearer前缀？这是前后端分离项目的事实标准，Vue端的axios拦截器设置请求头时使用Authorization: Bearer ${token}，后端按这个规则截取token。注意Jwts.parser()在不同版本的jjwt库里写法有差异，0.11.x以上推荐用Jwts.parserBuilder().setSigningKey(key).build()，否则启动后会报算法不匹配的错。

还要给拦截器一个白名单。登录接口、注册接口、房源搜索列表这些租客未登录也能访问的路径必须放行。放行配置写在实现WebMvcConfigurer的配置类里，常见的正则写法是antMatchers("/api/auth/**", "/api/house/list").permitAll()，初学者容易漏掉首页轮播图对应的房源接口，导致租客打开首页时请求401。

4.2 Axios拦截器：请求携带Token与401统一处理

Vue端的关键文件是src/utils/request.js，项目中所有HTTP请求都通过这个封装的axios实例发出。请求拦截器负责在每次请求头里注入Token，响应拦截器统一处理业务错误码和HTTP状态码。

import axios from 'axios' import { ElMessage } from 'element-plus' import router from '@/router' const service = axios.create({ baseURL: '/api', timeout: 15000 }) service.interceptors.request.use( (config) => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }, (error) => Promise.reject(error) ) service.interceptors.response.use( (response) => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message || '请求失败') if (res.code === 401) { localStorage.removeItem('token') router.push('/login') } return Promise.reject(new Error(res.message)) } return res }, (error) => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } ElMessage.error('网络异常，请稍后重试') return Promise.reject(error) } ) export default service

后端业务异常统一抛出BizException时，由全局异常处理器返回HTTP 200 + code字段，还是HTTP 401？这里建议“HTTP状态码只管HTTP层的语义，业务错误码交给code字段”。拦截器里对401的处理必须同时覆盖两种情况：响应拦截器里res.code === 401和后端返回HTTP 401。token失效时，前端要把本地用户信息一并清空，否则会出现“路由跳回了登录页但右上角还显示用户名”的脏状态。

4.3 三端工程复用与跨域CORS配置

管理端、屋主端、租客端如果拆成三个Vue项目，维护成本会翻三倍：改一个公共按钮要同步三个仓库。务实做法是拆成三个子目录但共用同一套组件库和封装好的request工具，路由按模块拆文件夹，打包时用不同的.env.xxx文件区分后端地址。Vue Router的createWebHistory在管理端部署时要配Nginx的try_files，否则刷新页面直接404。

后端跨域配置用CorsFilter最省事，网上很多教程写的是allowedOrigins("*")加allowCredentials(true)的组合，这在SpringBoot 2.4以上会启动报错，因为*不能和携带凭证同时使用。正确写法是用allowedOriginPatterns("*")：

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.setAllowCredentials(true); config.addAllowedOriginPattern("*"); config.addAllowedHeader("*"); config.addAllowedMethod("*"); config.setMaxAge(3600L); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

addAllowedOriginPattern("*")允许携带Cookie跨域，适合联调阶段。生产环境一定要把*改成具体的前端域名列表，比如http://admin.rental.com、http://owner.rental.com，避免任何人从任意来源请求你的后端接口。另外注意，加了拦截器后跨域预检请求OPTIONS会被拦截器拦下来返回401，所以preHandle方法里要放行HttpMethod.OPTIONS。

5. 上线前必做的优化与安全检查（定时任务、敏感信息、缓存穿透）

5.1 预约超时未确认的兜底：SpringBoot定时任务

预约看房有一个需求很容易漏：租客提交预约后，如果屋主一直不确认，状态就一直卡在“待确认”，租客也不知道该不该去。常见做法是提供一个“超时自动取消”功能，这也正好发挥SpringBoot定时任务的作用。

用@Scheduled注解实现每天零点扫描或者每十分钟扫描一次待确认且超时的预约。关键点有两个：一是任务方法上要处理分布式部署的幂等，二是不要一次把全表数据捞出来改，而要用分页处理。

@Component public class AppointmentTimeoutTask { @Resource private AppointmentMapper appointmentMapper; @Scheduled(cron = "0 */10 * * * ?") public void cancelTimeoutAppointments() { // 只处理超过24小时未确认的预约 LocalDateTime deadline = LocalDateTime.now().minusHours(24); LambdaQueryWrapper<HouseAppointment> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(HouseAppointment::getStatus, 0) .lt(HouseAppointment::getCreateTime, deadline) .last("LIMIT 200"); List<HouseAppointment> list = appointmentMapper.selectList(wrapper); for (HouseAppointment appt : list) { appt.setStatus(2); appointmentMapper.updateById(appt); } // 此处可通过事件发布通知租客，预约已超时取消 } }

cron表达式“0 */10 * * * ?”表示每10分钟执行一次。LIMIT 200是防止一次性更新太多导致主从延迟，业务量大的时候可以循环处理直到没有更多数据。不要在这个定时任务里加@Transactional到整个for循环上，应该每次更新一个预约单独事务，避免一条失败导致前面的回滚。部署时还要注意@EnableScheduling不要漏掉，它在启动类或配置类上开启定时任务能力。

5.2 HeapDump泄露与敏感信息脱敏

SpringBoot项目上线前最容易忽略的是健康检查和敏感信息暴露。近年SpringBoot爆出的HeapDump敏感信息泄露漏洞，核心问题不是框架本身，而是Actuator的heapdump端点如果在生产环境开放，任何人访问/actuator/heapdump都能下载到JVM堆转储文件，里面包含数据库密码、Redis密码、业务数据等一切在内存里的敏感信息。规避方法很直接：生产环境关闭所有非health的端点。

# 生产环境application-prod.properties management.endpoints.web.exposure.include=health management.endpoint.health.show-details=never

配置show-details=never是为了防止/actuator/health泄露数据库连接状态等细节。安全管理上还要配合密码加密，spring.datasource.password和spring.redis.password不要明文写在配置文件里，使用Jasypt加密或环境变量注入。

另外，房源地址、屋主手机号这类字段在接口返回时要脱敏。租客端查询房源列表时，地址不应返回完整门牌号，通常把小区名字保留、楼栋和门牌号替换成“***”。实现脱敏不要在SQL里做，建议在序列化层面用Jackson注解：

public class HouseVO { private String title; @JsonSerialize(using = AddressMaskSerializer.class) private String address; }

自定义AddressMaskSerializer继承JsonSerializer<String>，在serialize方法里写脱敏规则，这样业务代码无感知，屋主端和管理端的VO类不加注解就能看到完整地址。

5.3 高频公告与房源列表的缓存穿透处理

公告和热门房源列表是整个系统里读多写少的部分。每次租客打开小程序或移动端首页都请求一次公告接口，Redis缓存就很有必要。查询顺序是“先查Redis，再查数据库，回填缓存”。租房系统的公告数量不多，写入后变更频率极低，所以缓存时间可以设置长一些，比如12小时。缓存Key设计要注意带上目标角色，例如notice:tenant和notice:owner，避免全员公告和租客公告混在一起。

缓存穿透的防护同样重要。如果有攻击者持续请求不存在的房源ID，Redis和数据库都查不到，请求会直接打到MySQL。解决方案是“缓存空值”和“布隆过滤器”二选一。房源列表场景用缓存空值更简单，实现如下：

public House getHouseById(Long houseId) { String cacheKey = "house:detail:" + houseId; Object cached = redisTemplate.opsForValue().get(cacheKey); if (cached != null) { return JSON.parseObject(cached.toString(), House.class); } House house = houseMapper.selectById(houseId); if (house != null) { redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(house), 1, TimeUnit.HOURS); } else { // 空值也缓存，防止穿透 redisTemplate.opsForValue().set(cacheKey, "", 5, TimeUnit.MINUTES); } return house; }

这里要强调，缓存空值时过期时间不要和正常缓存一样，否则大量不存在ID的请求还是会在同一时间点穿透到数据库。空值缓存5到10分钟足够。用Redis的setIfAbsent加分布式锁是更严谨的做法，建议去了解“缓存击穿”与“缓存穿透”两个概念的区别，前者是热点Key过期瞬间的并发请求全部打进数据库，后者是查询根本不存在的Key直接打到数据库。

5.4 SpringBoot版本选择与面试考察点

写这个系统前，你先定SpringBoot版本。SpringBoot 2.7.x是目前最稳妥的生产选择，一方面Spring Security、Redis、MyBatis-Plus的兼容文档最全，另一方面Java 8够用；SpringBoot 3.x强制要求JDK 17，如果你的电脑环境还是JDK 8，一台机器上切来切去很痛苦。搜springboot版本太高出现的坑大多数是SpringBoot 3.x + Spring Security 6配置方式大改，antMatchers变成了requestMatchers，照着老教程抄会卡很久。

面试或者简历里写这个项目时，有两个SpringBoot底层的点值得展开：@ConfigurationProperties绑定配置项的原理，以及@SpringBootApplication自动装配机制。前者对应你项目里的短信配置、OSS配置等自定义属性类，后者支撑你在面试时回答“为什么自己写的@Component能被SpringBoot扫描到”。把这两点配合“预约看房异步事件”“订单幂等控制”一起讲，面试官基本能认定你是真正把业务落到框架里的人，而不是只会按IDS_AST摸代码。

本文还有配套的精品资源，点击获取