SpringBoot+Vue房屋交易系统：前后端分离毕设全栈实现与避坑指南

拿到这套 SpringBoot+Vue 的房屋交易系统完整源码时，我第一反应不是急着部署，而是先花半小时把目录结构和核心数据表捋了一遍。这类项目在Java Web毕设里太常见了，但“常见”不代表“简单”，真正把它从能跑通的Demo做成一个经得起答辩追问的完整系统，中间隔着一堆容易忽略的坑：数据表怎么设计才不冗余、图片上传后为什么刷新页面就没了、前端代理跨域怎么配、接口文档和实际返回对不上怎么办。如果你正在做毕设或者想系统地学一遍前后端分离开发，这篇内容值得你泡杯茶慢慢看。

这个项目本质上是一个“前端Vue全家桶 + 后端SpringBoot单体服务 + MySQL持久化”的全栈练习，麻雀虽小，但五脏俱全。它涵盖了管理员、房东/中介、购房者三类用户，包含了房屋发布、图片存储、条件检索、收藏预约、后台管理等一条完整业务链路，适合三种人：一是正在准备毕业设计、需要完整参考实现的学生；二是想从零开始体验真实前后端分离项目开发流程的初学者；三是想找一套基础代码做二次开发，比如换成租房平台或二手车交易平台的开发者。我后面所有讲解都基于“能跑起来、能答上问题、能改得动”这三个目标来展开。

1. 项目整体解读与业务架构设计

1.1 用户角色与核心业务链路

很多同学拿到这类项目会直接启动数据库、跑后端、开前端，结果界面出来了却不知道自己在看什么。我建议你先搞清楚角色和业务链路再动手，因为面试或答辩时最容易被追问的就是“你这个系统有哪些角色，各自能做什么”。

房屋交易系统里最常见的角色划分是三段式：管理员负责整体运营治理，包括用户审核、房屋信息审核上下架、公告发布、基础数据统计；发布方（房东或中介）负责录入房屋信息、管理自己的房源上下架、查看预约记录；购房者或租客负责浏览房源、按条件筛选、收藏心仪房屋、预约看房、提交留言咨询。

从用户出发，核心业务链路是“找房-看房-约房-咨询-成交/管理”。找房对应首页关键词检索和区域价格筛选，看房对应房屋详情页里的轮播图和配套设施展示，约房对应预约看房表单，咨询对应留言模块，成交或管理对应后台的房源状态流转。毕设项目里可以把线下签约和真实支付省略掉，但预约和收藏这两个“意向动作”必须有，否则这个系统只剩一个信息展示壳子，业务上说不通。

1.2 数据表设计与关联关系

数据库是这个项目最值得花时间的地方。我见过太多毕设项目把房屋信息的配套字段全部塞在一张表里，导致后期维护非常痛苦。稍微靠谱一点的设计，通常会把核心表和辅助表分离。

从功能反推数据表，至少需要六张基础表：

• 用户表：用户ID、用户名、密码、手机号、邮箱、头像、角色标识、注册时间。密码必须加密存储，不能搞明文。
• 房屋表：房屋ID、标题、所属区域、详细地址、面积、户型、朝向、楼层、装修标准、售价/租金、房屋描述、封面图、状态字段、发布时间、发布人ID。这里是核心业务表，字段要多预留几个可扩展位，比如是否电梯房、是否近地铁。
• 房屋图片表：图片ID、房屋ID、图片路径、排序字段。房屋和图片是典型的一对多关系，必须拆表，否则一个房源十几张图会把主表撑爆。
• 收藏表：收藏ID、用户ID、房屋ID、收藏时间。用户和房屋是多对多，通过收藏表关联。
• 预约看房表：预约ID、房屋ID、用户ID、预约时间、联系人、联系电话、状态字段（待确认/已完成/已取消）。
• 公告表：公告ID、标题、内容、发布时间，由管理员维护。

表结构设计里有几个细节值得展开。第一，房屋状态字段建议用int而不是varchar，0下架、1在售、2已租售、3审核中，后端用常量类去约束，比直接存中文靠谱得多，也方便做批量更新。第二，区域字段不要存零散字符串，尽量存储统一编码或固定枚举值，比如“01-02”代表“某市-某区”，前端联动省市区选择器会省很多事。第三，价格字段用decimal而不是float，避免精度丢失。第四，在设计外键时要克制，物理外键能不用就不用，改成逻辑关联，否则后期写删除和更新业务的SQL会让你痛不欲生。

2. 核心功能拆解：从用户浏览到管理员后台

2.1 房屋发布与图片上传存储

房屋发布是系统的核心输入操作，也是前后端交互最复杂的环节，没有之一。前端需要一次提交房屋基本信息和多张图片，后端要确保房屋信息写入主表、图片路径写入子表，整个操作保持事务一致性。

先说图片上传。实战中有两条路：本地磁盘存储路径，或者对象存储/云存储。毕设项目建议选本地存储，毕竟不需要引入云服务依赖，也方便演示。前端用ElementUI的Upload组件配多图上传，action指向后端接口/api/house/upload，上传成功后拿到图片ID和URL，再连同表单数据一起提交。

这里有个高频坑点：很多同学在房屋提交后才去上传图片，导致图片上传接口和房屋ID对不上。正确思路是在发布房屋时，先把图片传到临时目录，返回图片URL；然后提交房屋主表数据，拿到房屋ID；最后把图片记录写入房屋图片表，关联上房屋ID。如果想偷懒，也可以前端把图片Base64编码直接塞进表单，但这种做法会让请求体大好几倍，体验和性能双输，不建议学。

后端接收图片的核心代码逻辑大概是：

@PostMapping("/upload") public Result<String> upload(@RequestParam("file") MultipartFile file) { // 1. 校验文件类型和后缀，只看contentType不可靠 // 2. 生成唯一文件名：时间戳 + UUID片段 + 原始后缀 // 3. 写入本地磁盘指定目录，如 /files/house/ // 4. 返回可访问的URL路径，如 http://localhost:8080/files/house/xxx.jpg }

实现时要注意：文件名必须处理，不要用用户原始文件名，否则重名覆盖、中文乱码、路径穿越各种问题都会找上门。我用的是System.currentTimeMillis() + UUID.randomUUID().toString().substring(0, 6)拼接后缀的方案，够用，也不会重复。

2.2 条件检索与分页排序

房屋列表页通常会提供几个筛选条件：关键词、区域、户型、价格区间、朝向、是否在售。如果你一个个拼接SQL语句，会写得又臭又长。合理做法是前端只负责传条件对象，后端用MyBatis-Plus的LambdaQueryWrapper动态构造查询。

价格区间这种条件，前端传minPrice和maxPrice，后端判断，如果有值就ge或le拼接。关键词搜索一般针对标题和地址字段做模糊匹配，用like处理，但要注意数据库层面和请求层面的中文编码。分页建议用MyBatis-Plus内置的Page插件，写起来简单，性能也过得去。

排序方面，用户最关心的是“最新发布”和“价格从低到高”，SQL里对应order by create_time desc和order by price asc。前端排序字段切换并重新请求列表时，后端要防止SQL注入，不能直接拼接列名。稳妥做法是用一个白名单映射，只允许前端传createTime、price、area这些已知字段进去。

2.3 收藏、预约与消息联动

收藏和预约是交易系统里体现“行为数据”的关键模块，也是最容易用户交互出错的环节。收藏的SQL很简单，插入一条关联记录再页面更新个高亮状态就行，但要注意重复收藏的问题：用户重复点击按钮会导致数据库里出现多条同用户同房屋的收藏记录。实战中要么加唯一联合索引，要么在查询时先判断是否已收藏，二选一。我倾向于两者都做，前端置灰已收藏按钮，后端同样用selectCount做兜底判断。

预约看房看起来只是提交一个表单，但设计时要想清楚状态怎么流转。用户在详情页提交预约，状态初始为待确认；房东或管理员后台查看预约列表，可以进行确认或标记完成。这个流程里，短信/邮件通知在毕设阶段可以不做，但如果想加分，可以加一个简单的系统站内消息表，把预约成功和确认结果推送给用户，体现业务闭环。

2.4 系统管理后台权限控制

后台权限是所有管理者功能的基础。虽然不需要做到Spring Security加多级角色颗粒度控制那么重，但至少得区分管理员和普通用户。我建议用拦截器或过滤器配合JWT来实现登录态校验和角色拦截，理由后面会细说。

后台管理页面的操作要兜底，尤其是管理员对房源强制下架、删除用户恶意留言这类操作，后端接口必须二次校验管理员角色，不能只靠前端把按钮藏起来。权限校验没做好的项目，前端只要用控制台手动调一下接口就能把所有房源下架了，这在答辩现场是非常尴尬的演示事故。

3. 技术栈选型与开发环境搭建

3.1 为什么是SpringBoot+Vue这套组合

就毕设场景而言，SpringBoot调低了SSH时期繁琐的XML配置成本，内嵌Tomcat让打jar包直接运行变得很轻松；Vue配合ElementUI或Ant Design Vue能快速做出还算体面的后台界面，学习曲线也相对平缓。这个组合在今天几乎是全栈类项目的事实标准，教程多、踩坑方案齐全、面试官认得出来，选它不会出错。

反过来说，如果纯玩后端用Thymeleaf模板渲染，也可以，但页面观感和前后端分离的体验就差很多；如果前端换了React，问题也不大，但意味着学习成本和找参考的难度都会增加。在实际答辩场景里，SpringBoot+Vue这套组合基本是“安全牌”，不会因为技术选型被质疑。

3.2 本地环境准备与目录结构规划

在跑项目之前，我强烈建议先检查本机环境，避免后续排错怀疑人生。需要准备的东西包括JDK 8或11（和pom.xml里指定的版本对应）、Maven 3.6以上、MySQL 5.7或8.x、Node.js 14以上、npm或pnpm、IDEA或Eclipse（推荐IDEA，自带HTTP Client和数据库插件）。准备好这些之后再打开源码。

整个工程一般是前后端分目录：后端springboot-house-backend，前端vue-house-frontend，也有项目是混合放一个目录。拿到手先别急着启动，第一步是git init或者直接复制成新目录，防止原项目里的target目录和node_modules残留。然后在IDEA里以Maven项目导入后端，在VS Code或IDEA中打开前端目录。

3.3 数据库导入与配置修改

这套项目自带的SQL脚本一般是house.db.sql或init.sql，属于手工初始化的数据集。导入时要注意：先仔细检查MySQL的字符集设置，如果你的数据库默认不是utf8mb4，导入中文数据后大概率会变成乱码。我的习惯是在执行SQL脚本之前先执行一句：

set names utf8mb4;

然后在Navicat或命令行里选择对应数据库导入。导入之后，打开后端application.yml，检查数据库用户名、密码、URL端口号是否匹配。有一个经典问题是你本机数据库密码和脚本开发者不一致，不改配置就会一直报Access denied for user，这其实是90%的“项目跑不起来”问题的来源。

同时还要检查前端代理配置。Vue项目的vue.config.js里通常配了：

devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这里的target地址必须和后端实际启动端口一致。很多项目后端是8080，前端自己跑在8081，而代理配成了9090之类，接口全部404。

3.4 接口文档的正确用法

这是我接收这套源码时重点看的东西。接口文档不一定全是Swagger在线文档，也可能是Word或Markdown文件，它描述的是每个API的请求方式、路径、参数、返回结构。但文档不会自动更新，代码一旦改动，文档可能就滞后了。所以你的正确打开方式是：文档当引导，真正确认以代码里的Controller和实际调试器返回为准。

建议你在启动项目后，把接口文档里的关键接口逐一和Postman或Apifox里的请求结果比对一遍。房屋列表接口、图片上传接口、登录接口、预约接口这四条是最核心的，必须全部过一遍。如果你的项目集成了knife4j或Swagger页面，直接在浏览器访问/doc.html就能看到在线调试界面，那是非常方便的联调工具。

4. 实操过程与关键代码实现

4.1 后端分层设计与核心实现

后端代码一般按Controller、Service、Mapper三层组织。Controller只做参数接收和结果返回，Service层承载业务逻辑，Mapper处理SQL持久化。我看到过不少项目的Service层又臭又长，这其实是正常的，因为业务集中在那里。

以用户登录为例，正常流程是这样：Controller接收用户名密码，Service调用Mapper查用户记录，密码用BCrypt或MD5加盐比对，成功之后生成JWT返回前端，前端把它存到localStorage或sessionStorage。后续请求在请求头带上Authorization: token，后端用拦截器统一校验。这里有个容易被追问的细节：为什么用JWT而不用Session？核心原因是前端项目和后端项目分离部署，Session默认依赖同域下的Cookie，跨域环境下处理起来麻烦；JWT是无状态认证，后端不需要保存会话数据，服务器重启也不会掉登录态，对水平扩展也友好。但代价是JWT签发后不好主动吊销，一般靠短期有效时间来控制。

核心示例片段：

public Result<UserVO> login(LoginDTO dto) { // 1. 根据用户名查用户 User user = userMapper.selectOne( new LambdaQueryWrapper<User>() .eq(User::getUsername, dto.getUsername())); if (user == null) { return Result.error("用户名不存在"); } // 2. 校验密码（BCrypt匹配） if (!BCrypt.checkpw(dto.getPassword(), user.getPassword())) { return Result.error("密码错误"); } // 3. 生成JWT，注意放用户ID和角色 String token = JwtUtil.generateToken(user.getId(), user.getRole()); return Result.success(new UserVO(user, token)); }

注意编码规范：DTO负责接收前端参数，VO负责返回给前端数据，Entity只对应数据库表结构。很多新手直接在Controller层返回Entity，多表关联查询时就会碰到字段外露、字段冗余的问题。分清楚这三层，代码会清晰不少。

4.2 前端页面与数据交互实现

Vue项目中将API请求统一封装到src/api/目录，是提高可维护性的关键做法。

// src/api/house.js import request from '@/utils/request' export function getHouseList(params) { return request({ url: '/house/list', method: 'get', params }) } export function publishHouse(data) { return request({ url: '/house/publish', method: 'post', data }) }

所有请求都走同一个实例，后续如果想统一处理登录失效、统一返回错误提示、自动携带Token，只需要改一个文件。在Axios的拦截器里，可以自动读取localStorage中的Token并加到请求头，省得每个接口重复写。

列表页渲染是另一个重点。ElementUI的Table组件配列模板和分页组件，让getHouseList({ page, size, keyword })的返回值来驱动页面更新。需要注意：接口返回的数据结构要和你页面里写的字段名完全一致，比较常见的坑是后端VO里把字段命名为houseId，前端模板里写的是id，结果表格一整列空白，检查半天才发现是对不上号。

4.3 跨域处理实操方案

前后端分离项目必然要处理跨域，常见有两条路：后端开启全局CORS，或者前端开发环境用代理转发。毕设项目我建议双保险都做，以备不同场景。

后端用配置类统一处理：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

前端配置vue.config.js代理。注意后端如果同时开启了CORS和拦截器，会遇到一个很隐蔽的问题：浏览器在真正请求前会先发一个OPTIONS预检请求，这个请求没有Authorization头。如果你的拦截器把OPTIONS请求也拦截了，会导致真正的请求被浏览器判定为失败。解决办法是拦截器里直接放行OPTIONS方法：

if ("OPTIONS".equalsIgnoreCase(request.getMethod())) { return true; }

这个坑，网上能搜到一堆人在问，但真正提前预防的很少。

4.4 前后端联调完整链路演示

我以“用户发布一套房屋”为例，把完整链路过一遍，你会发现联调的本质是在理顺数据和接口之间的“默契”。

前端表单包含基本信息区和图片上传区。用户选择户型、填写面积价格，同时选择多张图片，点击上传按钮触发/api/house/upload，后端把图片存到本地目录并返回图片URL。前端把URL收集到一个数组里。用户点击“发布”，前端调/api/house/publish，请求体是：

{ "title": "某小区两室一厅", "area": 88.5, "price": 1650000, "district": "01-02", "cover": "http://localhost:8080/files/house/xxx.jpg", "images": ["http://localhost:8080/files/house/xxx.jpg", "..."], "description": "精装修，近地铁" }

后端Service层拿到数据后，先插入房屋主记录获取自增ID，再循环插入图片子表，事务提交。此时房屋状态默认为在售。用户端列表页重新请求最新列表，就会发现新发布的房源已经出现在第一页。这套链路通了，整个项目的核心就算真正掌握了。

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

5.1 高频报错速查表

5.2 几个值得分享的避坑心得

第一，静态资源映射一定要做。如果你把图片存到了本地磁盘，但后端没配静态资源映射，图片URL返回了却无法访问。SpringBoot里加一个配置：

@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/files/**") .addResourceLocations("file:" + uploadPath + "/"); }

这个配置加好后，浏览器才能通过URL访问磁盘图片。这是本地存储方案里最容易忽略的“最后一公里”。

第二，数据库字段命名和前端字段命名要保持一致习惯。Java里是驼峰命名createTime，MySQL里常见的是下划线create_time，需要开启MyBatis的地图自动下划线转驼峰配置。如果配置没开，查到的时间字段映射不上，前端拿到createTime就是null或直接缺失。很多列表页日期列显示为空，就是这里出了问题。

第三，SQL脚本里的初始数据不要去手动改。我见过有人为了看起来符合自己地区，把初始SQL里的所有房屋地址批量改了，结果把一处外键关联改断了，导致详情页打开报错、后台删除失败，折腾了一整天才定位到是数据问题。想换数据，直接在后台界面手动添加几条新的就好，不建议动初始化脚本的原始数据。

第四，上线或演示前的收尾习惯。项目能跑起来之后，不少同学会忽略一件事：在演示当天，数据库里的图片路径、被修改过的数据、控制台里随时蹦出来的红色异常。一个稳妥的做法是演示前重新导入一次SQL脚本，恢复一个干净的初始数据环境，然后基本功能全流程走一遍，做好记录。课题演示翻车绝大多数不是功能不在了，而是环境状态太乱。

6. 项目交付物与二次开发扩展方向

6.1 源码、SQL脚本与接口文档的配合关系

这套项目交付物包含三块：Java源码、SQL脚本、接口文档。三者的关系可以用一句话概括：SQL脚本定义数据容器，Java源码实现业务逻辑，接口文档描述两者之间的交互协议。

在实际使用中，我的建议是把接口文档当成一个活文档来维护。每当你修改了后端接口路径或参数，顺手在文档里更新，否则几周后你自己翻文档都会怀疑自己写没写过这个接口。如果你的项目集成了Swagger注解，还能自动生成在线接口文档，但对结构要求较高，具体的业务逻辑还是要靠自己在接口语义上定清楚。

6.2 毕设答辩加分扩展点

如果时间充裕，这套系统有几个性价比很高的扩展方向。一是增加一个简单的看房订单流程，从预约状态流转到经纪人或房东确认，再流转到完成，把线下交易过程在系统里形成闭环；二是把收藏模块升级为“心愿清单”，增加批量备注和推荐排序；三是加一个基于地区、价格、户型统计的后台图表页面，用ECharts展示房源分布；四是对图片上传做压缩和水印处理，避免用户上传超大图拖慢页面。

每加一个功能都是在给答辩内容增加讲述素材。不过要稳住核心，不要为了扩展而扩展。赢得评委认可的主要方式，还是把“房屋发布-检索-收藏-预约-后台管理”这条关键链路讲通、跑顺、经得起追问。

我在实际跑这批代码时的体会是：真正拉开差距的地方往往不在于写了多少炫酷代码，而在于把每个基础功能闭环做扎实。前后端分离项目的联调过程会逼着你思考数据从哪来、到哪去、中间经过哪些校验，这套房屋交易系统正好覆盖了这些核心知识点。把这套东西吃透，你不仅应付得了眼前的项目周期，也顺手把企业里常见Web应用的开发套路摸了个大概其。等你再回头去看别的项目源码时，会发现上手速度快了不止一个档次。