企业官网建设流程全解析

当你在毕业设计选题列表里看到「大学生在线租房平台」这六个字时，大概率已经在心里给它贴上了"老掉牙"的标签。毕竟租房系统、二手交易系统、校园论坛这类题目，确实是每一届都会出现的"常青树"。但如果你把视角切换到答辩组老师的立场去看，这个题目恰恰是少数几个能同时覆盖Java后端、前端框架、数据库设计、权限控制、文件上传、订单状态流转这些高频考点的项目，而且业务场景贴近真实生活，本科生完全有能力独立讲清楚。用SpringBoot+Vue做这套系统，本质上是把"学生信息管理"和"房源信息管理"两套核心逻辑揉在一起，正适合拿来检验两学年积累的Java基础和前端基本功。

我是从去年秋天开始带几个学弟学妹做这套系统的，前后拆过三版代码，也帮人排查过不少运行不起来的问题。这篇文章不打算贴完整源码——那种几千行代码粘进来的做法对你没有任何帮助，真正值钱的是你想明白为什么这样设计表结构、为什么把某个接口拆成两个、为什么前端要加一道路由守卫。读完这篇文章，你能得到一张完整的地图：从数据库表设计、后端接口规划、前端页面划分、常见坑位处理到答辩准备，每一段都是可以被实现的。

1. 为什么"在线租房平台"是毕设里的稳妥之选——先想清楚题目背后的考察逻辑

1.1 这个题目到底考了你什么

不要小看"租房平台"四个字。把它拆开，它至少包含三个最基础但最重要的模块：

第一是用户系统。学生、房东、管理员三种角色，涉及注册、登录、信息修改、密码重置、权限拦截。这一块考的是你对认证和授权的理解，以及SpringBoot拦截器或Spring Security的基础用法。

第二是房源系统。房源发布、编辑、上下架、审核、多条件搜索、分页展示、图片上传。这块是整个项目工程量最大的部分，也是最能体现CRUD功底的地方。很多同学的问题恰恰出在这里——以为CRUD很简单，但真正把"上架中、已出租、已下架、待审核"这几种状态用字段干净地表达到位，还需要花点心思。

第三是订单与租赁流程。用户浏览房源、收藏、发起租赁申请、房东处理、生成订单/合同、确认入住，这个流程涉及多个表的数据变更，是考察事务边界的最佳场景。

把这三块做扎实，整个项目在答辩时就能形成一条完整的叙事线：谁在使用系统、数据从哪里来、经过了哪些状态、最终落到了哪张表。这套逻辑比单纯做一个"增删改查管理系统"要完整得多，又不会像推荐系统、秒杀系统那样复杂到超出本科答辩的接受范围。

1.2 适合什么样的人选这个题

有几个信号可以帮你判断自己适不适合选这个课题：Java基础刚学完SpringBoot，能写Controller和Mapper，但没做过完整前端；或者你前端Vue用了半年，但对Java后端的了解只停留在"能跑起来"；再或者你在校时间比较紧，想选一个资料多、参考多、独立能啃下来的题目。

如果你属于上述任何一种，这个题目都比较友好。它不像人脸识别那样依赖第三方SDK，也不像电商秒杀那样需要Redis消息队列，更不依赖硬件环境。一套JDK、一个IDEA、一个MySQL、一个Node环境就能跑完整个开发周期。哪怕你是从零开始抄一套代码，花两天把Er图和数据字典啃完，也能在答辩时讲得头头是道。最重要的是——这套系统的业务链条足够完整，能有真实的使用价值，课程答辩和毕业答辩都站得住。

1.3 别把"适合毕设"理解为"简单到没有深度"

也得提醒一句：这类题目虽然入门容易，但如果只是把别人的源码下下来换个名字交上去，答辩时被问到"订单状态是谁触发的""为什么用JWT不用Session""多条件查询的SQL是怎么拼接的"，大概率会卡壳。深度恰恰在细节里——如何设计房源表的状态字段，如何在用户下单时防止同一个房源被两个人同时租走，如何让房东端和学生端共用一套登录逻辑但看到不同菜单。以下每个章节，我都会围绕这些细节展开。

2. 技术选型的账要算清：SpringBoot、Vue、MySQL各自承担什么

2.1 后端为什么是SpringBoot而不是SSH、SSM

很多教程还在讲SSM（Spring+SpringMVC+MyBatis）整合，但那是五年前的主流。现在的SpringBoot对新手最大的价值是：把大部分配置从XML文件里解放出来，自动装配开箱即用。你写一个房源查询接口，只需要Controller、Service、Mapper三层的Java类加一个注解，不用再手工维护bean的XML配置。对于毕设这种规模的项目，SpringBoot的starter机制能让你把80%精力放在业务代码而不是环境配置上。

SpringBoot 2.7.x搭配JDK 1.8是目前最常见也最稳定的组合。为什么要强调这个组合？因为SpringBoot 3.x起强制要求JDK 17，而很多学校的课程和教材仍基于JDK 8，一旦本地环境装的是JDK1.8，用SpringBoot3.0会直接启动报错。开发调试阶段用IDEA自带的Maven插件，打包用mvn clean package，这一步是基本功，后面部署章节还会细说。

2.2 前端用Vue2还是Vue3，这是个现实问题

我这里直接给结论：如果你是照着某套开源毕设代码改，看看它用的是Vue2还是Vue3再做决定。Vue2搭配Element UI是最经典、最不容易出错的组合，网上随手一搜都是对应的教程和源码。Vue3搭配Element Plus更现代，但对没接触过Composition API的同学来说，上手成本会高一些。

如果你完全自己从零写前端，我给你一个保守建议：用Vue2 + Element UI + Vue Router + Vuex。理由有三条：一是Element UI的表格、表单、分页组件拿来即用，能快速搭出后台管理界面；二是Vue2的Options API（data/methods/computed）更接近传统JavaScript思维，比Composition API好理解；三是Vue2版本的教程数量庞大，遇到问题基本一搜就有答案。等你把这套系统的前端逻辑摸透了，再去学Vue3的setup语法也不迟。

2.3 MySQL在这里到底要建几张表

MySQL在整个项目里承担的是数据持久化，核心表满打满算也就六到八张：用户表、角色表（也可以用字段类型代替）、房源表、房源图片表、收藏表、租赁订单表、评论表、公告表。表与表之间的关系相当典型：用户与房源是一对多，房源与图片是一对多，用户与收藏是多对多，订单关联用户与房源。

典型归典型，但不代表随手建就行。字段类型、默认值、唯一索引、联合索引这些设计决策，直接决定你后端的SQL好不好写。下一章我专门展开讲。

2.4 环境版本匹配清单——这步错了后面处处是坑

整理一份我实际用下来的版本组合，照抄即可：

这里最容易踩的坑有两个：一是Node版本过高（比如18、20），跑老项目的npm install会报opensslErrorStack，方案是降低Node版本或设置legacy-provider；二是MySQL8.0的驱动类名从com.mysql.jdbc.Driver变成了com.mysql.cj.jdbc.Driver，连接串里还要加serverTimezone=Asia/Shanghai，否则会报时区错误。这些细节在启动时总会浪费新手一两个小时。

3. 数据库设计是整个项目的地基——从需求倒推表结构

3.1 三种用户角色怎么建模：角色表还是字段枚举

最直观的方案是建一张角色表，用户表里存role_id外键。这符合"正规设计"，但放在毕设项目里也可以简化——因为系统就只有固定三种角色，用一个role字段（比如0-学生、1-房东、2-管理员）就能满足需求。

我的建议是：按毕设的体量走字段枚举，但要在论文里写清楚为什么可以这样简化。答辩时这句话很加分，说明你分析过角色系统的复杂度，不是无脑建表。实际登录后判断角色的逻辑也更简单：前端根据登录接口返回的role值渲染不同菜单，后端在拦截器里检查请求路径前缀和role是否匹配。

3.2 核心表的数据字典拆解

这里只挑最重要的三张表展开，其余表可以照此思路推演。

第一张是用户表，字段至少包括：id、username、password、real_name、phone、role、create_time。密码一定要存加密后的密文，用MD5加盐或BCrypt都行。我推荐Spring Security里常用的BCryptPasswordEncoder，虽然加密速度慢一点，但安全性更好，毕设论文里也能写一句"采用BCrypt加密存储用户密码"。

第二张是房源表，这是整张数据库的关键。字段建议：id、landlord_id（关联用户表）、title、description、price（月租，用decimal类型）、area（面积）、address、room_type（整租/合租/单间）、status（0待审核、1上架中、2已出租、3已下架）、is_deleted、create_time、update_time。status字段是房源生命周期管理的核心，要求按状态过滤展示时，SQL就是一个简单的WHERE status = ?。

第三张是订单表，关联用户和房源：id、student_id、house_id、owner_id、status（0待房东确认、1已确认待入住、2已入住、3已退租、4已取消）、rent_time、expire_time、create_time。为什么要冗余一个owner_id（房东ID）？因为订单列表页查询时经常需要同时显示房源信息和房东联系方式，冗余存下来能减少一次关联查询。这张表是后端事务的演练场，后面讲下单接口时你会看到它的价值。

3.3 外键、索引和逻辑删除的取舍

老派教材会要求必须写外键约束，但真实项目里外键反而是累赘——它会影响插入性能，也会让删除操作变得麻烦。很多生产环境都选择在业务层维护引用完整性，只建立逻辑关联，不建立物理外键。毕设层面你可以两者之间选一个方案：如果论文里强调"数据库设计遵守范式且使用外键约束保证完整性"，那就加物理外键；如果你想让自己写SQL时更自由，可以在设计文档里说明"为了业务扩展和性能考虑未设置物理外键，而是使用逻辑外键+应用层校验"。

索引方面不要贪多，对毕设来说两三组就够：用户表的username建唯一索引（登录查询需要）、房源表的status和create_time建联合索引（列表页按状态和最新时间筛选常用）、订单表的student_id建普通索引（个人租房记录查询）。is_deleted字段是全表都加的软删除标记，查询时统一过滤is_deleted=0，这样用户误操作删除房源后还能恢复，也方便答辩时演示"数据没有物理丢失"。

4. 后端核心模块的落地——从登录鉴权到一条完整的租房流程

4.1 登录鉴权：JWT还是Session，别被教程带偏

Session的传统做法是在服务器内存里保存登录态，客户端通过Cookie携带sessionId。但在前后端分离的项目里，Cookie跨域处理麻烦，而且后端如果做集群部署，Session同步也是问题。JWT（JSON Web Token）的优点是服务端无状态：登录成功后把用户id和角色加密成一个token串返回给前端，前端每次请求放在Header的Authorization里，后端拦截器解析token即可。

在毕设项目里，我不建议你直接引入Spring Security全家桶——它的过滤器链机制对新手来说是个黑盒。更合适的做法是：写一个拦截器（HandlerInterceptor），在preHandle里检查请求头token，解析是否过期、是否合法，然后放行。大约八十行代码就能搞定，而且答辩时能讲得非常清楚。具体代码逻辑如下：

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (request.getMethod().equals("OPTIONS")) { return true; // 跨域预检请求直接放行 } String token = request.getHeader("Authorization"); if (token == null || token.isEmpty()) { throw new RuntimeException("未登录"); } // 解析token，得到userId和role，放入request域 Claims claims = JwtUtil.parseToken(token.replace("Bearer ", "")); request.setAttribute("userId", claims.get("userId")); request.setAttribute("role", claims.get("role")); return true; } }

拦截器注册进WebMvcConfig时需要指定拦截路径与放行路径：登录、注册、首页房源列表和详情可以放行，其余接口一律拦截。这样既保证游客能浏览房源，又保证发布房源、下单、审核等操作必须是登录用户。

4.2 登录接口和权限控制的细节

写登录接口时容易忽略三个点。一是登录成功后除了返回token，一定要把用户名和role一起返回，前端才能决定跳转到哪个页面。二是用户状态校验，比如被管理员封禁的用户不能登录。三是密码加密的校验方式——BCrypt的matches(原始密码, 加密密文)方法才是正确用法，而不是把加密后的密文再加密一次对比。

权限控制在Service层做一层就够了。比如修改房源信息、下架房源，Service层先判断当前userId是否等于该房源的landlord_id，不是就抛出异常。管理员审核房源，判断角色是否为管理员。这种逐接口的判断比全局拦截更灵活，也更好讲清楚颗粒度。

4.3 多条件查询与分页：关键SQL长什么样

房源列表页的搜索条件通常有：关键词（标题/地址模糊查询）、户型（整租/合租/单间）、价格区间、发布时间排序。用MyBatis-Plus可以这样写：

LambdaQueryWrapper<House> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(House::getStatus, 1); // 只查上架中 wrapper.and(w -> w.like(House::getTitle, keyword).or().like(House::getAddress, keyword)); wrapper.eq(StringUtils.hasText(houseType), House::getRoomType, houseType); wrapper.between(priceMin != null && priceMax != null, House::getPrice, priceMin, priceMax); wrapper.orderByDesc(House::getCreateTime); Page<House> page = houseMapper.selectPage(new Page<>(current, size), wrapper);

如果不用MyBatis-Plus，手写XML时就是把上面的条件拼到<where>标签里，注意每个条件都要判空。分页用PageHelper插件或者MySQL的LIMIT ? OFFSET ?都行。这里有个阅卷老师爱问的点：LIMIT的offset是不是传什么就用什么？答案是否定的，必须用(current - 1) * size换算，前端页码从1开始，数据库偏移量从0开始。

4.4 图片上传：本地存储的取舍与实现

房源需要有实拍图片，通常的做法是前端用Element UI的Upload组件把文件上传到后端接口，后端存到服务器的某个磁盘目录，再把访问路径存数据库。以本地存储为例，最简实现如下：

@PostMapping("/upload") public Result upload(@RequestParam("file") MultipartFile file) { if (file.isEmpty()) { return Result.error("请选择文件"); } String originalFilename = file.getOriginalFilename(); String suffix = originalFilename.substring(originalFilename.lastIndexOf(".")); String fileName = UUID.randomUUID() + suffix; String dir = System.getProperty("user.dir") + "/upload/"; File folder = new File(dir); if (!folder.exists()) { folder.mkdirs(); } file.transferTo(new File(dir + fileName)); return Result.success("/upload/" + fileName); }

这个方案的工作量最小，适合课程设计和毕业设计。要留心两点：一是把上传目录放到项目运行目录下的/upload中，而不是写死绝对路径，否则部署到服务器上会找不到路径；二是在WebMvcConfig中需要配置虚拟路径映射，把/upload/**指向实际磁盘路径，这样浏览器才能直接通过URL访问图片。SpringBoot的配置：

registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + System.getProperty("user.dir") + "/upload/");

4.5 下单与状态流转：事务的边界到底画在哪里

下单这个动作，用户的视角是：对某套房源点"申请入住"，填写预计入住时间和租期，提交。后端的视角是：先在订单表插入一条status为0的记录，然后把房源表这个房源的status从1改成2（已出租），同时要保证这两步要么都成功，要么都失败——否则会出现订单生成了，房源却还是可租状态，或者房源被标记出租了，订单却没生成。

用@Transactional注解方法即可。我更想强调的是，为什么要把"写订单"和"改房源状态"放进同一个事务。你可以这样理解：数据库的一致性要求每一笔订单都必须对应一个真实可租的房源。如果在并发场景下两个学生同时申请同一间房，会出现两个订单都对同一个房源写入的情况。要避免这个问题，除了事务还需要加锁——最简单的是在房源表上加一个version字段做乐观锁，更新时检查version是否变过。毕设项目并发量通常不会很高，但把这个方案写进论文的"系统优化"部分，能帮你抬高一个层次。

订单状态流转建议保持简单：0待房东确认 -> 1已确认待入住 -> 2已入住 -> 3已退租。房东确认、学生取消、管理员查看全部门店订单，这几个接口的核心逻辑都是对status字段做条件更新。特别要注意，取消订单时如果房源还是"已出租"状态，要把它改回"上架中"，这时候又要涉及事务。开个玩笑说，你得习惯事务在这个系统里随处可见。

5. 前端Vue层——页面、路由和状态管理的实际安排

5.1 页面结构拆分：一个平台的前端到底该有哪些页面

按用户视角来分，前端可以拆成三大块。

第一块是C端（学生用户）：注册登录页、首页房源列表、房源详情页、下单页、个人中心（我的订单、我的收藏、个人资料）。这几页是整个系统的门面，界面设计要相对用心，房源卡片、轮播图、价格标签这些组件都是加分项。

第二块是B端（房东端）：我的房源管理（发布、编辑、上下架）、租客订单处理（查看申请、确认/拒绝）。房东端页面可以复用C端的组件，只是菜单不同。

第三块是管理后台：用户管理（禁用/解禁用户）、房源审核（通过/驳回）、公告管理、统计概览（按房源数量、订单数量、用户数量做几个简单的卡片统计）。

页面数量不算多，但每页之间通过路由串联起来后，整个结构就清晰了。建议前端路由用懒加载方式引入组件，这样首页加载时不会一次性加载全部页面文件，答辩演示时切换页面也更流畅。

5.2 axios封装与跨域问题的双保险

前后端分离开发最大的坑是跨域。前端的域名是localhost:8080，后端的接口是localhost:9090，浏览器默认拒绝跨域请求。解决思路通常有两个，后端加CORS配置，前端通过代理转发。

后端CORS配置在SpringBoot里就是实现一个WebMvcConfigurer，把允许的源、方法、请求头都放行。前端开发模式下用Vue CLI的vue.config.js配置代理：

module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:9090', changeOrigin: true, pathRewrite: { '^/api': '' } } } } };

这样一来，前端所有请求都写/api/xxx，开发环境会转给后端，生产环境则通过Nginx将/api前缀反代到后端服务。pathRewrite的作用是方便后端接口不用改，而前端保持统一前缀。这个配置在部署时同样适用，记得在Nginx里配好。

axios封装则是另一个容易被忽略的点。你想一下，如果每个页面都直接写axios.get，一旦后端返回code=401表示token过期，你要在每个请求失败的回调里单独处理，显然会写大量重复代码。合理的封装是统一用拦截器：

service.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = 'Bearer ' + token; } return config; }); service.interceptors.response.use(res => { if (res.data.code === 401) { localStorage.removeItem('token'); router.push('/login'); } return res.data; });

5.3 路由守卫怎样配合后端做权限控制

后端有拦截器，前端还要不要做权限控制？答案是当然要。后端拦截是底线，前端拦截是体验。如果学生用户能直接输入/admin/users的地址进入管理页，即便后端会拦截，但页面先报错，体验就很糟糕。

前端做法是：在路由表里给每个路由配置meta.role，然后在router.beforeEach里检查：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); if (to.meta.requiresAuth && !token) { next('/login'); return; } const role = localStorage.getItem('role'); if (to.meta.role && to.meta.role !== role) { next('/403'); return; } next(); });

这段代码不必写成守卫也能实现，但写成守卫后，所有页面的访问控制都收敛在一处。尤其适合在答辩时讲"我是如何用单一入口控制权限分级"。

5.4 Element UI里的几个高频组件怎么用

整体开发会大量依赖Element UI，这里列几个常用的场景。el-table用于订单列表和管理员管理房源列表，配合el-tag显示状态颜色，配合el-pagination做分页，事件绑定current-change让页码变化触发重新拉取数据。el-form用于注册和房源发布，字段校验规则写在rules里就能实现必填与格式校验。el-cascader或者el-select用于城市/区域选择，做房源地址录入时比较自然。

要提醒一个细节：el-table的data数组里的状态字段要转换成文本显示，最好用计算属性或写一个过滤器，例如：

formatStatus(row) { const map = { 0: '待审核', 1: '上架中', 2: '已出租', 3: '已下架' }; return map[row.status] || '未知'; }

不要把这段逻辑直接塞进模板里的三元表达式，那样模板会变得很乱，也是代码风格扣分项。

6. 踩坑实录——从身边人辛酸史里提炼出的九条经验

6.1 前后端联调时的JSON时间格式问题

Java后端默认序列化LocalDateTime会输出一串带T的格式，比如2025-06-01T10:20:30，前端控件直接显示会很难看，而且Element UI的日期选择组件解析这种格式偶尔会出问题。处理方式是在application.yml里配置全局时间格式：

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

如果仍然不行，就在字段上加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")。时间相关bug最讨厌的点是本地没问题、部署上服务器后时间差8小时，多半是时区没配成Asia/Shanghai，连接串和Jackson配置两处都要检查。

6.2 后端接收前端传参时的三种典型不匹配

前端传对象、后端用实体类接收，字段名不一致会全部为null；前端传数组、后端用String接收会报类型转换异常；前端传的时间字符串、后端用LocalDateTime接收可能因为格式不对解析失败。遇到这些问题的排查顺序是：先看Network面板里请求体长什么样，再看Controller参数有没有@RequestBody注解，最后看字段类型。不要一上来就怀疑SpringBoot环境坏了，大部分接口404和参数错误都是这些细节。

6.3 文件上传一直是报404或大小超限的排查链路

如果你上传图片后访问URL一直404，排查链路按三步走：第一步，打开浏览器直接访问localhost:9090/upload/xxx.png，看是否能看到图片。能看见，说明后端虚拟路径映射已生效，问题出在前端代理配置没把图片请求也代理过去。第二步，如果访问不了，检查WebMvcConfig里addResourceHandler的路径是否写成了/upload/**。第三步，检查上传文件的大小限制，SpringBoot默认最大只允许1MB，超过就会报MultipartException。配置如下：

spring: servlet: multipart: max-file-size: 10MB max-request-size: 10MB

6.4 数据库连接被切断、中文乱码和自增主键被中断

开发时数据库连不上，先重启MySQL，再看连接串的serverTimezone，最后检查驱动依赖是否缺失。中文乱码则检查三处：数据库表的字符集是不是utf8mb4、连接串有没有characterEncoding=utf8、页面文件存的是不是UTF-8编码。这三处没问题，乱码基本不可能出现。自增主键被中断通常是因为米删除了一些中间数据，不影响功能，但如果论文里的数据字典展示了自增ID，最好重置一下或不要展示所有ID。

系统时常出现Too many connections的问题，排查时先用show processlist;看看连接堆积，之后在数据源配置里加上maximum-pool-size: 10。这些看似不起眼的配置，实际上控制着程序的稳定性，答辩的时候随口提一句"我配置了数据库连接池的最大连接数"，老师会认为你有生产意识。

7. 部署上线与答辩准备的完整链路

7.1 本地打包与服务器部署：两种路线怎么选

本地演示和交给老师验收，通常分两种部署方式。

第一种是双端打包。前端用npm run build生成dist目录，后端用mvn clean package生成jar包。然后有两种放法：要么前端dist文件放进后端的static目录下，再启动jar包，访问同一个端口即同时完成前后端服务，很简单；要么后端jar包和前端dist目录分开，用Nginx做静态资源服务和接口反向代理。对毕设来说，把dist复制到SpringBoot的resources/static下是最保险的方式，不用处理Nginx配置，也避免了跨域，我喜欢叫它"单端口部署"。

第二种是Docker容器化。写一个简单的Dockerfile把jar打包成镜像，再用docker-compose同时编排MySQL容器和SpringBoot容器。这个方案适合时间充裕、想给答辩增加亮点的同学。但注意，Docker方式会引入网络配置、数据卷管理等额外知识点，如果你自己都搞不清楚原理，答辩时被追问容易露馅。

7.2 答辩演示脚本怎么准备：从首页到订单，一条路走完

答辩演示时最忌讳的是把所有页面都点一遍——时间不够，也没有重点。建议走一条闭环流程：注册一个学生账号，登录后搜索一个条件（比如"整租 800-1500元"），打开详情页收藏房源，发起租赁申请；切换到房东账号，在订单列表里看到这条申请并确认；再切换到管理员账号，审核房源、查看用户列表。这一条路线串起了三种角色、六张以上的数据表，能完整展示系统核心能力。

演示前一定把测试数据准备好看一点：房源图片要正常显示，价格要有梯度，状态要有变化。最尴尬的场面是老师想看"已出租房源在列表中不再出现"，结果你因为没造数据不得不现场重新租一遍。提前把状态用例造齐，该上架的、该下架的、该审核的都在数据库里备好。

7.3 论文和答辩PPT里最容易被提问的四个点

准备论文时，把这几块内容重点写透：

• ER图和数据字典：表字段含义、类型、约束、备注要完整，这是工作量证明。
• 系统架构图：Vue前端、SpringBoot后端、MySQL三层架构，标注请求走向。
• 核心功能时序图：从用户浏览到房东确认订单的完整过程。
• 关键问题解决方案：比如多条件搜索如何避免SQL注入、图片上传类型校验、JWT过期处理。

答辩老师依据经验最爱问的问题基本就四类：为什么用这种权限方案、为什么表之间不加外键、并发下怎么防止超租、数据库字段为什么这样设计。这篇文章前面都覆盖了，你只要用自己的话复述一遍，并且拿实际代码指给老师看，基本不会出问题。怕的就是项目不是自己敲的，被问到一个Service方法里从未见过的注解时只能支支吾吾。

8. 如果你想基于这套系统做二次开发，这几个方向值得考虑

到这里，核心内容已经全部说完了。最后聊一点扩展性的事——毕设做完之后，源码不应该是终点，把它改造成更有个人色彩的方向，往往反而简单。

我建议你可以从两个方向扩展。一是功能层面：加入地图选房功能，在Vue里集成地图组件，根据经纬度筛选附近房源，这会让系统看起来有现代感。或者加入在线聊天功能，学生和房东在线沟通，技术上也就是WebSocket在SpringBoot里的入门用法。二是工程层面：引入Redis缓存热门房源列表，把首页查询从每次读MySQL改成缓存热点数据；或者引入RabbitMQ处理订单创建后的延迟提醒。这些扩展每做一个，论文的"系统特色"章节就多一条硬货。

我是真心觉得，在线租房平台这个题目的上限远比很多同学想象得高。它不需要你研究复杂的算法，但逼你把一个业务闭环从数据库一路做到前端页面，再画上权限、事务、并发这几道考试必考的点。如果你现在正为了某个接口跑不通或者某个页面渲染不出来而头疼，慢慢来，按这篇文章的章节一点一点拆，大部分问题都可以定位到很小的范围。做完之后你会发现，整个Web开发的流程已经在你脑子里长出了一张完整的地图。