最近刚带人做完一个 springboot 租房管理系统的毕业设计前后折腾了大概三周从选题、搭框架到跑通核心功能踩了不少坑也总结了不少能直接抄作业的经验。这个题目在计算机毕设里属于典型的中等难度 Java Web 项目既不会像纯 CRUD 那样显得工作量不够又不会像微服务那一套那样把自己逼疯。这个项目本质上是给房东、租客和管理员三方搭一个线上协作平台核心就是房源管理、合同管理、账单管理、租客信息维护这几条主线。从技术角度看SpringBoot 负责承载所有后端接口前端配合 Vue 或者 Thymeleaf 都行数据库用 MySQL权限控制用 JWT 或者 Session 方案整体架构清晰又不过度设计。无论你是准备拿它当毕设题目还是想自己练习 SpringBoot 项目开发这篇内容都能帮你在动手前把思路理顺。1. 项目全貌与核心需求拆解1.1 这个系统到底要解决什么问题做毕设最容易犯的毛病就是一上来就堆功能结果做了一堆没用的页面核心业务反而没跑通。租房管理系统的本质需求其实很朴素房东有房子要出租租客要找房子住中间涉及看房、签约、交租、退租这一连串流程传统方式全靠 Excel 和聊天记录去管理信息散乱且容易扯皮。从实际使用场景来看系统至少要覆盖这样几条业务线房源侧房源信息发布、上下架、租售状态变更基础信息包括小区、户型、面积、朝向、租金、押付方式等。租客侧租客信息建档身份证件、联系方式、紧急联系人以及历史租住记录。合同侧租房合同的创建、审核、到期提醒核心字段是起止日期、租金、押金、付款周期。财务侧租金账单生成、收款记录、押金管理以及逾期统计。系统侧用户登录注册、角色权限控制管理员对整体数据进行查看和统计。想明白这些业务场景之后功能边界就清晰了。毕设答辩时老师最爱问“为什么设计这个模块”能讲清楚它解决的是什么线下痛点就已经成功了一半。1.2 角色划分与权限设计思路这个系统我建议采用三角色模型管理员、房东、租客。不要一开始就想着搞复杂的 RBAC 权限模型对毕设来说基于角色的简单判断逻辑完全够用而且更容易讲明白。管理员拥有全部数据权限可以查看所有房源、合同、账单管理平台用户账号。房东维护自己的房源信息查看名下合同和收入账单跟进租客状态。租客查看可租房源发起租赁申请查看自己的合同与缴费记录。多个角色意味着登录后返回的菜单结构不同前端要根据角色标识动态渲染路由。后端接口层面可以通过拦截器校验登录状态再通过自定义注解或角色判断来控制接口访问权限。这里的小技巧是不要只在前端做按钮级隐藏后端接口必须做二次校验否则答辩时老师写个脚本直接调接口你的权限体系就等于摆设。1.3 功能优先级取舍策略毕设时间有限功能一定要分优先级。我给出的建议是核心链路优先加分功能量力而行。第一优先级是房源管理、用户登录注册、合同与账单管理。这是整个租房系统的骨架如果这几个模块没做完项目逻辑上就不成立。第二优先级是搜索筛选、到期提醒、数据统计。这些功能属于“看起来很专业”的部分工作量不小但技术含量适中做完以后系统完成度会明显上一个档次。第三优先级是消息通知、收藏功能、在线聊天。这部分我建议直接砍掉或者做成最简单的轮询版因为涉及 WebSocket 或更复杂的前端交互不是毕设的核心评分点花大量时间在上面性价比极低。我在实际划分时还加了个“低频但有亮点”的思路可以用 Redis 做缓存来加速房源列表的访问虽然毕设并发量根本用不上缓存但在设计说明里写一句“利用缓存降低数据库压力”就是妥妥的加分项。2. 技术选型与项目骨架搭建2.1 版本选型背后的坑很多人在毕设开头就卡在环境上核心原因是盲目选择新版本。SpringBoot 3.x 虽然出了很久但它基于 Spring Framework 6要求 JDK17 起步很多配套教程中间件还没完全跟上。我的建议就是老老实实用 SpringBoot 2.7.x JDK8这是生态最稳的组合网上资料一抓一大把遇到问题随便搜都能找到答案。配套选型方面ORM 层选 MyBatis-Plus 而不是原生 MyBatis因为它的条件构造器能省掉大量 XML 里的 if 判断对赶时间的毕设来说体验是质的提升。数据库连接池用 Druid监控页面可以直接访问写论文时还能截图展示“系统具有良好的可观测性”。权限控制用 JWT 拦截器无状态认证前后端分离场景下最好用而且源码量少答辩时容易解释。接口文档建议引入 Knife4j基于 Swagger 的增强版页面比原生 Swagger 好看很多生成接口文档后写论文的“系统设计”章节直接复制核心部分即可。这个选型组合看似普通但胜在每一项都在“够用”和“有深度”之间取得了平衡。避免选择一个过于小众的技术栈导致答辩时老师无从问起也避免全用最基础的工具导致项目毫无亮点。2.2 数据库设计要点数据库设计是整个项目的地基表结构一旦定下来后面写代码其实就是照表操作。租房系统核心表建议这么设计user用户表id、用户名、密码BCrypt 加密存储、真实姓名、手机号、角色标识0 管理员 / 1 房东 / 2 租客、创建时间。house房源表id、房东 id、标题、小区名、地址、户型几室几厅、面积、朝向、楼层、租金、押金方式、出租状态0 未出租 / 1 已出租、房屋描述、发布时间。tenant租客表id、用户 id、身份证号、紧急联系人、紧急联系电话、职业信息、备注。contract合同表id、合同编号、房源 id、租客 id、房东 id、起租日期、结束日期、租金、押金、付款周期月付 / 季付 / 年付、合同状态、签订时间。bill账单表id、合同 id、账单编号、费用类型租金 / 押金 / 水电费、金额、账期如 2025-01、缴费状态0 待缴 / 1 已缴 / 2 逾期、缴费时间。house_apply租赁申请id、房源 id、租客 id、申请状态待处理 / 通过 / 拒绝、申请时间。字段类型上有几个值得注意的点金额一律用DECIMAL(10,2)而不是DOUBLE避免浮点误差时间字段统一用datetime面积建议保留一位小数。主键直接bigint自增就好不需要为了炫技用雪花 ID那是给自己找麻烦。外键不要真的在数据库层面建逻辑外键就够了。一方面数据删除灵活另一方面避免 MySQL 在外键约束下做级联操作时的性能损耗。答辩时老师如果问为什么不用外键可以回答“在高并发写入场景下外键约束会带来额外的锁开销实际开发中常用应用层保证数据一致性”这个回答非常加分。2.3 项目目录结构与分层设计很多初学者喜欢把所有代码塞到 controller 里一个方法几百行看着热闹实则维护成本极高。SpringBoot 项目推荐用标准分层架构cn.xx.rent ├── config // 配置类跨域、拦截器、Knife4j ├── controller // 接口层接收参数并返回统一结果 ├── service // 业务层核心逻辑处理 │ └── impl ├── mapper // 数据访问层MyBatis-Plus 的 Mapper 接口 ├── entity // 数据库实体类 ├── dto // 传输对象接收前端参数 ├── vo // 视图对象返回给前端的数据 ├── common // 通用类统一返回结果、异常处理、常量 ├── utils // 工具类JWT 工具、日期工具 └── RentApplication.java有一个很关键的习惯要养成前端传参不要直接绑定entity而是定义dto接口返回值不要直接返回entity而是封装成vo。虽然在小项目里这看起来有点绕但它的好处很实在实体类字段有时候包含密码这类敏感数据直接返回前端就是隐患而且定义 VO 后你可以在里面额外添加“房东姓名”“房源图册”这类关联展示字段前端拿数据会非常舒服。在common包下定义统一的ResultT返回类包含code、message、data三个字段所有接口统一返回。前端拿到这种结构后处理逻辑完全一致不会为每个接口单独写一套解析方法。这块一定要在开工前搭好否则后面写一个接口写一套返回光统一格式就能耗掉半天。3. 核心功能实现与实操要点3.1 登录鉴权与权限控制实现细节登录逻辑看似简单但要做好需要处理几个细节密码不能明文存储登录态不能放在HttpSession里由后端维护因为前后端分离项目需要无状态认证。我用的方案是 JWTJSON Web Token。用户登录成功后后端生成一个 token 返回给前端前端存储在localStorage每次请求在请求头携带Authorization: Bearer token。后端写一个拦截器统一拦截需要认证的路径解析 token 成功后直接放行同时在request里设置用户 ID 供后续业务使用。生成 token 的核心代码如下public String generateToken(User user) { MapString, Object claims new HashMap(); claims.put(userId, user.getId()); claims.put(role, user.getRole()); return Jwts.builder() .setClaims(claims) .setSubject(user.getUsername()) .setExpiration(new Date(System.currentTimeMillis() 7L * 24 * 3600 * 1000)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }拦截器的关键点在于白名单路径必须放行比如/api/user/login、/api/user/register、/api/house/list因为未登录也要能浏览房源。不要拦截静态资源。调试时最容易出问题的是遗漏跨域配置前端请求带 token 时会出现预检请求后端必须正确响应OPTIONS请求否则前端会一直报跨域错误。密码加密直接使用BCryptPasswordEncoder这玩意儿的好处是每次加密结果都不一样数据库被脱库也无法反推出原始密码答辩时提到“采用了不可逆加密算法存储敏感信息”本身就是安全意识的表现。3.2 房源管理与多条件检索实现房源管理是整个系统最核心的模块录入、修改、上下架、列表展示每个环节都要考虑。我建议把房源列表做成支持多条件筛选的形式关键词搜索小区名 / 地址、租金范围、户型筛选、状态筛选。用 MyBatis-Plus 的条件构造器写这种动态查询非常舒服不需要写 XML 里的各种if标签LambdaQueryWrapperHouse wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.isNotBlank(keyword), House::getAddress, keyword) .ge(minRent ! null, House::getRent, minRent) .le(maxRent ! null, House::getRent, maxRent) .eq(type ! null, House::getType, type) .eq(status ! null, House::getStatus, status) .orderByDesc(House::getCreateTime);这里有个容易踩的坑条件构造器里链条式写法虽然简洁但要注意like查询的关键词必须提前做空值判断否则用户什么都没输入时会把整个表的数据全部查出来。别看这个错误低级实际开发中至少一半的查询副作用都是这种因素导致的。分页方面MyBatis-Plus 提供了Page对象配合分页插件使用PageHouse page new Page(pageNum, pageSize); PageHouse result houseMapper.selectPage(page, wrapper);前端传pageNum和pageSize后端返回total总记录数和records当前页数据。前端用 Element UI 的el-pagination组件可以直接对接。房源上下架相当于一个状态更新接口通过updateById修改状态字段即可。有一个小细节要注意房子处于“已出租”状态时下架后是否允许编辑我的做法是已出租房源锁定核心字段地址、户型、租金只允许修改描述信息这是为了模拟真实业务中合同存续期间的约束规则。3.3 合同管理与到期自动提醒合同管理是租房系统里最有业务深度的部分做好了整个项目的档次就上去了。合同的状态流转可以设定为待生效 → 生效中 → 已到期 → 已退租。合同创建时要做几件重要的事检查房源当前不是“已出租”状态避免一房多租。生成唯一的合同编号建议格式为HT 年月日 4位随机数。根据合同起止日期提前生成所有周期的账单记录。将房源状态更新为“已出租”把租客和房源进行绑定。账单生成的逻辑值得展开一下。如果付款周期是“月付”合同期限是 12 个月那就要在签合同的同时生成 12 条账单记录每条账单对应一个账期。这里写一个循环生成即可但要注意日期计算方式第一期的截止日期是起租日期加一个月第二期以此类推。这种“合同驱动账单”的设计思路在答辩时能展示你对业务闭环的理解。到期提醒可以用 SpringBoot 自带的Scheduled定时任务Scheduled(cron 0 0 8 * * ?) public void remindContractExpire() { // 查询三十天内即将到期的合同 // 给房东和租客发送通知 }定时任务虽然一行注解就能启用但有几个隐藏细节需要在测试时关注时间默认走服务器时区如果服务器在国外那每天 8 点执行的含义可能会跟预期不一样建议在配置文件里明确spring.jackson.time-zone: GMT8另外生产环境如果有多个实例部署同一时刻定时任务会执行多遍虽然毕设用不到但论文明里可以提一句“可以通过分布式锁保证单个实例执行”。3.4 账单统计与数据可视化前面把账单生成了这个模块就是把账单数据进一步加工让系统管理者能看到经营概况。我建议在后台管理页面放一组统计卡片和一张图表包括总房源数、已出租房源数、本月应收租金、本月实收租金、租客总数。实现方式用 MySQL 聚合函数配合 Java 8 Stream 都可以但聚合统计这类操作更适合直接让数据库算好返回Select(SELECT IFNULL(SUM(amount), 0) FROM bill WHERE status 1 AND bill_period #{month}) BigDecimal sumPaidAmount(String month);在 MyBatis 中直接写注解 SQL 处理这种简单统计比用 MyBatis-Plus 更直观因为条件构造器表达不了聚合函数。不过要注意SUM结果可能为null需要用IFNULL兜底否则 Java 这边接一个null做运算就直接空指针。图表展示部分前端使用 ECharts后端提供两个统计接口一个是租金趋势近六个月的应收实收折线图一个是房源户型分布饼图。前端拿到 JSON 数据后配置一下option就完事。这一块属于典型的面向前端展示型功能难度不大但视觉效果非常显著系统演示录屏的时候也是很好的素材。4. 常见问题排查与避坑实录4.1 前后端联调的 JSON 格式与跨域问题前后端分离开发时第一个拦路虎基本就是跨域。后端 SpringBoot 默认不允许跨域请求解决方式是写一个配置类Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedMethod(*); config.addAllowedHeader(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }这里有个跟 JWT 相关的隐藏坑当你携带 token 发起请求时浏览器会先发一个OPTIONS预检请求预检请求不会携带自定义请求头。如果拦截器拦截了所有请求并直接校验 token预检请求就会返回 401前端表现就是“明明接口能通为什么还是报跨域”。解决方式很简单在拦截器里先放行OPTIONS请求再继续校验逻辑。后端返回的日期类型默认序列化为yyyy-MM-dd HH:mm:ss格式还好但 LocalDate 类型默认不带时分秒前端解析时可能报错。建议在配置文件里统一指定spring.jackson.date-formatyyyy-MM-dd HH:mm:ss spring.jackson.time-zoneGMT84.2 Maven 依赖冲突与打包问题SpringBoot 项目最常见的打包报错是Skip Tests没开导致的构建失败以及主类找不到。排查思路如下确保maven-compiler-plugin编译版本设置为 JDK8 对应的 1.8否则你用的 JDK 版本不同会出现编译期方法签名错误。打包时建议执行mvn clean package -DskipTests跳过测试避免某些测试用例影响构建。依赖冲突集中在druid-spring-boot-starter和knife4j上有时会因为传递依赖引入旧版 Jackson 导致 JSON 序列化问题。遇到此类情况可以在pom.xml里排除传递依赖强制使用 SpringBoot 统一管理的版本。这里多说一句很多同学项目开发环境跑得好好的但打包部署到服务器就起不来大概率是编译版本问题。配置里的java.version必须和机器上的 JDK 匹配不然就是各种invalid target release报错。4.3 定时任务与数据一致性细节合同到期自动修改状态、账单逾期自动标记这些操作依赖定时任务但定时任务里的逻辑一定要考虑幂等性。如果数据重复处理就会出现租客已经退租了合同还在“生效中”这种尴尬情况。我的做法是在定时任务执行前先查询当前状态只有状态匹配的数据才更新ListContract expiringList contractMapper.selectList( new LambdaQueryWrapperContract() .eq(Contract::getStatus, 生效中) .lt(Contract::getEndDate, LocalDate.now().plusDays(30)) );同时数据库层面也加上状态筛选条件双重保障。这里有个非常值得讲的细节不要直接在定时任务里调用 service 的更新方法去“批量更新所有到期合同”而应该一条条查询、一条条更新这样即使中途失败只需要观察日志定位到具体哪一条数据出了问题。批量更新的异常日志往往不精确排错效率很低。并发部分还有一个隐蔽的问题用户在前端同时点“确认退租”和定时任务在后台跑“合同到期更新”可能导致同一条合同被重复更新。解决思路是在更新 SQL 里加状态条件比如UPDATE contract SET status 已退租 WHERE id ? AND status 生效中这样即使两个请求同时到达也只有其中一个能真正执行成功。4.4 数据脱敏与接口安全细节租房系统里面涉及租客身份证号、手机号等敏感信息。哪怕只是毕设也要有点安全意识。我的建议是后端接口中凡是返回身份证号、手机号这类信息都在 VO 层做脱敏处理展示时只保留前几位和后几位比如110***********1234。这不影响功能演示但论文里写“对个人敏感信息进行脱敏处理”就是一个区别于其他同学的安全意识加分项。另外管理员和房东登录后能看到的房源列表边界也要注意房东进入后台只能操作自己的房源和合同。所以房源列表查询时除了条件构造器还要额外加一个eq(House::getOwnerId, userId)的条件。这块是典型的越权漏洞来源很多初学毕设的人忽略了“数据范围权限”结果 A 房东能看到 B 房东的房子答辩现场被老师点出来会非常狼狈。5. 项目答辩与说明文档组织技巧5.1 演示流程的合理设计毕设答辩时系统演示一般只有 5 到 10 分钟很多同学一上来就从前端页面开始点结果时间全浪费在加载数据和切换菜单上。我的经验是演示要按“业务故事线”走不要按菜单顺序走。可以先演示管理员登录打开数据统计页面通过图表快速展示系统整体情况数据量大、信息全、系统是真实业务场景。然后切换到一个房东账号创建一个房源修改房源信息模拟租客注册并发起申请房东确认申请后生成合同。再打开账单页面展示合同生成的账单列表演示租客缴费功能。最后演示合同到期提醒和退租操作。你会发现这条线其实就是真实业务的完整闭环而“按菜单演示”只是在念系统功能清单没有故事感。5.2 文档编写的核心素材来源写说明文档最费时间的是画用例图、ER 图、流程图。手动绘制效率极低但通常建模工具可以直接从接口和数据表反向生成。有的工具比如某些 IntelliJ 插件能直接从数据库反向生成 ER 图这样出来的图又规范又好看。论文里这些图贴上以后整个文档的专业度会非常明显。技术架构选型部分直接把你最终确定的技术栈按“集成层、接口层、业务层、数据层”写清楚再把选择每一项技术的理由写一句。不要写“为了毕业设计方便”这种话要写“SpringBoot 简化了项目初始化和部署复杂度内嵌容器便于快速启动”“MyBatis-Plus 在满足灵活 SQL 编写能力的同时大幅提升了开发效率”。这些话就是老师想听的设计理由。写在后面的一点体会做完这个租房管理系统我最大的感受是毕设选题真的不用贪大。一个 SpringBoot 单体应用、七八张核心表、三到四个角色只要把业务闭环跑通把两三个技术细节做出深度就已经是相当扎实的毕业设计了。我见过很多同学一年前就开始准备最后却因为反复重构和追求完美导致连基本功能都没做完这是最可惜的结果。如果你正在做类似的系统我的建议是把核心链路先跑通把登录、房源、合同、账单这几条线先理顺再去优化细节和界面。等项目能整体运行起来那种踏实感会帮你把剩下的事情一股气做完。祝你的毕设顺利过关。 最近刚带人做完一个 springboot 租房管理系统的毕业设计前后折腾了大概三周从选题、搭框架到跑通核心功能踩了不少坑也总结了不少能直接抄作业的经验。这个题目在计算机毕设里属于典型的中等难度 Java Web 项目既不会像纯 CRUD 那样显得工作量不够又不会像微服务那一套那样把自己逼疯。这个项目本质上是给房东、租客和管理员三方搭一个线上协作平台核心就是房源管理、合同管理、账单管理、租客信息维护这几条主线。从技术角度看SpringBoot 负责承载所有后端接口前端配合 Vue 或者 Thymeleaf 都行数据库用 MySQL权限控制用 JWT 或者 Session 方案整体架构清晰又不过度设计。无论你是准备拿它当毕设题目还是想自己练习 SpringBoot 项目开发这篇内容都能帮你在动手前把思路理顺。1. 项目全貌与核心需求拆解1.1 这个系统到底要解决什么问题做毕设最容易犯的毛病就是一上来就堆功能结果做了一堆没用的页面核心业务反而没跑通。租房管理系统的本质需求其实很朴素房东有房子要出租租客要找房子住中间涉及看房、签约、交租、退租这一连串流程传统方式全靠 Excel 和聊天记录去管理信息散乱且容易扯皮。从实际使用场景来看系统至少要覆盖这样几条业务线房源侧房源信息发布、上下架、租售状态变更基础信息包括小区、户型、面积、朝向、租金、押付方式等。租客侧租客信息建档身份证件、联系方式、紧急联系人以及历史租住记录。合同侧租房合同的创建、审核、到期提醒核心字段是起止日期、租金、押金、付款周期。财务侧租金账单生成、收款记录、押金管理以及逾期统计。系统侧用户登录注册、角色权限控制管理员对整体数据进行查看和统计。想明白这些业务场景之后功能边界就清晰了。毕设答辩时老师最爱问“为什么设计这个模块”能讲清楚它解决的是什么线下痛点就已经成功了一半。1.2 角色划分与权限设计思路这个系统我建议采用三角色模型管理员、房东、租客。不要一开始就想着搞复杂的 RBAC 权限模型对毕设来说基于角色的简单判断逻辑完全够用而且更容易讲明白。管理员拥有全部数据权限可以查看所有房源、合同、账单管理平台用户账号。房东维护自己的房源信息查看名下合同和收入账单跟进租客状态。租客查看可租房源发起租赁申请查看自己的合同与缴费记录。多个角色意味着登录后返回的菜单结构不同前端要根据角色标识动态渲染路由。后端接口层面可以通过拦截器校验登录状态再通过自定义注解或角色判断来控制接口访问权限。这里的小技巧是不要只在前端做按钮级隐藏后端接口必须做二次校验否则答辩时老师写个脚本直接调接口你的权限体系就等于摆设。1.3 功能优先级取舍策略毕设时间有限功能一定要分优先级。我给出的建议是核心链路优先加分功能量力而行。第一优先级是房源管理、用户登录注册、合同与账单管理。这是整个租房系统的骨架如果这几个模块没做完项目逻辑上就不成立。第二优先级是搜索筛选、到期提醒、数据统计。这些功能属于“看起来很专业”的部分工作量不小但技术含量适中做完以后系统完成度会明显上一个档次。第三优先级是消息通知、收藏功能、在线聊天。这部分我建议直接砍掉或者做成最简单的轮询版因为涉及 WebSocket 或更复杂的前端交互不是毕设的核心评分点花大量时间在上面性价比极低。我在实际划分时还加了个“低频但有亮点”的思路可以用 Redis 做缓存来加速房源列表的访问虽然毕设并发量根本用不上缓存但在设计说明里写一句“利用缓存降低数据库压力”就是妥妥的加分项。2. 技术选型与项目骨架搭建2.1 版本选型背后的坑很多人在毕设开头就卡在环境上核心原因是盲目选择新版本。SpringBoot 3.x 虽然出了很久但它基于 Spring Framework 6要求 JDK17 起步很多配套教程中间件还没完全跟上。我的建议就是老老实实用 SpringBoot 2.7.x JDK8这是生态最稳的组合网上资料一抓一大把遇到问题随便搜都能找到答案。配套选型方面ORM 层选 MyBatis-Plus 而不是原生 MyBatis因为它的条件构造器能省掉大量 XML 里的 if 判断对赶时间的毕设来说体验是质的提升。数据库连接池用 Druid监控页面可以直接访问写论文时还能截图展示“系统具有良好的可观测性”。权限控制用 JWT 拦截器无状态认证前后端分离场景下最好用而且源码量少答辩时容易解释。接口文档建议引入 Knife4j基于 Swagger 的增强版页面比原生 Swagger 好看很多生成接口文档后写论文的“系统设计”章节直接复制核心部分即可。这个选型组合看似普通但胜在每一项都在“够用”和“有深度”之间取得了平衡。避免选择一个过于小众的技术栈导致答辩时老师无从问起也避免全用最基础的工具导致项目毫无亮点。2.2 数据库设计要点数据库设计是整个项目的地基表结构一旦定下来后面写代码其实就是照表操作。租房系统核心表建议这么设计user用户表id、用户名、密码BCrypt 加密存储、真实姓名、手机号、角色标识0 管理员 / 1 房东 / 2 租客、创建时间。house房源表id、房东 id、标题、小区名、地址、户型几室几厅、面积、朝向、楼层、租金、押金方式、出租状态0 未出租 / 1 已出租、房屋描述、发布时间。tenant租客表id、用户 id、身份证号、紧急联系人、紧急联系电话、职业信息、备注。contract合同表id、合同编号、房源 id、租客 id、房东 id、起租日期、结束日期、租金、押金、付款周期月付 / 季付 / 年付、合同状态、签订时间。bill账单表id、合同 id、账单编号、费用类型租金 / 押金 / 水电费、金额、账期如 2025-01、缴费状态0 待缴 / 1 已缴 / 2 逾期、缴费时间。house_apply租赁申请id、房源 id、租客 id、申请状态待处理 / 通过 / 拒绝、申请时间。字段类型上有几个值得注意的点金额一律用DECIMAL(10,2)而不是DOUBLE避免浮点误差时间字段统一用datetime面积建议保留一位小数。主键直接bigint自增就好不需要为了炫技用雪花 ID那是给自己找麻烦。外键不要真的在数据库层面建逻辑外键就够了。一方面数据删除灵活另一方面避免 MySQL 在外键约束下做级联操作时的性能损耗。答辩时老师如果问为什么不用外键可以回答“在高并发写入场景下外键约束会带来额外的锁开销实际开发中常用应用层保证数据一致性”这个回答非常加分。2.3 项目目录结构与分层设计很多初学者喜欢把所有代码塞到 controller 里一个方法几百行看着热闹实则维护成本极高。SpringBoot 项目推荐用标准分层架构cn.xx.rent ├── config // 配置类跨域、拦截器、Knife4j ├── controller // 接口层接收参数并返回统一结果 ├── service // 业务层核心逻辑处理 │ └── impl ├── mapper // 数据访问层MyBatis-Plus 的 Mapper 接口 ├── entity // 数据库实体类 ├── dto // 传输对象接收前端参数 ├── vo // 视图对象返回给前端的数据 ├── common // 通用类统一返回结果、异常处理、常量 ├── utils // 工具类JWT 工具、日期工具 └── RentApplication.java有一个很关键的习惯要养成前端传参不要直接绑定entity而是定义dto接口返回值不要直接返回entity而是封装成vo。虽然在小项目里这看起来有点绕但它的好处很实在实体类字段有时候包含密码这类敏感数据直接返回前端就是隐患而且定义 VO 后你可以在里面额外添加“房东姓名”“房源图册”这类关联展示字段前端拿数据会非常舒服。在common包下定义统一的ResultT返回类包含code、message、data三个字段所有接口统一返回。前端拿到这种结构后处理逻辑完全一致不会为每个接口单独写一套解析方法。这块一定要在开工前搭好否则后面写一个接口写一套返回光统一格式就能耗掉半天。3. 核心功能实现与实操要点3.1 登录鉴权与权限控制实现细节登录逻辑看似简单但要做好需要处理几个细节密码不能明文存储登录态不能放在HttpSession里由后端维护因为前后端分离项目需要无状态认证。我用的方案是 JWTJSON Web Token。用户登录成功后后端生成一个 token 返回给前端前端存储在localStorage每次请求在请求头携带Authorization: Bearer token。后端写一个拦截器统一拦截需要认证的路径解析 token 成功后直接放行同时在request里设置用户 ID 供后续业务使用。生成 token 的核心代码如下public String generateToken(User user) { MapString, Object claims new HashMap(); claims.put(userId, user.getId()); claims.put(role, user.getRole()); return Jwts.builder() .setClaims(claims) .setSubject(user.getUsername()) .setExpiration(new Date(System.currentTimeMillis() 7L * 24 * 3600 * 1000)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }拦截器的关键点在于白名单路径必须放行比如/api/user/login、/api/user/register、/api/house/list因为未登录也要能浏览房源。不要拦截静态资源。调试时最容易出问题的是遗漏跨域配置前端请求带 token 时会出现预检请求后端必须正确响应OPTIONS请求否则前端会一直报跨域错误。密码加密直接使用BCryptPasswordEncoder这玩意儿的好处是每次加密结果都不一样数据库被脱库也无法反推出原始密码答辩时提到“采用了不可逆加密算法存储敏感信息”本身就是安全意识的表现。3.2 房源管理与多条件检索实现房源管理是整个系统最核心的模块录入、修改、上下架、列表展示每个环节都要考虑。我建议把房源列表做成支持多条件筛选的形式关键词搜索小区名 / 地址、租金范围、户型筛选、状态筛选。用 MyBatis-Plus 的条件构造器写这种动态查询非常舒服不需要写 XML 里的各种if标签LambdaQueryWrapperHouse wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.isNotBlank(keyword), House::getAddress, keyword) .ge(minRent ! null, House::getRent, minRent) .le(maxRent ! null, House::getRent, maxRent) .eq(type ! null, House::getType, type) .eq(status ! null, House::getStatus, status) .orderByDesc(House::getCreateTime);这里有个容易踩的坑条件构造器里链条式写法虽然简洁但要注意like查询的关键词必须提前做空值判断否则用户什么都没输入时会把整个表的数据全部查出来。别看这个错误低级实际开发中至少一半的查询副作用都是这种因素导致的。分页方面MyBatis-Plus 提供了Page对象配合分页插件使用PageHouse page new Page(pageNum, pageSize); PageHouse result houseMapper.selectPage(page, wrapper);前端传pageNum和pageSize后端返回total总记录数和records当前页数据。前端用 Element UI 的el-pagination组件可以直接对接。房源上下架相当于一个状态更新接口通过updateById修改状态字段即可。有一个小细节要注意房子处于“已出租”状态时下架后是否允许编辑我的做法是已出租房源锁定核心字段地址、户型、租金只允许修改描述信息这是为了模拟真实业务中合同存续期间的约束规则。3.3 合同管理与到期自动提醒合同管理是租房系统里最有业务深度的部分做好了整个项目的档次就上去了。合同的状态流转可以设定为待生效 → 生效中 → 已到期 → 已退租。合同创建时要做几件重要的事检查房源当前不是“已出租”状态避免一房多租。生成唯一的合同编号建议格式为HT 年月日 4位随机数。根据合同起止日期提前生成所有周期的账单记录。将房源状态更新为“已出租”把租客和房源进行绑定。账单生成的逻辑值得展开一下。如果付款周期是“月付”合同期限是 12 个月那就要在签合同的同时生成 12 条账单记录每条账单对应一个账期。这里写一个循环生成即可但要注意日期计算方式第一期的截止日期是起租日期加一个月第二期以此类推。这种“合同驱动账单”的设计思路在答辩时能展示你对业务闭环的理解。到期提醒可以用 SpringBoot 自带的Scheduled定时任务Scheduled(cron 0 0 8 * * ?) public void remindContractExpire() { // 查询三十天内即将到期的合同 // 给房东和租客发送通知 }定时任务虽然一行注解就能启用但有几个隐藏细节需要在测试时关注时间默认走服务器时区如果服务器在国外那每天 8 点执行的含义可能会跟预期不一样建议在配置文件里明确spring.jackson.time-zone: GMT8另外生产环境如果有多个实例部署同一时刻定时任务会执行多遍虽然毕设用不到但论文明里可以提一句“可以通过分布式锁保证单个实例执行”。3.4 账单统计与数据可视化前面把账单生成了这个模块就是把账单数据进一步加工让系统管理者能看到经营概况。我建议在后台管理页面放一组统计卡片和一张图表包括总房源数、已出租房源数、本月应收租金、本月实收租金、租客总数。实现方式用 MySQL 聚合函数配合 Java 8 Stream 都可以但聚合统计这类操作更适合直接让数据库算好返回Select(SELECT IFNULL(SUM(amount), 0) FROM bill WHERE status 1 AND bill_period #{month}) BigDecimal sumPaidAmount(String month);在 MyBatis 中直接写注解 SQL 处理这种简单统计比用 MyBatis-Plus 更直观因为条件构造器表达不了聚合函数。不过要注意SUM结果可能为null需要用IFNULL兜底否则 Java 这边接一个null做运算就直接空指针。图表展示部分前端使用 ECharts后端提供两个统计接口一个是租金趋势近六个月的应收实收折线图一个是房源户型分布饼图。前端拿到 JSON 数据后配置一下option就完事。这一块属于典型的面向前端展示型功能难度不大但视觉效果非常显著系统演示录屏的时候也是很好的素材。4. 常见问题排查与避坑实录4.1 前后端联调的 JSON 格式与跨域问题前后端分离开发时第一个拦路虎基本就是跨域。后端 SpringBoot 默认不允许跨域请求解决方式是写一个配置类Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedMethod(*); config.addAllowedHeader(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }这里有个跟 JWT 相关的隐藏坑当你携带 token 发起请求时浏览器会先发一个OPTIONS预检请求预检请求不会携带自定义请求头。如果拦截器拦截了所有请求并直接校验 token预检请求就会返回 401前端表现就是“明明接口能通为什么还是报跨域”。解决方式很简单在拦截器里先放行OPTIONS请求再继续校验逻辑。后端返回的日期类型默认序列化为yyyy-MM-dd HH:mm:ss格式还好但 LocalDate 类型默认不带时分秒前端解析时可能报错。建议在配置文件里统一指定spring.jackson.date-formatyyyy-MM-dd HH:mm:ss spring.jackson.time-zoneGMT84.2 Maven 依赖冲突与打包问题SpringBoot 项目最常见的打包报错是Skip Tests没开导致的构建失败以及主类找不到。排查思路如下确保maven-compiler-plugin编译版本设置为 JDK8 对应的 1.8否则你用的 JDK 版本不同会出现编译期方法签名错误。打包时建议执行mvn clean package -DskipTests跳过测试避免某些测试用例影响构建。依赖冲突集中在druid-spring-boot-starter和knife4j上有时会因为传递依赖引入旧版 Jackson 导致 JSON 序列化问题。遇到此类情况可以在pom.xml里排除传递依赖强制使用 SpringBoot 统一管理的版本。这里多说一句很多同学项目开发环境跑得好好的但打包部署到服务器就起不来大概率是编译版本问题。配置里的java.version必须和机器上的 JDK 匹配不然就是各种invalid target release报错。4.3 定时任务与数据一致性细节合同到期自动修改状态、账单逾期自动标记这些操作依赖定时任务但定时任务里的逻辑一定要考虑幂等性。如果数据重复处理就会出现租客已经退租了合同还在“生效中”这种尴尬情况。我的做法是在定时任务执行前先查询当前状态只有状态匹配的数据才更新ListContract expiringList contractMapper.selectList( new LambdaQueryWrapperContract() .eq(Contract::getStatus, 生效中) .lt(Contract::getEndDate, LocalDate.now().plusDays(30)) );同时数据库层面也加上状态筛选条件双重保障。这里有个非常值得讲的细节不要直接在定时任务里调用 service 的更新方法去“批量更新所有到期合同”而应该一条条查询、一条条更新这样即使中途失败只需要观察日志定位到具体哪一条数据出了问题。批量更新的异常日志往往不精确排错效率很低。并发部分还有一个隐蔽的问题用户在前端同时点“确认退租”和定时任务在后台跑“合同到期更新”可能导致同一条合同被重复更新。解决思路是在更新 SQL 里加状态条件比如UPDATE contract SET status 已退租 WHERE id ? AND status 生效中这样即使两个请求同时到达也只有其中一个能真正执行成功。4.4 数据脱敏与接口安全细节租房系统里面涉及租客身份证号、手机号等敏感信息。哪怕只是毕设也要有点安全意识。我的建议是后端接口中凡是返回身份证号、手机号这类信息都在 VO 层做脱敏处理展示时只保留前几位和后几位比如110***********1234。这不影响功能演示但论文里写“对个人敏感信息进行脱敏处理”就是一个区别于其他同学的安全意识加分项。另外管理员和房东登录后能看到的房源列表边界也要注意房东进入后台只能操作自己的房源和合同。所以房源列表查询时除了条件构造器还要额外加一个eq(House::getOwnerId, userId)的条件。这块是典型的越权漏洞来源很多初学毕设的人忽略了“数据范围权限”结果 A 房东能看到 B 房东的房子答辩现场被老师点出来会非常狼狈。5. 项目答辩与说明文档组织技巧5.1 演示流程的合理设计毕设答辩时系统演示一般只有 5 到 10 分钟很多同学一上来就从前端页面开始点结果时间全浪费在加载数据和切换菜单上。我的经验是演示要按“业务故事线”走不要按菜单顺序走。可以先演示管理员登录打开数据统计页面通过图表快速展示系统整体情况数据量大、信息全、系统是真实业务场景。然后切换到一个房东账号创建一个房源修改房源信息模拟租客注册并发起申请房东确认申请后生成合同。再打开账单页面展示合同生成的账单列表演示租客缴费功能。最后演示合同到期提醒和退租操作。你会发现这条线其实就是真实业务的完整闭环而“按菜单演示”只是在念系统功能清单没有故事感。5.2 文档编写的核心素材来源写说明文档最费时间的是画用例图、ER 图、流程图。手动绘制效率极低但通常建模工具可以直接从接口和数据表反向生成。有的工具比如某些 IntelliJ 插件能直接从数据库反向生成 ER 图这样出来的图又规范又好看。论文里这些图贴上以后整个文档的专业度会非常明显。技术架构选型部分直接把你最终确定的技术栈按“集成层、接口层、业务层、数据层”写清楚再把选择每一项技术的理由写一句。不要写“为了毕业设计方便”这种话要写“SpringBoot 简化了项目初始化和部署复杂度内嵌容器便于快速启动”“MyBatis-Plus 在满足灵活 SQL 编写能力的同时大幅提升了开发效率”。这些话就是老师想听的设计理由。写在后面的一点体会做完这个租房管理系统我最大的感受是毕设选题真的不用贪大。一个 SpringBoot 单体应用、七八张核心表、三到四个角色只要把业务闭环跑通把两三个技术细节做出深度就已经是相当扎实的毕业设计了。我见过很多同学一年前就开始准备最后却因为反复重构和追求完美导致连基本功能都没做完这是最可惜的结果。如果你正在做类似的系统我的建议是把核心链路先跑通把登录、房源、合同、账单这几条线先理顺再去优化细节和界面。等项目能整体运行起来那种踏实感会帮你把剩下的事情一股气做完。祝你的毕设顺利过关。