SpringBoot+Vue大学生在线租房平台全栈实战解析

你有没有发现，最近两年“毕设级全栈项目”这个词出现频率特别高，其中基于SpringBoot+Vue的大学生在线租房平台管理系统更是常客。名字虽然长，但它做的事情很清晰——用Java+MySQL+MyBatis把后端接口撑起来，用Vue把前端页面渲染出来，最终呈现一个能看房、能收藏、能预约、能签约下单的完整业务闭环。

这个项目特别适合两类人。一类是正在准备毕业设计的学生，题目接地气，功能边界清楚，评委想找亮点也容易；另一类是刚学完基础、想练手全栈开发的初学者，数据模型设计、接口分层、前后端联调这些硬功夫，全都可以在这一套代码里练到位。把它当成一个能摆上简历的面试作品来打磨，也完全拿得出手。

这篇文章不打算只贴源码然后让你自己猜，而是按实际开发顺序把这个项目捋一遍：需求拆解、数据库设计、后端接口、前端页面、联调部署、问题排查。所有内容都是我在带这类实训项目时反复遇到过、并且认为最值得你提前知道的点，没有花架子，看完你至少能少走两三个晚上的弯路。

1. 项目整体拆解：这个租房平台到底在解决什么问题

1.1 需求从哪来：先搞清楚系统要服务谁

做系统最忌讳一上来就写代码。你至少要先把“谁在用、用在哪里、解决什么问题”这三点想明白，后面所有表结构、接口、页面才不会跑偏。

大学生在线租房平台的业务背景很典型：大学生在校外租房，身边并没有一个集中、可信的房源信息渠道；中介房源价格偏高，个人房源信息散落在各种群里，真假难辨；线下看房效率低，租约过程又没有统一记录。系统要解决的，就是把这些信息集中起来，让房源信息可查、收藏、预约看房，并在线上完成租约流程，同时给管理员一个管理入口。

从这个业务里能抽出两类核心用户：普通用户（学生）和管理员。有同学会问，要不要单独拆一个“房东”角色？我的建议是，毕设项目第一次做的时候，可以把房东和管理员合并。租客端由普通用户操作，房源发布、审核、上下架和租约管理都交给管理员处理。这样角色边界清晰，代码量可控，等基础功能全部跑通之后，再扩展独立的房东端也不迟。

梳理下来，核心业务闭环是这样的：

1. 管理员录入或导入房源，审核后上架；
2. 学生在列表页按区域、价格、户型、整租/合租条件筛选房源；
3. 学生对感兴趣的房源收藏，或提交预约看房申请；
4. 线下看房满意后，学生创建租约，系统记录租期、租金、押金；
5. 管理员在后台查看租约状态，处理到期、退租。

这个闭环一旦理清楚，项目范围就锁死了。你再去对照网上各种“完整源码”目录，会发现万变不离其宗，核心都在这条线上。

1.2 技术选型：为什么偏偏是SpringBoot+Vue+MyBatis+MySQL

技术栈不是我随意拍脑袋定的，它几乎就是这类管理系统的标准答案，每一项都有它的位置。

SpringBoot负责后端基础框架。它内嵌Tomcat，自动配置多，不用像传统Spring那样写大量XML配置，这对实训阶段的学生特别友好。项目里用到的依赖无非是spring-boot-starter-web、MyBatis整合包、MySQL驱动、Lombok，一个起步依赖能省掉一大堆版本管理的事情。

Vue负责前端页面。尤其是房源列表、详情页、后台管理这种中后台与前端展示混合的场景，Vue的双向绑定和组件化让数据刷新、筛选条件联动变得很自然。配合Element UI或Element Plus这种现成的组件库，后台表格、弹窗、表单半天就能搭起来，比传统JSP或模板引擎的方案现代得多，也好改得多。

MySQL负责数据持久化。轻量、免费、资料多，从安装到SQL语法，几乎每个坑都能搜到解决方案。对毕设演示和本地开发来说，MySQL是性价比最高的选择。

MyBatis负责数据访问层。你可能听过很多人推荐MyBatis-Plus，确实更省事，但底层项目用原生MyBatis更能体现水平。它对SQL掌控力更强，多表联查、动态条件筛选、分页这些面试官常问的点，都藏在XML映射文件里。面试时你能把一条联表SQL的逻辑讲明白，比只会调框架API要有说服力得多。

1.3 功能模块怎么切：一页纸说清系统边界

功能模块建议按业务域划分，而不是按页面划分。我在设计时一般会切成六大块：

每个模块内部再拆分接口，接口设计放在后面聊。切分模块的时候有一个原则：宁可在初期把模块边界放宽一点，也不要一开始就把一个模块拆得细碎，否则联调阶段接口对不上，改起来非常痛苦。

2. 数据库设计：几张表撑起整个租房业务

2.1 核心表结构：用户、房源、收藏、预约、租约

数据库是这个项目的地基。我见过太多同学源码能跑通、但被面试官一问“为什么这么建表”就卡壳，就是因为表设计时没有想清楚字段来源和关联关系。整个系统本质上就是五张核心表：用户表、房源表、收藏表、预约看房表、租约表。

用户表是最基础的，主键用自增id就行，用户名要加唯一索引。密码字段长度要预留足够，因为存的是加密后的字符串，不是明文。角色字段用TINYINT表示，0是普通用户，1是管理员，扩展方便，也省空间。

CREATE TABLE `user` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键', `username` VARCHAR(50) NOT NULL COMMENT '用户名', `password` VARCHAR(100) NOT NULL COMMENT '加密后密码', `role` TINYINT DEFAULT 0 COMMENT '0普通用户 1管理员', `phone` VARCHAR(20) DEFAULT NULL COMMENT '联系电话', `email` VARCHAR(50) DEFAULT NULL COMMENT '邮箱', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '注册时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

房源表是业务核心，字段比较多，我单独强调几个字段的设计理由。价格字段建议用DECIMAL(10,2)而不是FLOAT，租金涉及金额，FLOAT的精度问题在后期统计时会暴露。区域字段用VARCHAR存“徐汇区”“大学城”这类文本值，比外键关联地区表更简单直接，对毕设项目足够了。房源的审核状态status字段非常重要，一套完整的房源生命周期是：0待审核、1已上架、2已下架，这个状态贯穿前后端所有逻辑。

CREATE TABLE `house` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '房源ID', `title` VARCHAR(100) NOT NULL COMMENT '房源标题', `area` VARCHAR(50) DEFAULT NULL COMMENT '所在区域', `address` VARCHAR(200) DEFAULT NULL COMMENT '详细地址', `price` DECIMAL(10,2) NOT NULL COMMENT '月租金', `house_type` VARCHAR(20) DEFAULT NULL COMMENT '户型：一室一厅/两室一厅', `rent_type` TINYINT DEFAULT 0 COMMENT '0整租 1合租', `image_url` VARCHAR(500) DEFAULT NULL COMMENT '封面图地址', `description` TEXT COMMENT '房源描述', `status` TINYINT DEFAULT 0 COMMENT '0待审核 1上架 2下架', `landlord_id` BIGINT NOT NULL COMMENT '发布人ID', `click_count` INT DEFAULT 0 COMMENT '点击量', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='房源表';

收藏表、预约表、租约表结构都比较直观。收藏表要关注业务约束：同一个用户对同一个房源只能收藏一次，所以建议建一个(user_id, house_id)唯一索引。预约表需要记录预约看房时间和状态。租约表注意一个细节：表名尽量不要叫order，因为ORDER是SQL关键字，容易在写原生SQL时踩坑，用contract_rental或house_contract更稳妥。

2.2 字段与状态设计的几个准则

建表时最容易犯的错，是把所有字段都定义成VARCHAR。我在很多项目里都看到过这种写法，金额用VARCHAR，时间用VARCHAR，排序全靠字符串比较，后患无穷。

字段设计要遵守几个基本准则。一是金额用DECIMAL，日期用DATETIME，数值统计用INT或BIGINT，不要让数据库帮你做不擅长的事。二是所有状态字段用TINYINT并加注释，代码里再用常量类定义对应值，避免魔法值满天飞。三是不建物理外键，虽然数据库外键能保证一致性，但对这套系统来说，逻辑外键更灵活，联表查询用SQL层面关联就够，避免了后期数据迁移时外键带来的麻烦。四是表名和字段名不要用MySQL保留字，同时建议统一使用小写下划线命名。

时间字段也是一个容易忽略的点。合理设置默认值，CREATE_TIME用DEFAULT CURRENT_TIMESTAMP，UPDATE_TIME用ON UPDATE CURRENT_TIMESTAMP，这样后端新增记录时甚至不用手动写这两个字段，自动维护。

2.3 MyBatis多表联查与分页：SQL怎么组织才不脏

后端和前端联调时，最核心的SQL集中在房源列表接口。这个列表页要展示的不只是房源表本身，还包括房东的联系电话，以及当前用户有没有收藏过这套房源。用一条SQL把这些信息全部带出来，前端就不用额外多次请求了。

我用MyBatis的XML文件来组织这条查询时，会这样写：

<select id="selectHouseList" resultMap="HouseResultMap"> SELECT h.id, h.title, h.area, h.address, h.price, h.house_type, h.rent_type, h.image_url, h.status, u.phone AS landlord_phone, CASE WHEN c.id IS NULL THEN 0 ELSE 1 END AS collected FROM house h LEFT JOIN user u ON h.landlord_id = u.id LEFT JOIN collect c ON c.house_id = h.id AND c.user_id = #{userId} <where> h.status = 1 <if test="area != null and area != ''"> AND h.area = #{area} </if> <if test="rentType != null"> AND h.rent_type = #{rentType} </if> <if test="minPrice != null"> AND h.price &gt;= #{minPrice} </if> <if test="maxPrice != null"> AND h.price &lt;= #{maxPrice} </if> <if test="keyword != null and keyword != ''"> AND (h.title LIKE CONCAT('%', #{keyword}, '%') OR h.address LIKE CONCAT('%', #{keyword}, '%')) </if> </where> ORDER BY h.create_time DESC, h.id DESC </select>

这里有两个细节值得说。第一是LEFT JOIN收藏表，而不是用子查询判断isCollect，因为这样一条SQL就能同时拿到列表数据和收藏状态，效率更高。第二是排序字段，同一秒创建的数据如果没有id做第二排序条件，分页时非常容易出现重复数据，这个坑我踩过，后面排查时看着是“概率性重复”，其实就是排序不稳定。

分页方案我建议用PageHelper。虽然手写LIMIT也不难，但PageHelper胜在改动量小，一行PageHelper.startPage(pageNum, pageSize)就能让紧随其后的SQL自动拼接分页。需要注意，PageHelper只对紧接着的那一条查询生效，所以它后面不要跟其他SQL语句。如果项目里用了聚合查询或多表联查，写分页前先确认一下SQL语句的单条边界。

3. 后端和前端：核心功能是怎么一步步实现的

3.1 SpringBoot后端分层与接口设计

后端代码我会严格按controller、service、mapper、entity四层来组织。controller层只做参数接收、调用service、返回统一结果；service层写业务规则，比如创建租约时要检查房源状态、冲突时间；mapper层直接操作数据库，通过接口加XML的方式组织SQL。

统一返回结果类Result是毕设项目常被忽略但在联调时极其关键的设计。它的结构是code、msg、data三个字段，code为200表示成功，其他值表示业务异常或系统异常。为什么不用裸返回值？因为前端axios拦截器需要统一判断业务是否成功，没有统一结构，每个接口的异常处理就乱了。

接口设计我按业务模块来划分，下面是最核心的一组：

登录认证部分，推荐用JWT而不是传统的Session，理由很实在：前端项目部署时通常会单独跑在某个端口或静态资源服务器上，和后端域名不一致，Session的跨域处理就变得麻烦，JWT的无状态特性更贴合前后端分离架构。

我简单说下实现思路。登录成功后，后端生成一个带过期时间的token返回给前端。前端把token存到localStorage。之后每次axios请求，都在拦截器里加Authorization头。后端写一个HandlerInterceptor，拦截所有需要登录的接口，校验token有效性，无效直接返回401。前端axios响应拦截器看到401，跳转登录页。

3.2 Vue前端页面与路由组织

前端环境配置是很多同学的第一个坎。Vue CLI或Vite创建项目之后，第一步是安装依赖，axios、vue-router、element-ui（或element-plus）这三件套跑不掉。安装依赖时建议用npm install而不是cnpm，虽然cnpm速度快，但容易出现node_modules里的包版本不一致，导致本地能跑、发给别人跑不起来。我遇到过太多次这样的问题，最后统一改用npm并在package.json里锁好版本，问题才消停。

前端路由我建议按页面职责来做划分。核心路由如下：

• /home：房源列表首页
• /house/:id：房源详情页
• /login：登录注册页
• /user/collect：我的收藏
• /user/contract：我的租约
• /user/appointment：我的预约
• /admin/house：后台房源管理
• /admin/contract：后台租约管理

路由配置这里有一个值得说的点：用路由懒加载按需加载页面组件。写法很简单，component写成动态import。这样首页不会一次性加载所有页面代码，首屏速度快，评审演示时也不会打开页面白屏等待半天。

前端组件的设计也有讲究。房源卡片在列表页和收藏页都可能出现，所以我会抽成一个HouseCard组件，通过props接收房源对象。组件内部预留slot插槽，插槽动态放这块卡片右上角的操作按钮。列表页传给插槽的是“收藏”按钮，后台管理页传给插槽的是“上架/下架”按钮，同一个卡片组件两处复用，代码量少、改起来也统一。这就是Vue插槽在实际业务里最常见的用途。

3.3 前后端联调：跨域、字段映射和时间格式

前后端联调是最容易让人崩溃的阶段，但问题翻来覆去就那么几个。

跨域是第一个大坑。后端跑在8080，前端devServer跑在8081，前端请求后端时浏览器会拦截跨域请求。解决办法有几种，我推荐在SpringBoot里配置一个全局CorsFilter，在配置文件层面统一允许跨域请求，避免在每个controller上写@CrossOrigin注解，那样太散、容易漏。还要注意，允许的请求头一定要包含Authorization，否则前端带token会被跨域过滤掉。这是很多同学配置了跨域却依然请求失败的原因。

字段映射问题也很常见。Java端习惯写驼峰命名userName，数据库列名是user_name，在MyBatis里如果没开启mapUnderscoreToCamelCase，查出来的字段就是null，前端拿到一堆空值也找不到原因。在application.yml里加一行配置就能解决。

mybatis: configuration: map-underscore-to-camel-case: true

时间格式是联调时另一个高频问题。Java8的LocalDateTime经过Jackson默认序列化后，输出的是数组或带T的ISO字符串，前端展示时非常费劲。我的方案是全局配置Jackson时间格式，或者直接在实体类时间字段加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")注解。注意，这种全局配置在SpringBoot里是一劳永逸的，不用每个字段都去处理。

有个联调习惯建议尽早养成：在axios封装里统一处理响应code、统一弹出异常提示，而不是每个页面单独catch处理。否则你的代码里会充满重复的try/catch，而且提示语风格还不统一，演示时很掉价。

4. 拿到完整源码之后：怎么读、怎么跑、怎么扩展

4.1 代码目录与关键文件解读

很多同学下载源码后，第一件事是直接启动，启动失败就开始焦虑。我的建议是反过来，先花半小时把目录结构读一遍，搞清楚每个文件干什么，再启动也不迟。

后端是标准的Maven结构。src/main/resources里的application.yml是配置文件，数据库连接信息、端口、MyBatis配置都在这里。另外注意一个people常常忽略的目录：src/main/resources/mapper，MyBatis的XML映射文件都躺在里面。项目里我是把mapper接口放在Java源码的mapper包里，XML放在resources/mapper下，两者通过namespace对应。文件路径如果配置错了，启动不报错，但一调用接口就会抛Invalid bound statement。

前端路由入口在src/router/index.js，全局axios实例在src/utils/request.js，页面组件统一放在src/views目录下。想看业务怎么串起来，建议按“登录 → 首页列表 → 详情 → 收藏 → 租约”这条路走一遍，每个页面文件对应一个接口调用文件，逻辑很清晰。

4.2 本地启动流程：数据库、后端、前端三件套

我按三个步骤来梳理本地启动的完整流程。

第一步，准备数据库环境。如果本机还没有MySQL，就安装一个，Windows下安装5.7或8.0都行。安装时记得选utf8mb4字符集，否则后面中文容易乱码。安装完成后，用Navicat或命令行执行项目附带的schema.sql，把库和表建好。建完表后确认一下账号密码，后面要写进application.yml。

第二步，启动后端。用IDEA打开后端工程，等待Maven把依赖下载完。修改application.yml里的数据库用户名和密码，检查端口8080有没有被占用，然后直接运行启动类。看到Spring Boot的启动日志和banner，后端就起来了。如果启动失败，先把报错日志往上翻，重点看Caused by部分，十有八九是数据库连接问题。

第三步，启动前端。用VSCode或IDEA打开前端目录，在终端执行npm install。依赖装完后执行npm run dev，控制台会输出本地访问地址，浏览器打开就行。如果后端端口改了，前端utils/request.js里的baseURL也要同步改，不然请求会全部404。

这中间最容易被忽略的一点是：后端接口能不能单独测通。我习惯在后端启动后用Postman或Apifox先测一遍登录接口，拿到token后再测其他接口。如果后端接口一个个都能返回数据，再启动前端去联调，问题定位范围会小很多。

4.3 二次开发示例：给项目加一个“合租室友匹配”功能

如果让项目在评审时多一个记忆点，可以考虑在合租场景上做扩展。大学生租房有个真实痛点：合租的人选不好找。很多项目止步于“房源展示”，没人做室友匹配，你做了就是亮点。

这个功能可以这样设计。新增一张室友需求表，学生填自己的性别、作息习惯、预算范围、期望区域、是否接受宠物，相当于一份“合租意向档案”。后端提供两个接口：一个保存意向，一个按条件匹配。匹配的逻辑是，查同区域、预算区间有交集、生活习惯标签相似的其他学生，展示在前端列表里。

房源详情页加一个“找室友”按钮，点击后跳到匹配列表页，列表卡片展示对方的预算、生活习惯标签，以及一个“联系TA”按钮。这个功能不需要改动现有核心表结构，只在原基础上加一张新表、两个新接口和一个新页面，属于典型的低成本高展示效果扩展。更重要的是，你做完这个功能后，面试时能讲一套完整的需求分析、表设计、接口实现思路，而不是只说“我抄了一套源码”。

5. 常见问题与排查实录

5.1 环境与版本类问题速查

这一类报错通常发生在项目刚拷贝到新电脑或第一次启动时。我把高频问题整理成一张表，方便你对照排查。

尤其要提醒一点，“springboot版本太高”这个问题是真实存在的。很多同学图新，一上来就选SpringBoot 3.x，结果本地JDK还是8，启动直接挂掉。不要追新，2.7.x稳定、资料多、和MyBatis整合信息丰富，对这类项目来说是最好的版本区间。

5.2 业务与联调类问题速查

版本问题过了关，接下来就是业务联调阶段的报错。有些问题的报错信息很不直观，我列几个代表性案例。

跨域报错：浏览器控制台显示blocked by CORS policy，大概率是后端CorsFilter没放行Authorization请求头，或者前端没有把请求代理到正确地址。先看浏览器Network面板，确认请求发出去了没有，再确认后端有没有处理OPTIONS预检请求。

中文乱码：后端返回给前端的数据中文正常，但登录注册后控制台打印中文变成问号。这种情况大多数是连接数据库的URL里没有指定字符集。在application.yml的jdbc url后面加上characterEncoding=utf8，同时确认项目文件编码和数据库连接都是UTF-8。

Invalid bound statement：MyBatis的XML没被加载。检查三处：@MapperScan注解扫的包路径对不对、mapper-locations配置的XML路径对不对、XML文件里namespace的接口全限定名和mapper接口对不对。这三处对应不上，项目不报错，但业务接口一调就炸。

前端拿到的时间格式很奇怪：比如“2023-08-01T10:00:00”。这是Jackson对LocalDateTime默认序列化格式导致的。加上@JsonFormat注解指定格式，复杂的就全局配置Jackson，问题就消失。

还有一个很常见的情况：vue项目源码发给别人后对方跑不起来。原因多数是node_modules在不同环境下没装全，或者package.json里的依赖版本有差异。正确做法是发送前把node_modules删掉，发送完整的前端源码和package.json，让对方重新npm install，并提醒对方固定Node版本。

5.3 演示与答辩：怎么把项目讲出水平

项目能跑只是及格，演示和答辩才是拉分项。我的个人建议是，从做完功能的那一刻开始，就把自己当成这个项目的产品经理。

第一，准备足够多的真实测试数据，不要只有三四条模拟数据。房源至少造十套，覆盖不同区域、不同价位、不同租期，筛选条件才会真正生效，演示时不会显得空。第二，录制一个两分半的演示视频，按完整业务流程走一遍：登录、搜索、看详情、收藏、预约、创建租约、后台管理。万一现场演示出问题，视频能兜底。第三，准备几个“为什么”问题的回答，比如为什么用MyBatis不用MyBatis-Plus，为什么设计逻辑外键，为什么租约状态用TINYINT。这些问题没有标准答案，但你必须能说出自己的理由。

最后，我想说一点关于“源码”的态度。网上完整的项目源码很多，下载、改个logo、跑起来，这不算做完一个项目。真正值得做的是拿到源码后，把核心表结构重新画一遍，把接口文档重新梳理一遍，然后选一个功能点从零写一次。比如收藏功能，表设计到接口再到前端按钮，整个链路自己敲一遍，你在这个项目里学到的东西就真正属于你了。

我在实际带项目时还有个习惯，供你参考：所有时间字段，后端统一返回标准字符串，前端统一用日期格式化库做展示，两边约定好一种格式，绝不在某个页面单独写格式化逻辑。看起来是小事，但联调时能省掉非常多来回沟通的成本。另外一个可做的个性化增强是，用在线工具给SpringBoot定制一个专属启动banner，启动时显示项目名和版本号，评审现场启动后小小展示一下，细节上的用心很容易被注意到。

这个项目后续还可以继续扩展的方向也很多。比如把当前管理员的房源发布独立成房东端，加入地图定位选房，或者把租约到期自动续租提醒做成定时任务。改造的点都在现有业务线上，不会让你推倒重来。你只要把一个闭环吃透，后面的路会越走越顺。