每年毕业季都有不少同学在选题上卡壳。问得最多的一类问题就是“有没有那种功能不算特别复杂、但又能把 SpringBoot、Vue、MySQL 全用上、好答辩的项目”实话实说房地产销售管理系统就是这类题目里性价比很高的一个它不像电商系统那样要处理复杂的支付和库存也不像办公系统那样全是流程表单它的业务链路非常清晰——从房源入库、客户登记到销售跟进、成交下单最后形成数据报表。每一步都能找到一个典型的技术落点既能把全栈技术栈串起来又不会让自己陷在业务的泥潭里出不来。这篇文章就围绕这个系统把我做同类项目的完整思路、模块设计、核心代码写法、以及一大堆实际开发中才能踩到的细节一次性拆开讲清楚。1. 房地产销售管理系统到底在管理什么——需求拆解与模块划分很多同学拿到这类题目第一反应是打开 IDEA 新建项目然后对着“房地产销售管理”六个字发呆。这是典型的顺序搞反了。不管做什么系统第一步永远是把业务语言翻译成功能清单再把功能清单翻译成数据表和数据流。房地产销售管理这个题目核心业务链路其实就一条楼盘/房源信息入库客户进来登记需求销售跟进客户达成意向后下单成交合同归档最后管理层要看销售业绩和房源去化情况。围绕这条链路系统的功能模块可以拆成下面几块房源管理楼栋、房号、户型、面积、朝向、单价、总价、销售状态待售、已预订、已签约。客户管理客户姓名、联系方式、意向户型、预算范围、意向楼盘、跟进记录。销售管理销售员信息、客户指派、销售订单、成交价、折扣审批如果要做的话。合同管理成交后的合同基本信息登记、合同状态。数据统计月度销售业绩、房源去化率、客户转化率、热门户型排行。系统管理用户登录、角色权限、密码修改、操作日志。如果是从零开始做毕设或课设我建议不要一上来就把所有模块都铺开。你要先判断自己的时间预算和答辩要求。常见的做法是做一个“基础版 加分项”的组合类型模块说明必做核心房源管理、客户管理、销售订单、用户登录保证业务闭环完整加分项数据可视化统计、Excel 导入导出、合同管理、跟进记录让系统的“管理”属性更强答辩更有话可说时间充裕再加权限精细化多角色菜单、操作日志、消息提醒偏工程实践也能体现深度我见过不少同学把大量时间花在花哨的权限模型上结果核心的销售闭环反而没做完整答辩的时候被老师一问“客户从登记到成交的流程是什么”直接卡壳。记住毕设类项目的评价标准里“业务完整度”永远大于“技术炫技度”。先把主链路跑通再考虑添砖加瓦。2. 技术选型背后的真实考量——为什么是 SpringBoot Vue MySQL这个项目标题里直接写明了技术栈但很多同学未必清楚“为什么是这三个”更不清楚版本该怎么选、ORM 用什么、需不需要引入 Redis 这类中间件。我把我自己的选型逻辑说一遍。SpringBoot 是当前 Java 后端开发的事实标准这句话不是空话。它把 Spring 庞大的配置体系收缩成了“约定优于配置”你不需要再手动写一堆 XML 配置文件Maven 引一个 starter 就能快速集成 Web、数据库、校验、测试等能力。内置 Tomcat打包后直接 java -jar 就能跑这对答辩演示环境来说特别友好。你要在一个没有 IDE 的机器上临时跑起来SpringBoot 的 jar 包形态是灾难最低的选择。Vue 的优势在于渐进式和生态。相比 ReactVue 的上手曲线更平缓对前端基础薄弱的同学来说能在比较短的时间里做出像样的页面。而且 Element Plus 或者 Element UI 这套组件库专门解决管理后台类的界面问题——表格、表单、弹窗、日期选择器、分页全都有现成组件拼装效率非常高。用 Vue 做管理平台本质上是“搭积木”而不是“写样式”。MySQL 更不用说开源免费、部署简单、JDBC 驱动成熟、网上教程最多的数据库。做 Java 毕设项目我建议你直接装 MySQL 8.x虽然老教程里很多东西都是 5.7 的写法但 8.0 的时区、认证方式等问题现在都有很成熟的解决方案了没必要故意选旧版本。选型时还有两个决定用得舒服不舒服的关键选择值得单独说。ORM 层我强烈建议用MyBatis-Plus。它在你需要手写 SQL 控制复杂查询时保留 MyBatis 的灵活性同时又能用 BaseMapper 内置的增删改查节约大量重复代码。更关键的是 LambdaQueryWrapper 这套链式写法拼条件查询特别方便后面你会看到房源列表的“按区域筛选、按价格区间筛选、按状态筛选”这种动态 SQL用 MyBatis-Plus 写起来非常舒服。前端脚手架用Vite Vue 3 Element Plus。Vite 的启动速度和热更新速度比 Vue-CLI 那套 Webpack 方案快非常多开发体验完全不一样。版本搭配上我顺手整理了一个列表给不知道怎么选版本的同学参考组件推荐版本说明JDK8 或 11用 SpringBoot 2.x 就配 JDK 8用 3.x 必须 JDK 17建议新手先用 2.7.x JDK 8 降低未知问题概率SpringBoot2.7.x稳定、教程多、兼容性最广MyBatis-Plus3.5.x当前主流版本文档全MySQL8.0安装时选 utf8mb4 字符集Node.js16.20 或 18配合 Vite 5 / 6 使用Vue3.x Vite别再用 Vue 2 了新项目直接用 Vue 3Element Plus2.x适配 Vue 3 的组件库3. 数据库表设计从房源到成交的完整数据链路数据库是这个系统里最值得多花时间的部分。我见过太多人急着写代码结果后面开发时反复改表结构甚至动到已经写好的接口非常痛苦。花一晚上把表设计好后面能省一周的事。按业务链路来拆至少要覆盖下面这些核心信息用户表sys_user这是系统登录和权限控制的基础。拿销售管理系统来说用户基本分三种超级管理员、经理、销售员。我设计了下面这个最小字段集字段名类型说明idbigint主键自增usernamevarchar(50)用户名唯一passwordvarchar(100)BCrypt 加密后的密码real_namevarchar(50)真实姓名rolevarchar(20)ADMIN / MANAGER / SALES 字符串存法简单直观phonevarchar(20)联系电话statustinyint1 启用 0 禁用create_timedatetime创建时间密码加密一定要用 BCrypt不要用 MD5。MD5 撞库太容易了答辩时老师随便问一句“你的密码是明文存的吗”就能看出你对安全有没有基本概念。Spring Security 的 BCryptPasswordEncoder 可以单独拿来用不需要引入整个 Spring Security。房源信息表house_info这是核心业务表。字段设计上要既能描述房子的物理属性又能支撑销售状态的流转。CREATE TABLE house_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 房源ID, building_no VARCHAR(50) NOT NULL COMMENT 楼栋号, unit_no VARCHAR(50) COMMENT 单元号, room_no VARCHAR(50) NOT NULL COMMENT 房号, house_type VARCHAR(50) COMMENT 户型如 3室2厅, area DECIMAL(10,2) COMMENT 建筑面积(㎡), orientation VARCHAR(20) COMMENT 朝向南北/朝南/朝北, floor_no INT COMMENT 所在楼层, total_floor INT COMMENT 总楼层, unit_price DECIMAL(10,2) COMMENT 单价, total_price DECIMAL(10,2) COMMENT 总价, decoration VARCHAR(20) COMMENT 装修情况毛坯/简装/精装, status TINYINT DEFAULT 1 COMMENT 1待售 2预订 3已签约, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );两个容易踩坑的点。一是价格字段绝对不要用 float/double 存金额浮点数二进制表示会导致金额误差用 DECIMAL(10,2) 存。二是状态字段用 TINYINT 存而不是字符串后面做查询统计时数字比字符串更高效也更容易做接口参数校验。客户信息表customer_info记录客户的基本信息和购房需求。这张表需要跟“跟进记录”配合起来看才能体现销售管理的价值。CREATE TABLE customer_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, phone VARCHAR(20) NOT NULL, gender TINYINT COMMENT 1男 0女, age INT, budget_min DECIMAL(12,2) COMMENT 预算下限, budget_max DECIMAL(12,2) COMMENT 预算上限, intention_type VARCHAR(50) COMMENT 意向户型, intention_house_id BIGINT COMMENT 意向房源ID, owner_id BIGINT COMMENT 跟进销售ID, follow_status TINYINT DEFAULT 1 COMMENT 1新客户 2跟进中 3已成交 4已流失, remark VARCHAR(500), create_time DATETIME DEFAULT CURRENT_TIMESTAMP );销售订单表sale_order订单表是连接房源、客户、销售员三个核心实体的桥梁也代表了销售的动作发生。一个订单里除了记录成交房源和成交客户还要记录成交价格、优惠金额、订单状态。另外建议加一个order_no 订单编号因为订单号在演示和交接时会频繁用到用时间戳 随机数生成即可不要用自增 ID 直接对外展示容易暴露业务量。CREATE TABLE sale_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(50) NOT NULL UNIQUE, house_id BIGINT NOT NULL, customer_id BIGINT NOT NULL, sales_id BIGINT NOT NULL COMMENT 销售员ID, final_price DECIMAL(12,2) COMMENT 成交总价, discount_amount DECIMAL(12,2) DEFAULT 0 COMMENT 优惠金额, status TINYINT DEFAULT 1 COMMENT 1已预订 2已签约 3已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );跟进记录表follow_record如果不想做这个表可以把跟进记录合并到客户表的 remark 字段里但那样客户历史跟进就丢了答辩时“我的系统没有操作审计概念”这句话说出来挺减分的。跟进记录表用customer_id、content、create_time三个核心字段就够了写起来不费事但能显著提升系统的专业感。另外建议加一张公告或新闻表可以用来做系统首页的动态信息模块这个体量小但能丰富主页面展示。Redis 和 JWT 需要引入吗这是我被问得最多的一个问题。我的建议是毕设不做 RedisToken 存内存/缓存即可或者干脆使用 JWT 无状态方案这样就不需要 Redis。理由很实在引入 Redis 意味着你要额外安装、配置、考虑缓存失效和脏数据问题而毕设场景并发量极低Redis 的优势根本发挥不出来反而徒增部署和答辩的不确定性。JWT 本身是无状态的天然适合这种场景。4. 后端接口开发的几个硬骨头——鉴权、动态查询、事务与报表后端开发的核心不是把 CRUD 写完而是把几个有代表性的“硬骨头”啃下来。把下面这几块的思路理清楚整个系统基本上就通了。4.1 登录鉴权JWT HandlerInterceptor 的最小实现登录接口的逻辑比较直接根据用户名查出用户用BCryptPasswordEncoder.matches(rawPassword, encodedPassword)比对密码通过则生成一个 JWT Token 返回前端。JWT 的生成可以用io.jsonwebtoken:jjwt库核心代码大概长这样String token Jwts.builder() .setSubject(user.getUsername()) .claim(role, user.getRole()) .claim(userId, user.getId()) .setExpiration(new Date(System.currentTimeMillis() 24 * 60 * 60 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();生成 Token 后前端把 Token 存在 localStorage 里以后每次请求都在请求头的 Authorization 字段带上Bearer token。后端用一个拦截器统一校验public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String authHeader request.getHeader(Authorization); if (authHeader null || !authHeader.startsWith(Bearer )) { throw new BusinessException(401, 未登录或Token已过期); } String token authHeader.substring(7); // 解析校验解析失败直接抛异常 Claims claims Jwts.parser().setSigningKey(secretKey).parseClaimsJws(token).getBody(); request.setAttribute(userId, claims.get(userId)); request.setAttribute(role, claims.get(role)); return true; } }然后注册进 WebMvcConfigurer把放行路径登录接口、静态资源和拦截路径除了放行路径外的所有接口配置好。 建议 /login 和 /api/common/** 放行其余 /api/** 全部拦截。前端通过路由守卫控制页面访问后端通过拦截器保证接口安全两层配合才是完整的登录校验逻辑。4.2 房源列表的动态条件查询房源列表页一定会有多个筛选项楼栋、户型、朝向、状态、价格区间。这种“条件可多可少”的查询最容易写出又臭又长的 if 拼接 SQL但 MyBatis-Plus 的 LambdaQueryWrapper 能把这个场景处理得非常优雅。Override public PageResultHouseInfoVO pageHouse(HouseQueryDTO query) { LambdaQueryWrapperHouseInfo wrapper Wrappers.lambdaQuery(); wrapper.like(StringUtils.hasText(query.getBuildingNo()), HouseInfo::getBuildingNo, query.getBuildingNo()) .eq(StringUtils.hasText(query.getHouseType()), HouseInfo::getHouseType, query.getHouseType()) .eq(StringUtils.hasText(query.getOrientation()), HouseInfo::getOrientation, query.getOrientation()) .eq(query.getStatus() ! null, HouseInfo::getStatus, query.getStatus()) .between(query.getMinPrice() ! null query.getMaxPrice() ! null, HouseInfo::getTotalPrice, query.getMinPrice(), query.getMaxPrice()) .orderByAsc(HouseInfo::getBuildingNo); PageHouseInfo page houseInfoMapper.selectPage(new Page(query.getPageNum(), query.getPageSize()), wrapper); // 转VO后返回 }写这段代码时有个非常容易被忽略的坑.between一旦最小值和最大值有一个是 null就会做全区间查询导致价格条件失效。所以我在前面加上了 min 和 max 都为非空的判断。用 LambdaQueryWrapper 的好处就是每个条件参数都可以传一个布尔值如果为 false它就不会拼进查询 SQL这样你不用手动写一堆 if-else 了。4.3 下单操作的事务与房态校验下单是整个系统里唯一需要认真考虑“事务”的地方因为同一个房源不能被两个销售员同时卖给不同客户。我建议用一个Transactional方法来实现完整的下单逻辑根据 houseId 查询房源判断状态必须为“待售”如果不是直接提示“该房源已售或预订”。把房源状态更新为“预订”通过乐观锁或者简单的状态判断 更新行数来防止并发下的超卖——MyBatis-Plus 的乐观锁插件是个很合适的方案。生成订单记录订单号为时间戳 三位随机数。这里要注意事务失效的场景必须从外部通过代理调用方法不能在同一类里 this 调用否则 Transactional 不生效。现实中我不止一次看到同学在同一个 Service 类里内部调用带事务的方法结果数据写入一半某个环节异常前面已执行的 SQL 没回滚最后表里出现脏数据。下完单后为保证一致性可以把订单表和房源表的状态变更放在同一个事务里这个逻辑也是答辩时老师最喜欢问的点“你这个订单和房源状态是怎么保证一致的”你只要答上“用了数据库事务出现异常会回滚同时更新房源状态时检查了原状态避免并发操作”这个回答在毕设答辩里就是一个很稳的分数点。4.4 数据统计与报表实现管理后台肯定要有一个 Dashboard把销售额、成交量、房源去化情况用可视化的方式展示出来。这里的核心 SQL 在Mapper层写原生语句或 XML 自定查询。例如SELECT DATE_FORMAT(create_time, %Y-%m) AS month, COUNT(*) AS order_count, SUM(final_price) AS total_amount FROM sale_order WHERE status 2 GROUP BY month ORDER BY month DESC LIMIT 12;这个查询按月份聚合订单数量对应页面上放一个柱状图来表达月度销售趋势。MyBatis-Plus 里用Select注解或者 XML 写返回 Map 的查询再转成图表需要的 JSON 数组就可以。另一个常用统计是房源去化率用“已签约房源数 / 总房源数”占比即可推出常用命名方式。ECharts 的饼图每个扇形区域就是一类状态加载数据时从后端接口取 countByStatus 的 Map 再适配数据格式即可。到这里后端的核心能力基本齐了登录鉴权、多条件查询、事务下单、统计报表。把这几块写清楚系统的主要骨架就有了说服力。5. 前端实现的思路与关键交互Vue 页面开发不能只靠“抄模板”后端接口逻辑清晰之后前端的工作量主要就集中在这几个点路由与菜单权限、组件化页面搭建、表格与弹窗交互、禁用状态处理、与后端的接口对接。路由与菜单权限的处理是第一个容易出问题的地方。最简单的做法是登录后根据用户角色在前端一次性生成菜单。前端提前维护好一份“角色 → 菜单列表”的动态路由映射表本地写好路由后再用router.addRoute()注册进去。这种方式在毕设项目中完全够用也没有任何安全风险因为后端接口依然有拦截器把关前端动态路由只是为了“显示/隐藏菜单”真正能否操作由后端校验。适配管理后台的布局结构。Vue3 Element Plus 的经典布局左侧菜单栏右侧头部 主内容区。前端组件化对这套系统几乎是“量身定制”的el-menu做左侧菜单el-table做列表页el-dialog做表单弹窗el-pagination做分页。这套组合拳下来页面功能的一致性和开发效率会非常高。我在实际做这个系统时把页面归纳成三大类列表页房源列表 / 客户列表 / 订单列表表格 顶部筛选条件 操作按钮 分页。弹窗表单页新增房源 / 新增客户 / 下单操作弹窗内编辑表单保存后调用刷新列表接口。统计展示页Dashboard 首页图表卡片组合无复杂交互。举一个典型例子。房源列表页的“筛选 表格 分页”结构每个字段都需要和查询接口的 QueryDTO 一一对应比如楼栋、户型、状态和价格区间筛选组件用了el-select、el-input、el-input-number。查询按钮触发后会重新请求house/page接口携带新的查询参数和页码。前端组件一般维护两个数据对象一个是查询表单的queryForm一个是结果集合tableData和分页pagination结构非常固定、易复用。另一个值得专门说的点是订单状态更新按钮的禁用逻辑。比如“已签约”的订单不能再次点击“签约”“已取消”的订单不允许继续操作。这些校验在后端接口也应该有防止有人直接调接口修改状态但前端也做一层状态判断一是减少接口请求二是提升用户体验。接口对接时axios 的统一封装能避免大量重复代码。我用 request.js 统一创建 axios 实例并在请求拦截器中从 localStorage 取 token添加到请求头在响应拦截器中统一处理 code ! 200 的情况弹一个 ElMessage 提示并拦截错误。这样每个页面的 request 调用代码都变得非常简短项目中不会出现每个页面各自处理 401 的情况。图表可视化用 ECharts。Vue 项目里我喜欢在mounted里初始化图表实例通过option配置项控制展示逻辑。引入 ECharts 也很简单——npm 安装 echarts在需要的组件里直接 import或者在入口文件全局注册。前端做到这里你会发现它其实是“围绕后端接口的动力模型在做组织”接口清了页面结构自然就清晰了。6. 联调、打包部署与答辩演示的细节——别让环境问题毁了整个项目很多同学项目代码写得不错一到现场演示就翻车原因基本都是环境问题。这一节把从本地联调到最终演示的完整链路整理一遍。本地联调阶段最常见的问题是跨域。前端在 Vite 配置里加一个 proxy 代理把/api开头的请求代理到后端端口一举解决跨域问题// vite.config.js server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }后端如果做了跨域处理比如 SpringBoot 里的支持跨域CorsFilter那是备选方案。但我建议优先用前端 proxy 做联调代理特别是部署后还有一层 Nginx 的场景通过 proxy 来解耦更干净。后端打包用 Mavenmvn clean package -DskipTests打出来的target目录下的.jar文件就是可以直接运行的产物SpringBoot 内置了 Tomcatjava -jar demo-0.0.1.jar前端打包npm run builddist 目录就是静态文件里面包含了所有资源。部署方式有两种常见选择我个人更推荐的是用Nginx 部署 dist 目录并配置反向代理/api到 SpringBoot 端口server { listen 80; server_name localhost; root /opt/frontend/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这样做的好处是前端的 ajax 请求在浏览器里看到的仍是同源地址不需要前端处理跨域也不要在后端写跨域配置干净利落。另一个做法是把前端 dist 目录复制进 SpringBoot 项目的src/main/resources/static下再重新打包整个工程成一个 jar。这样只跑一个 Java 进程就能访问前端了对答辩环境是最简单的一种。缺点是每次前端改动都得重新打包但对毕设来说问题不大。我得吐槽一句每年在答辩现场我都能见到因为演示环境没有 Node 或者没有 MySQL 服务导致项目跑不起来的案例。所以现场演示前请务必自己在一台干净机器上从零按一遍流程安装 MySQL、导入 SQL、启动后端 jar、启动前端或直接跑打包后的静态文件确保每个环节都能过。7. 实操中反复踩的坑与避坑思路——给准备动手的同学提个醒最后这部分我把做这类系统时最常见的几个坑集中讲一下。这些坑不解决轻则浪费大半天时间重则直接影响答辩结果。第一个坑是 MySQL 8.0 的驱动和时区问题。驱动类要用com.mysql.cj.jdbc.Driver而不是旧版的com.mysql.jdbc.Driver连接 URL 上最好加上serverTimezoneAsia/Shanghai和useSSLfalsecharacterEncodingutf8。还有一个小 bug 非常经典MySQL 8.0 默认密码插件是caching_sha2_password如果你的 JDBC 驱动版本太旧会连接不上确保用到最新版驱动mysql-connector-java8.0.33 或以上即可。第二个坑是 Long 类型主键在前端精度丢失。后端主键是 Long 类型通过 JSON 传给前端后JavaScript 的 Number 最多精确表示 2^53超长数字会出现尾数四舍五入的“丢精度”问题。结果就是列表页里有个记录点击编辑后永远在编辑别的东西。解决办法有两个一是让 SpringBoot 的 Jackson 在序列化时把 Long 转成字符串返回加上JsonFormat(shape JsonFormat.Shape.STRING)或全局配置二是业务层面用字符串类型的业务编号避免直接暴露自增 ID。我建议一开始就在配置里把 Long 统一转 String一劳永逸。第三个坑是订单状态和房源状态的同步问题。如果你只改了订单表状态而忘了更新房源表状态会出现房源已经被卖掉却还显示“待售”客户下单后房子被别人重复购买。这个问题的根源就是没有用事务或者对事务边界理解不深。所有对“多个表状态同步变更”的操作必须放在同一个Transactional里并在更新前校验源状态。你可以在房源表和订单表加一个 version 字段做乐观锁或者退而求其次在更新语句的 where 条件里强制带上状态字段让数据库层面帮你做“状态对比 更新”的原子操作。例如boolean success houseInfoMapper.updateStatus(houseId, 1, 2); // 只有当原状态为1待售时才会更新为2预订否则影响行数为0这个写法比代码里先查再更可靠得多也是个很值得在答辩时讲出来的设计细节。第四个坑是文件上传和静态资源访问。一些系统会涉及房源图片上传或户型图展示如果你用了本地上传那要注意把上传目录用好并配置静态资源映射。SpringBoot 里需要重写addResourceHandlers把本地磁盘路径映射到/upload/**虚拟路径。不放图片也完全不影响评分但放了图片会让系统看起来更“真”。第五个坑是几乎所有新手都会犯的前后端字段命名不一致。前端用驼峰命名如userName后端实体类用userName但数据库里的字段是user_name接口返回 JSON 时如果没配置全局下划线转驼峰就会出现字段对不上、页面显示空白的情况。解决办法是要么后端统一加JsonProperty要么前端写死字段名适配其实最舒适的方式是在 SpringBoot 里开启全局下划线转驼峰然后前端就按 Java 实体的驼峰字段名对接即可彻底解决这类问题。最后再分享一个小建议如果你时间紧张别贪多。老老实实做三个核心模块把房源、客户、订单做成链路通顺的闭环再加上登录权限和 Dashboard 统计图这个项目无论从完成度还是技术上都已经达到甚至超过多数毕业设计的预期。不要为了“看起来复杂”去堆功能把有限的精力和更多的时间花在把现有模块做扎实、把关键细节打磨顺滑上效果会好得多。就按这个思路动手吧希望这篇分享能让你少走点弯路。