基于Spring Boot的房屋租赁管理系统设计与实现指南

每年到了三四月份，总有一批大四的同学在宿舍里挠头：开题报告的截止日期越来越近，系统代码却连个登录页都没跑起来。要是你拿到的题目恰好是“基于Spring Boot的房屋租赁管理系统的设计与实现”，那这篇文章就是给你准备的。我从选题拆解、技术选型、数据库设计、核心功能实现，到论文和开题报告的撰写节奏，把整条线捋一遍。这篇文章不是那种“教你复制粘贴跑通就完事”的速成教程，而是站在“要答辩、要交论文、要让评委挑不出毛病”的角度，把每一个关键的决策点都讲透。

我自己带过不少毕业设计，也在实际项目里用 Spring Boot 写过类似的业务系统，所以这篇文章里有很多东西，是你在学校课堂上和大多数博客里看不到的。如果你正准备动手，或者已经卡在某一步，耐心看完，应该能帮你省下不少返工的时间。

1. 项目整体设计与技术选型思路

1.1 毕业设计选题：为什么是房屋租赁管理系统

房屋租赁管理系统在毕业设计里属于“经典中的经典”。它经典，不是因为题目烂大街，而是因为这个业务场景的复杂度刚好合适：有用户角色区分（租客、房东、管理员）、有核心业务流转（房源发布、预约看房、签订合同、账单支付）、有状态变化（房源上架/下架、合同生效/到期）、还有数据统计需求（租金收入、房源利用率）。这些要素切得恰到好处，既不会简单到让评委觉得你在划水，也不会复杂到让一个应届生半年都做不完。

选这个题目还有一个隐性好处：业务模型贴近日常生活，你在答辩的时候不需要花大量时间解释业务背景。评委问“为什么需要这个功能”，你直接说“租客找房难、房东管房乱、中介收费高”，一句话就能让所有人理解系统存在的价值。相比之下，如果你选一个“基于深度学习的xxx”之类题目，光解释模型原理和数据标注就能把你问晕。

从工作量分配上看，房屋租赁管理系统非常适合一个人独立完成。前端页面、后端接口、数据库设计、论文撰写，各占一块，每个部分都有东西可写，但又不会彼此纠缠到失控。这对接下来的论文查重和功能演示都很有利——论文里有真实的功能设计图和表结构描述，答辩现场也能够完整演示，不会出现“实现了一堆功能但讲不清”的尴尬。

1.2 技术栈选型：Spring Boot + Vue 前后端分离的考量

技术栈是开题报告里最容易被追问的部分，也是很多同学第一个踩坑的地方。我的建议非常明确：后端用 Spring Boot，前端用 Vue，数据库用 MySQL，部署用阿里云学生机或本地虚拟机，鉴权用 JWT。这套组合是当前中小型管理系统的主流搭配，网上资料多、社区问答多、导师也不陌生，踩坑时能查到解决方案的概率远高于那些冷门组合。

Spring Boot 的优势不光是“简化配置”。它内置了自动装配机制，你引入一个 spring-boot-starter-web 依赖，内嵌的 Tomcat 就会帮你把 Web 环境搭好，不需要像传统 SSM 那样去配置一大堆 XML。这个特性对毕业设计来说特别重要，因为你没有时间去死磕环境搭建，精力应该花在业务逻辑和论文写作上。

前端选择 Vue 而不是 JSP 或 Thymeleaf，原因也很简单：前后端分离的架构更容易拉开工作量、更容易写进论文。“基于前后端分离架构”这句话本身就是一个加分项，而且 Vue 的生态足够成熟，Element UI 组件库里的表格、表单、弹窗都是现成的，美观度也远超写 JSP 标签。你不需要是前端大神，把组件拖过来改一改、绑一下数据，就能做出一套看起来很像样的管理界面。

有一点要特别提醒：Spring Boot 的版本千万不要盲目追求最新。现阶段最好选 2.7.x 这个系列，而不是 3.x。原因很现实，很多教程、博客、开源代码都基于 2.x 的写法，你搜索问题时能直接搜到答案。3.x 在 Jakarta EE 命名空间、Spring Security 配置方式上有不小变化，如果照着一堆 2.x 的老教程去配，很容易出现“版本太高反而跑不起来”的尴尬。等你把所有功能调通之后，如果还有多余时间，再去折腾升级不迟。

1.3 功能模块划分与需求分析

系统功能模块怎么划分，直接决定你论文里那张“系统功能结构图”长什么样，也决定你后期的工作量上限。我把我的划分方案分享出来，你可以在它的基础上增减。

整个系统分成三个角色：管理员、房东、租客。管理员负责整体运营，包括用户管理、房源审核、订单监控、数据统计。房东可以发布房源、管理自己名下的房源、查看预约、确认合同、处理账单。租客可以搜索房源、浏览详情、发起预约、签订合同、在线支付租金、提交退租申请。

从功能模块的角度细拆，大概有八个核心模块：用户认证模块、房源管理模块、预约看房模块、合同管理模块、账单支付模块、退租流程模块、数据统计模块、系统管理模块。这八个模块覆盖了房屋租赁业务的主干链路，也足够支撑起一篇上万字的毕业论文。

模块划分这件事，我的建议是“宁多勿少、边界清晰”。多一个模块，论文里就多一条需求分析的描述、多一张页面截图、多一段功能测试记录，这些全是论文的工作量来源。但要注意边界要清晰，不要让模块之间相互纠缠，比如“预约看房”和“合同管理”就得严格分开，哪怕业务上两者是有先后关系的，代码实现上也要保证各自的 Controller 只负责自己的事。

2. 数据库设计与核心表结构

2.1 从业务需求推导数据表，而不是倒过来

很多同学拿到选题第一件事就是打开 Navicat 建表，建着建着发现字段不够用，又回头去加。这种“先射箭后画靶”的做法看起来很高效，实际上后患无穷。正确的顺序应该先是把 1.3 节里那八个模块的业务流程走一遍，把每一步涉及的数据对象列出来，然后再进行数据库建模。

我来演示一下这个推导过程。就拿“租客预约看房”这个场景来说：租客看到了一个房源，想约时间看房，那我们需要知道“哪个租客”约的“哪个房源”、“约的什么时间”、“什么状态”（待确认、已确认、已取消）。这就能推导出一张预约表，字段至少包含：appointment_id、tenant_id、house_id、appointment_time、status、create_time。其他模块按照同样的思路去拆，最后把表结构梳理出来。

核心数据表我大致列一下：用户表（user）、角色表（role）、用户角色关联表（user_role）、房源信息表（house）、房源图片表（house_image）、预约看房表（appointment）、租赁合同表（contract）、账单表（bill）、支付记录表（payment）、公告表（notice）。如果还想要做收藏功能，就再加一张收藏表（favorite）。这个规模对于毕业设计来说刚好，不多不少。

2.2 关键表结构的字段设计与关联关系

你在论文里展示数据库设计时，评委通常会关注三件事：主键设计是否合理、外键关联是否清晰、关键字段的类型选择是否有依据。我挑几张核心表仔细说一下。

用户表 user 的字段设计如下：id 用自增主键，username 存用户名并加唯一索引，password 存 BCrypt 加密后的密文（绝对不要存明文，这是答辩时能加分的细节），real_name 存真实姓名，phone 存手机号，email 存邮箱，status 用 0 和 1 表示禁用和正常，create_time 和 update_time 用 datetime 类型。别小看这些字段，它们就是 HR 面项目经验时问你“有没有做过用户模块”的底气。

房源表 house 要复杂一些。除了基本的标题、描述、租金、面积、户型、朝向之外，我建议一定要有：province、city、district、address 这四个地址字段，不要混在一个字段里，因为后续你大概率需要按城市或区域来筛选房源——这也是论文里“多条件组合查询”功能的基础。另外加一个 publisher_id 指向房东用户 ID，一个 status 字段表示待审核、已上架、已下架、已租出这些状态。cover_image 存封面图 URL，detail_images 可以用 JSON 字符串或单独建表存储，但单独建表在论文里更写得出东西。

合同表 contract 是核心业务表，字段至少包含：contract_no（合同编号，用 UUID 或业务规则生成）、house_id、tenant_id、landlord_id、start_date、end_date、monthly_rent、deposit（押金）、status（生效中、已到期、已解除）、sign_time。这里要注意，合同金额字段用 decimal(10,2) 而不是 float，因为浮点数在计算时会有精度问题，做账单核算时容易出错。这个细节写进论文的数据设计说明里，显得很专业。

2.3 权限模型：最简单的 RBAC 方案

很多毕业设计在“权限管理”这块做得非常糊弄，要么是用户表里加一个 role 字段区分角色就完事，要么是搞了一堆复杂的 Shiro 配置结果自己也讲不清楚。这两种情况在答辩时都很危险——前者显得太简单，后者一问细节就露馅。

我推荐最简单的 RBAC 模型：用户表、角色表、用户角色关联表，再加 Spring Security 或拦截器做接口权限控制。角色就三种：管理员、房东、租客，在角色表里初始化三条数据。用户登录后，查询出用户的角色标识，后端接口用 @PreAuthorize("hasRole('ADMIN')") 之类的注解控制访问权限，前端根据角色动态渲染菜单。

不要在这个模块上过度设计。如果导师没有明确要求做细粒度的权限控制（比如每个按钮的权限），就保持“角色到接口”这个粒度。因为做细粒度权限意味着要设计权限表、角色权限关联表、前端按钮级指令，工作量会翻一倍，而答辩时评委大概率只关心你能不能讲清楚访问控制的基本思路。

3. 核心功能实现与关键代码

3.1 从零到一跑通 Spring Boot 项目骨架

这部分我直接给你一套可操作的步骤，按照顺序执行，十分钟内可以跑起来一个带数据库连接的 Spring Boot 项目。

第一步，打开 IntelliJ IDEA，用 Spring Initializr 创建项目。Group 填 com.example，Artifact 填 rental-management，Java 版本选 8 或 11，依赖搜索添加 Spring Web、MyBatis Framework、MySQL Driver、Lombok。特别注意，如果你的 Spring Boot 是 2.7.x，MyBatis 的 starter 要用 mybatis-spring-boot-starter 版本 2.2.x；如果你是手动到 Maven 仓库搜的，别选成 3.x 的。

第二步，配置 application.yml。这是一个几乎所有新手都会懵的文件，我贴一个最小可用的配置：

yaml复制server:
  port: 8080

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/rental_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false
    username: root
    password: 你自己的密码
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: Asia/Shanghai

mybatis:
  mapper-locations: classpath:mapper/*.xml
  type-aliases-package: com.example.rental.entity
  configuration:
    map-underscore-to-camel-case: true

这里重点说一下 map-underscore-to-camel-case 这个配置。数据库字段通常叫 create_time，Java 实体类属性通常叫 createTime，如果不开启这个驼峰映射，你查出来的 create_time 字段就赋不到 createTime 属性上，返回给前端就是 null。这个配置每学期能坑掉无数人。

第三步，写一个测试用的 Controller 验证项目能跑通，然后 mvn spring-boot:run 启动，浏览器打开 http://localhost:8080，能看到响应就说明骨架没问题。万事开头难，跑到这一步，你的毕业设计进度已经完成五分之一了。

3.2 登录鉴权与 JWT 的实现思路

登录模块是整个系统的门面，也是答辩时评委大概率会问的模块。我的实现方案是：Spring Boot 后端用 JWT 生成令牌，前端把令牌存在本地，每次请求在请求头里带上 Authorization: Bearer <token>，后端用拦截器校验令牌。

JWT 的核心思路其实很简单：用户登录成功后，服务器把用户 ID、用户名、角色等信息加密进一个字符串里返回给前端。前端之后每次请求都带上这个字符串，后端校验这个字符串是合法的，就认为是这个用户。不需要在服务端存储会话信息，这对于前后端分离架构特别合适，也让论文里能写出一段像模像样的“无状态认证设计”。

我建议不要从零手写 JWT 工具类，直接引入 jjwt 依赖。具体的实现逻辑是：登录接口接收用户名和密码，用 BCryptPasswordEncoder 校验密码，成功后生成 token 并返回。写一个拦截器实现 HandlerInterceptor，在 preHandle 方法里解析 token，解析失败就返回 401。然后在 WebMvcConfigurer 里注册这个拦截器，并配置放行路径，比如 /api/auth/login、/api/house/list 这些不需要登录就能访问的接口。

关于登录加密，我再强调一遍：密码必须用 BCrypt，不要用 MD5。这是一个看起来很不起眼但答辩时很容易被追问的点。MD5 现在可以用彩虹表轻松逆向，而 BCrypt 每次加密都会加盐，同样的密码两次加密产生的结果都不同，安全性要高得多。Spring Security 的 BCryptPasswordEncoder 直接用就行，不用引入整套 Spring Security 那套复杂的过滤链。

3.3 房东发布房源与多条件检索的实现

房源发布功能看起来就是一个表单提交，但要做到“能写进论文”的程度，需要加入几个细节。首先是图片上传，我的建议是使用本地存储方案，在项目根目录建一个 upload 文件夹，用 MultipartFile.transferTo() 把上传的图片保存到磁盘，然后通过一个资源映射配置把 /upload/** 映射到本地路径。这个方案不需要配置阿里云 OSS，论文里也能写一句“为了避免依赖外部云服务，本系统采用本地文件存储方案”来表明你思考过这个问题。

检索功能是房源模块里技术含量最高的部分。你需要实现：按城市、区域筛选，按租金范围筛选，按户型筛选，按关键词模糊搜索，以及按发布时间排序。用 MyBatis 动态 SQL 来实现，核心的 XML 大概长这样：

xml复制<select id="searchHouses" resultType="com.example.rental.entity.House">
    SELECT * FROM house
    <where>
        <if test="city != null and city != ''">
            AND city = #{city}
        </if>
        <if test="district != null and district != ''">
            AND district = #{district}
        </if>
        <if test="minPrice != null">
            AND rent >= #{minPrice}
        </if>
        <if test="maxPrice != null">
            AND rent &lt;= #{maxPrice}
        </if>
        <if test="keyword != null and keyword != ''">
            AND title LIKE CONCAT('%', #{keyword}, '%')
        </if>
    </where>
    ORDER BY create_time DESC
</select>

这段 SQL 的巧妙之处在于，<where> 标签会自动去掉第一个多余的和 AND，所以不管你传不传条件、传几个条件，拼接出来的 SQL 都是合法的。这就是 MyBatis 动态 SQL 的魅力，也是你论文里可以着重写一段的“高性能、灵活化查询设计”。加上分页插件 PageHelper 之后，前端就可以传 pageNum 和 pageSize 实现分页，接口返回的格式统一封装成 { code: 0, msg: "操作成功", data: { list: [], total: 100 } }，前端拿到之后直接渲染表格和分页器。

3.4 订单与合同状态流转的实现细节

合同管理是房屋租赁系统业务逻辑最重的模块，也是最容易写出“高级感”的地方。核心在于状态流转。一个合同从创建到结束，至少要经历：待签署、生效中、已到期、已解除这四个状态。

我们可以用一个 status 字段来维护状态，但更规范的做法是引入状态机思想，在代码层面对状态迁移做约束。比如，只有“待签署”的合同才能被签署变成“生效中”，只有“生效中”的合同才能被解除变成“已解除”，某些状态不能跳转。实现起来也简单，在合同 Service 里做一个状态判断：

java复制public Result signContract(Long contractId, Long userId) {
    Contract contract = contractMapper.selectById(contractId);
    if (contract == null) {
        return Result.error("合同不存在");
    }
    if (!contract.getStatus().equals(ContractStatus.PENDING_SIGN)) {
        return Result.error("当前状态不能签署合同");
    }
    // 业务校验：只有租客本人能签署
    if (!contract.getTenantId().equals(userId)) {
        return Result.error("无权操作此合同");
    }
    contract.setStatus(ContractStatus.ACTIVE);
    contract.setSignTime(new Date());
    contractMapper.updateById(contract);
    return Result.success();
}

这里有两个隐藏的业务细节值得提一下，写在论文里非常加分。第一，签署生效后，要将关联房源的状态从“已上架”改为“已租出”，避免同一个房源被重复租赁。第二，合同生效后，要自动生成一条初始账单（首月租金 + 押金），供租客去支付。这两个细节体现了业务闭环思维，评委一听就知道你真正理解了这个系统。

3.5 数据统计模块与图表展示

数据统计模块是让系统“看起来完整”的点睛之笔。不用做得特别复杂，三个统计图就够：近半年房源发布数量趋势（折线图）、各区域房源分布情况（饼图）、每月租金收入统计（柱状图）。

后端实现套路是写一个统计 Controller，查询时用 MySQL 的日期函数和分组汇总。查询每月租金收入的 SQL 大概是：

sql复制SELECT DATE_FORMAT(create_time, '%Y-%m') AS month, SUM(amount) AS total
FROM bill
WHERE status = 1 AND pay_status = 1
GROUP BY DATE_FORMAT(create_time, '%Y-%m')
ORDER BY month DESC
LIMIT 12

前端图表我推荐使用 ECharts，引入方式非常简单，npm install echarts 之后，在 Vue 组件里 import * as echarts from 'echarts'，初始化一个 DOM 容器就能画图。前端的折线图、饼图、柱状图都有现成的官方示例，改一改数据源就行。这部分工作量不大，但放在系统首页里视觉效果非常出彩，也让论文里的“系统测试与展示”章节有素材可用。

4. 论文与开题报告的撰写思路

4.1 开题报告：把技术路线讲明白，重点写可行性分析

开题报告是很多人的心理负担，但其实它有固定的套路。核心内容就四块：选题背景与研究意义、国内外研究现状、研究内容和目标、技术路线和可行性分析。

选题背景和意义，你围绕“传统租房信息不透明、租房流程繁琐、中介费高”来写就行，再结合一下互联网+的背景，两三段话搞定。国内外研究现状，去知网搜个十来篇相关文献，每篇用一两句话概括一下。这部分我建议你认真写，因为导师和评审往往最先看这里，而且查重时的重复率也主要靠这里控制，建议用自己的话转述文献观点。

技术路线和可行性分析是开题报告中最容易拉开差距的部分。不要只写“本系统采用 Spring Boot 和 Vue 开发”，要写出递进层次：先说明开源框架成熟，社区生态完善，接着说明开发环境简单，只需要 JDK、Maven、MySQL 和 IDEA，最后说明自身具备 Java 基础和数据库基础。三段论述下来，可行性分析就饱满了。

4.2 论文结构：从选题到测试，每一章写多少内容

毕业论文的结构虽然学校之间有小差异，但大框架基本一致。我建议选择这种结构：第一章绪论，第二章相关技术介绍，第三章需求分析，第四章系统设计，第五章系统实现，第六章系统测试，第七章总结与展望。

相关技术介绍这章最容易写，Spring Boot、Vue、MyBatis、MySQL、JWT 各写一段，把核心特性和选择理由说清楚就能凑到三四千字。需求分析这章要画用例图和用例描述表，把每个角色的每个用例写清楚。系统设计这章内容最多，包含系统架构图、功能模块图、数据库 E-R 图、数据表结构、接口设计，每一块都值得展开细致描述，其中数据库表的字段设计最好用表格形式画出来，评审老师最喜欢看这种清晰的表格。系统实现这章需要提供核心代码片段和页面截图，页面截图一定要截图之后留出足够时间处理，建议做完整后再统一截，不要边做边截。

4.3 让论文查重顺利通过的写作技巧

毕业设计论文最头疼的问题通常是查重率。我要特别提醒：不要最后写完再查重，而是每写完一章就放进查重软件里看一眼。等到最后统一查，如果重复率太高，你会面临大面积重写的痛苦。

具体技巧有几个。第一，不要大段复制别人的文献综述，别人的话用自己的语言重新表达。第二，描述技术特性时，尽量结合你自己的项目语境来写，比如写 Spring Boot 特性时可以穿插一句“在本系统中，Spring Boot 的自动装配机制使得项目配置从原先的数页 XML 简化到仅需几行 YAML 配置”，这种和项目结合紧密的表述天然不容易重复。第三，代码片段不算重复率，但也别贴太多，论文是写给人看的，不是代码仓库，一段贴关键逻辑，其余用文字描述即可。

4.4 论文中的图表：三种图帮你撑起页面

论文插图是评阅老师的第一印象。我建议确保论文中出现三种图：系统功能结构图、系统架构图、数据库 E-R 图，最好还有每个核心模块的流程图和页面原型图。

功能结构图用 Visio 或 ProcessOn 画，就是一棵树形结构：系统分为管理员端和用户端，下面再分各功能模块，清晰明白。系统架构图画成分层结构，从上到下是 Vue 前端、Spring Boot 后端、MySQL 数据库，中间标出 HTTP 请求和 MyBatis 交互，这样能直观体现前后端分离架构。E-R 图画法有讲究，实体用矩形、属性用椭圆、关系用菱形，画的时候不需要把每个字段都标出来，标出关键字段即可，否则图会显得非常拥挤。

页面原型图一般来说可以在系统实现完成后，直接截取真实运行界面，效果往往比提前画的线框图更好。截图记得去掉地址栏和无关桌面元素，保证界面整洁，这也是职业素养的体现。

5. 常见问题与排查技巧实录

5.1 Spring Boot 环境相关的坑

这部分我把我见过的、以及自己在实操中踩过的坑集中整理成一张速查表，每一届学生都会在这里栽跟头，你留着备查。

这里我重点说一下跨域问题。Spring Boot 写一个配置类就能解决，代码如下：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("http://localhost:5173")
                .allowedMethods("GET", "POST", "PUT", "DELETE")
                .allowedHeaders("*")
                .allowCredentials(true);
    }
}

注意 allowedOrigins 要填前端实际运行的地址。Vue 项目默认跑在 5173 端口（Vite）或 8080 端口（Vue CLI），很容易搞混，填错了就会一直跨域报错找不到原因。

5.2 前端联调时常见的协作问题

前后端联调是毕业设计中最折磨人的阶段，但绝大多数问题都集中在少数几个点上。第一个是接口返回格式不统一，有时后端返回 { code: 0, data: ... }，有时又直接返回一个数组，导致前端处理逻辑要写一堆判断。解决办法是在后端定义一个统一的响应类 Result，所有接口的返回值都用它包装，用静态方法 Result.success(data) 和 Result.error("错误信息") 来构造。

第二个是字段名不一致问题。后端实体类用驼峰命名，前端 JS 用驼峰命名，理论上没问题，但如果你在哪条 SQL 上忘了开驼峰映射，返回的 JSON 就会变成下划线风格，前端调试时一脸懵。建议排查顺序是：先看后端接口返回的原始 JSON，再决定是修后端还是改前端。

第三个问题是日期时间格式不统一。后端返回 2025-04-01T10:30:00，前端想显示 2025-04-01 10:30:00。解决办法是在 application.yml 里配置 spring.jackson.date-format 和 time-zone，这样整项目的日期格式就统一了。这个配置一加上，前端就少写很多格式化逻辑。

5.3 数据一致性和并发问题：答辩加分的进阶点

如果你的系统已经能跑通，想再提升一个档次，就要关注数据一致性。房源被两个租客同时下单，会造成“一房两租”的问题，这是面试官或评委最喜欢的追问点。

解决办法是在业务层加锁或事务控制。一个简单可靠的方式是使用数据库的乐观锁，在 house 表中加一个 version 字段，更新房源状态时先比较版本号，如果版本号不一致就说明数据被其他人改过了，本次操作失败。用 MyBatis 实现的话，在更新 SQL 里加上 AND version = #{version}，更新成功后 version 自增。这个方法简单、可靠，而且实现细节能写一小段在论文里，绝对是加分项。

另外，账单支付模块要注意事务问题。支付成功后要同时更新账单状态、生成支付记录、更新合同中的已支付金额，这三步必须放在同一个事务里。在 Spring Boot 中，直接在 Service 方法上加 @Transactional 注解即可。但如果支付逻辑涉及本地事务和外部 API，复杂程度会上升，建议演示时用一个模拟支付按钮即可，避免接真实支付接口给自己找不必要的麻烦。真实支付需要商户号、证书、回调地址等一堆环境配置，对毕业设计来说成本太高，模拟支付完全够用。

一些事后才明白的体会

做完这个项目之后，我最大的感受是：毕业设计的难点从来不在技术，而在时间管理和需求边界控制。很多人一上来就想把功能做得很全，结果拖到最后论文没时间写、系统也没打磨好。正确的节奏应该是先把主干链路跑通，即发布房源、搜索房源、预约看房、合同签署、账单支付这五个核心流程，然后再去补管理后台、数据统计这些锦上添花的功能。

如果时间实在紧张，优先删掉的是收藏功能和公告管理，保留数据统计。因为数据统计对答辩视觉冲击力影响最大，而收藏功能只是多个表和一个按钮的事，论文里不写也完全不影响系统完整性。

最后再分享一个答辩前的小技巧：提前准备一个“演示脚本”，把每一步操作要讲什么话、要展示什么界面写在纸上，彩排至少三遍。答辩当天紧张的时候，只要照着脚本走，就不会出现“手忙脚乱找不到按钮”的情况。我自己见过太多代码写得不错但演示时卡壳的学生，那种场面非常可惜。系统做得好是基础，讲得好才是加分，这两件事都不难，但都需要足够准备。