1. 从毕设题目到可运行系统：这个公寓租赁项目到底要做什么

每年毕设季，总有那么一批同学拿到"XX系统的设计与实现"这类题目就开始发愁。图书馆里坐三天，代码没写几行，Word倒是建了几个模板。说实话，这类题目恰好是计算机专业毕业设计里最"中规中矩"的一种——平台类管理系统，需求清晰、技术成熟、资料好找，能不能做出亮点，全看你是否真正理解它背后的业务逻辑。

公寓租赁系统，名字听上去就是一个"租房信息管理后台"。但真正动手之后你会发现，它至少牵扯到三条业务主线：房源管理、合同流转、租金账单。任何一条线在传统的Excel管理下都容易乱——房间状态说不清、合同到期没人提醒、租金催缴全靠口头，更别说房东和租客之间的报修沟通、押金退还这些扯皮事。所以这套系统的核心价值，是通过一套标准的线上流程，把公寓租赁的"签、租、缴、修、退"全都管起来。

放在毕设语境下，它其实是把你大学四年学的技术栈串一遍：前端做页面，后端做接口，数据库建模，还要处理用户权限、业务状态流转、数据统计这些实际问题。你用Spring Boot也好，用SSM整合也罢，只要业务闭环是完整的，答辩时就有东西可讲。

这篇博文，我会从需求分析、技术选型、数据库设计、核心模块实现、权限与安全、项目部署这几个层面，完整拆解一个基于Spring Boot的公寓租赁系统是怎么从零落地成一份硬核毕设的。文末也会聊一些答辩时容易被追问的点，以及我在这类项目上吃过亏的地方。

适合两类人看：一是要做类似毕设、想找个清晰参考的同学；二是想快速了解"管理系统类毕设到底怎么做出差异化"的计算机专业学生。源码我会提到对应的模块组织思路，具体环境配置也按实际可复现的标准来写。

2. 需求边界与技术选型：为什么这套方案最适合拿来当毕设

2.1 先理清角色和业务边界，别一上来就写代码

很多同学拿到题目的第一反应是建Spring Initializr，这其实是本末倒置。做管理系统类毕设，第一步永远是画用例图、理角色。公寓租赁系统里至少有这三类人：

• 管理员：维护公寓信息、房间信息，管理房东和租客的账号，查看所有合同和账单，处理投诉建议。
• 房东（业主）：发布房源、维护房间状态、处理租客报修、发起收租提醒。
• 租客：查看可租房间、提交租房申请、在线签约、查账单、报修、退租申请。

确定角色之后，再去梳理"这个系统要支持什么样的业务流程"，比如：房间从"空闲"到"已预定"再到"已入住"最后"已退租"，这个状态机的流转规则是什么；合同到期前多少天要提醒；租金逾期后账单单据怎么变更。这些流程想清楚，数据库设计自然水到渠成，代码只是把它们翻译成逻辑而已。

我见过太多同学把租赁系统做成一个"房间信息增删改查"的玩具，答辩时被老师一句"你这个系统和Excel表有什么区别"直接问傻。把业务边界画好、流程说清楚，是拉开档次的第一步。

2.2 技术栈选择的底层逻辑：稳定、够用、能讲

公寓租赁系统的技术选型，我建议走最稳妥的组合：

这里有个非常现实的考量——毕设项目不要追新，要追稳。Spring Boot 3.x虽然已经普及，但部分旧教程和依赖可能适配有问题，2.x的资料最多，遇到坑解决起来最快。同理，JSP在国内各类"基于JSP的毕设"题目里出现频率依然很高，但如果你是从零开始写，我个人更推荐Thymeleaf，它在Spring Boot里整合体验远比JSP舒服。

2.3 为什么推荐"增删改查 + 状态机 + 报表"三层结构

很多同学担心"我做的是管理系统的增删改查，会不会太简单"。其实管理系统的难点从来不是单个表的CRUD，而是业务状态流转的正确性。以公寓租赁系统为例：

• 房间创建后是"待出租"；
• 租客发起预订，房间变成"预定中"；
• 管理员/房东审核通过并签订合同，房间变为"已出租"；
• 合同到期且无续签，房间回到"待出租"。

这套状态机写清楚，在答辩时讲"我是如何保证并发状态下同一间房不会被同时租给两个人"——这就是一个非常漂亮的亮点。对应到实现上，你可以用数据库行级锁（SELECT ... FOR UPDATE）或乐观锁（版本号字段）来处理房间状态变更，这些点都是能扛住老师提问的硬货。

报表部分至少要有三个图：公寓入住率统计、月度租金收入趋势、房间类型分布。别小看这几张图，它把你这套系统从"记录工具"提升到了"管理工具"的层级，也能自然地引出SQL聚合查询和ECharts配置的讲解。

3. 数据库设计：一张表对应一段业务，外键不是万能的

3.1 核心数据表有哪些，字段怎么定

数据库设计的质量基本决定了后期写代码的心情。公寓租赁系统最少需要这几张表：

• 用户表（sys_user）：主键、用户名、密码、姓名、手机号、角色类型（管理员/房东/租客）、状态、创建时间。
• 公寓表（apartment）：公寓名称、地址、楼层数、是否包含电梯、配套描述、管理员ID。
• 房间表（room）：所属公寓ID、房间号、面积、户型、租金单价（月）、状态（待出租/预定中/已出租/维修中）、房间图片URL。
• 合同表（contract）：合同编号、租客ID、房东ID、房间ID、起租日期、结束日期、押金、租金/月、合同状态（生效中/已退租/已过期）。
• 账单表（bill）：账单编号、关联合同ID、费用类型（月租/水电/押金/维修费）、金额、生成时间、缴费状态（未缴/已缴）、缴费时间。
• 报修表（repair）：报修编号、房间ID、租客ID、报修内容、报修图片、状态（待处理/处理中/已完成）、处理时间。
• 公告表（notice）：标题、内容、发布人ID、（发布时间）。

字段设计有两条原则：第一，凡是展示页要用的字段尽量冗余存储，不要过度范式化。比如账单表里存合同编号就够，但为了展示方便，可以直接冗余一个租客姓名、一个房间号，省得每次join三张表。第二，所有业务表都要有状态字段和创建时间，后续做筛选、统计、回溯都有依据。

3.2 关联关系、索引和并发控制细节

表之间的关系要画清楚，文档里体现为E-R图。实际创建外键约束我不反对，但更推荐在Java代码层维护逻辑关联——外键约束在跑批导入、造测试数据时经常帮倒忙，而逻辑外键加索引的方式既灵活又不影响带着概念图去答辩。

关键索引设计：

• room表：(apartment_id, room_status)联合索引，用于按公寓筛选房间。
• contract表：(tenant_id, status)联合索引，用于查某租客的生效合同。
• bill表：(contract_id)索引，用于账单关联查询。

并发状态机的实现，我建议用update room set status = 'reserved' where id = ? and status = 'available'这种条件更新，然后将受影响行数作为判断依据。受影响行数等于0说明抢租失败，直接抛业务异常提示"房间已被预订"。这一步拿到答辩现场讲清楚，老师就知道你不是在背代码，而是真的考虑过并发场景。

3.3 初始化数据与测试数据：顺手造的假房东也要像模像样

数据库建完之后，一定要写一个初始化数据的SQL脚本。里面至少要有：一个管理员账号、三四个房东账号、五六个租客账号、若干公寓和房间，并配上真实的地址和图片占位路径。这些数据有两大作用——让自己开发时页面不至于空荡荡，也让答辩时演示效果丰满。

密码字段不要存储明文，至少用MD5加盐或BCrypt。如果你是毕设，答辩时主动讲一句"密码通过BCrypt加密存储，即使数据库泄露也无法倒推明文"，这就是一个即时的安全加分项。

4. 后端核心模块实现：合同、账单、状态流转的代码细节

4.1 项目结构怎么组织，包名规划直接决定代码"气质"

后端代码结构建议这样划分：

com.example.apartment ├── common │ ├── result（统一返回结果） │ ├── exception（全局异常处理和自定义异常类） │ └── constant（状态常量） ├── config（跨域、拦截器、MyBatisPlus配置） ├── controller（接口层） ├── service（业务逻辑层，含实现类） ├── mapper（数据访问层） ├── entity（实体类） └── utils（JWT或工具类）

实体类和数据库表字段保持一致，用MyBatis Plus的@TableName和@TableId注解标注即可。Service层把业务写扎实，Controller只做参数接收和结果封装，这算是三层架构的基本功，答辩时打开代码结构就是一份无形的加分材料。

4.2 合同生成的业务闭环：怎么把零散操作串成一条流

一篇好的毕设博文应该让你感觉到"哦，原来这些操作是有关联的"。在公寓租赁系统里，签约功能的代码逻辑是这样的：

1. 前端提交签约请求，参数包含租客ID、房间ID、起止日期、月租金；
2. 后端校验该房间状态必须为"待出租"；
3. 锁定该房间记录（SELECT ... FOR UPDATE），再次校验状态；
4. 创建合同记录，状态为"生效中"；
5. 生成首月账单（租金+押金）与周期账单计划；
6. 将房间状态改为"已出租"；
7. 返回合同详情，前端跳转合同列表。

这里最值得学习的其实是一个事务里不该只操作一张表。签约、生成账单、改房间状态，三者必须放在同一个@Transactional中，否则一旦生成账单失败，房间状态却改成已出租，后面就全乱套了。理解"事务边界"不是背概念，而是在这种多表写操作里真实运用它。

4.3 账单状态与催缴逻辑：用定时任务做自动化

账单模块的亮点有两个，一个是账单自动生成，另一个是到期提醒。

周期账单的生成，可以在生成合同时，按照租赁月数批量创建账单记录；也可以依赖@Scheduled定时任务，每月1号扫描所有生效合同，为本月尚未生成账单的合同补单。后一种做法的好处是，即使合同创建于月中，下个月仍然能正确出账。

催缴提醒我用的是Spring Boot的@Scheduled+ 站内消息/短信接口预留位。每天扫描账单表，把所有"已出账但未缴费且超期7天"的账单找出来，给租客发通知，给房东生成提醒记录。这块实现并不复杂，但"定时任务"这个名词一出来，答辩的层次就又高了一层。

4.4 报修模块的流程状态控制

报修单的状态至少要有四态：待处理 → 已接单 → 处理中 → 已完成，另外可加一个"已驳回"。状态变更需要记录操作人ID和变更时间，方便后续追溯。实际开发中，可以把状态字段设计成Integer枚举，并配合STATE_MAP常量类统一管理含义，避免代码里散落一堆魔法数字。

这个模块技术上没有难度，麻烦的多半是页面。报修详情页建议放：报修人、联系手机号、房间信息、文字描述、图片列表、处理进度时间线。处理进度可以用一个简单的状态时间戳字段拼出来，效果很直观，答辩展示时也好看。

5. 权限与安全设计：Session还是JWT，别只会配置不会说

5.1 登录流程和角色鉴权

三种角色的登录鉴权是必须的。最简单的方案是Spring Security + Redis存储用户会话，登录成功后向Redis写入登录凭证，后端基于角色进行接口级别的权限控制。另一种常用方案是JWT（JSON Web Token），登录后服务端签发Token，前端存到localStorage，请求时放在Authorization头里。

两种方案我个人的使用倾向是：

• 如果做的纯后端模板渲染，用Session方案更简单直观，也在Web依赖中天然集成；
• 如果做了前后端分离（Vue3 + Spring Boot），用JWT更适合无状态场景，接口天然支持跨域。

答辩时老师特别喜欢问的一句话是："JWT的Token万一泄露了怎么办？"这个问题你提前准备一下，可以从缩短有效期、加入Token版本号、配合Redis做单点登录控制几个角度答，基本都能让老师点头。

5.2 若干容易被忽略的安全细节

• 接口层统一参数校验：通过JSR 303注解（@NotNull、@Size、@Pattern）校验前端传入参数，避免脏数据直接落库。
• SQL注入防御：永远使用预编译和参数占位符，禁止拼接SQL字符串。这点用MyBatis只要写#{}不写${}基本就不会出错。
• 越权访问控制：租客只能查自己的合同和账单，管理员可以全量查。后端逻辑要判断数据归属，不能只依赖前端按钮隐藏。
• 文件上传：如果是证件信息或报修图片上传，记得校验文件类型和大小，把文件名重命名为UUID后存储，禁止使用用户传入的原始文件名。

5.3 登录安全的前端体验细节

做登录页的时候，除了账号密码框，记得加一个验证码（可用Hutool的验证码工具生成）。这不仅仅是形式上好看，在讲安全设计时，它能作为"防止暴力破解"最直接的体现。同时，登录失败要提示"用户名或密码错误"，一定不要精确提示"用户不存在"，这也是安全常识。

6. 前端与页面设计：LayUI还是ElementUI，选对框架事半功倍

6.1 页面方案一：Thymeleaf + Bootstrap/LayUI，快速出活

面向毕设的快速开发，最稳的组合是Thymeleaf + LayUI。LayUI在后端管理类系统里特别顺手，表格自带分页、弹窗、表单校验，很多管理后台都是这个组合。模板里通过Thymeleaf语法渲染登录用户名、菜单列表、页面数据，省去前后端联调的时间。

页面至少包含以下模块：登录页、管理员后台首页（统计卡片+图表）、公寓管理页、房间管理页、合同管理页、账单管理页、报修管理页、用户管理页、公告管理页。整体风格不用花哨，干净整齐的左右布局或者顶部导航加下面内容的经典后台布局就够了。

6.2 页面方案二：前后端分离Vue3 + Element Plus

如果你对自己的前端有信心，或者毕设题目中明确写了"基于Spring Boot + Vue"，那前端独立项目会让你在整体结构上更像一个企业级产品。Vue3 + Vite + Element Plus + Axios + ECharts，这一套组合在管理和展示上都更现代，接口对接也规范。需要特别注意的一点是跨域配置——在Spring Boot的config中要实现CorsFilter或者WebMvcConfigurer的跨域配置，前端Vite里做Proxy转发也可以，二选一即可。

对多数同学来说，我建议的目的是"能演示、能截图、能讲清前后端交互流程"。做一个基于Token登录的演示页面，用Axios做请求拦截器统一注入Token，收到401就跳转登录页，这个链路完整跑通，已经足够在答辩证上展示你的工程能力。

6.3 管理页面里的几个"锦上添花"设计

• 首页统计卡片：总房间数、当前出租数、本月租金收入、待处理报修数。这四个数字一眼知其全貌，连统计SQL都简单。
• 房间状态可视化：按照"待出租/已出租/维修中"给房间卡片标颜色，直观展示出每个房间的当前状态。
• 租约日历：在管理页嵌入一个简易日历或列表，高亮显示近7天即将到期的合同，这个功能哪怕用纯前端筛选也能实现，但演示效果极好。

7. 项目部署、源码使用与答辩要点：把毕设讲成项目而非作业

7.1 本地部署的完整链路和坑点

带源码的毕设项目，最怕的是新环境跑不起来。我在本地部署时固定走这几步，你直接照做：

1. 安装JDK 1.8以上，配置JAVA_HOME环境变量；
2. 安装Maven 3.6以上，配置阿里云镜像加速依赖下载；
3. 安装MySQL，执行项目里的init.sql脚本创建数据库和表数据；注意数据库字符集选择utf8mb4，否则存emoji或中文容易出现乱码；
4. 修改项目里application.yml的数据源配置，密码改成你自己本地的；
5. 启动Spring Boot项目，浏览器访问localhost:8080；如果端口被占，在application.yml里改端口。

最容易翻车的点有三个：MySQL密码不匹配、Maven依赖下载超时（所以必须配镜像）、Java版本太高导致依赖不兼容。我建议全部使用JDK 1.8和Spring Boot 2.7组合，兼容性最稳。

7.2 拿到源码之后怎么"吃透"它

源码附带的项目，只在你手里"能跑"其实毫无意义，你要做的是：

• 把数据库表结构和E-R图对应起来，看每个表字段在代码里哪个地方被读写；
• 把Controller、Service、Mapper三层调用链画出来，这样答辩被问到任意一个功能都能说清"请求从哪里来，数据流到哪里去"；
• 改造一到两个自己的功能点，比如换一种租金计算规则（阶梯租金），或者加一个合租房源类型。哪怕是小修改，也能向老师证明这是你自己的工作量。

7.3 答辩演示的流程编排与高频问题

演示环节不要上来就点菜单。我建议按故事线走：

1. 用管理员登录，展示首页统计数据和图表；
2. 查看公寓与房间列表，演示添加一条房源；
3. 用一个租客账号发起预订，切换到管理员审核并签约；
4. 租客视角查看合同与账单，演示在线缴费（可用模拟接口）；
5. 发起报修，房东端接单处理，租客确认完成；
6. 最后展示账单统计报表和到期合同提醒。

高频问题我列几个，建议提前想好答案：

• "你做过并发测试吗？如何保证同一房间不会同时租出？"——讲条件更新和事务，如果有压测数据更好。
• "如果租客逾期不缴租金，系统怎么处理？"——讲定时任务扫描逾期账单，自动发提醒，超过N天合同自动标记逾期/冻结。
• "权限设计是注解控制还是代码拦截？"——讲你的具体实现，无论是注解还是拦截器，都要能画出控制链。
• "为什么选择这个数据库？有哪些索引设计？"——讲选择的动机和联合索引字段。

7.4 最重要的一条经验：开源代码也要留出自己的指纹

到答辩前，你必须对系统的每个页面都有"这是我的作品"的底气。这不仅是学术规范的问题，更是你真正把毕设变成自身项目经验的过程。哪怕你在UI上换了一套颜色主题、加了一种房间标签，或者只改了几行逻辑，都算你在这套系统上留下了自己的痕迹。这既是对学术诚信的尊重，也是理直气壮面对提问的基础。答辩时，你可以指着任一个页面说清楚它背后的数据表、接口和逻辑，这才是毕设真正的价值所在。

另外，给所有做毕设的同学一句心里话：不要怕前期需求分析阶段花时间，需求想清楚了，后面写代码基本是体力活。反过来，一行代码没写就纠结用不用Redis缓存这种问题，才是真正的浪费时间。公寓租赁系统的核心是业务闭环和状态流程，把这几件事理明白，你就已经超过大半对手了。