臭鼠标这个题目我在实际带毕业设计的过程中见过太多次了，很多学生一看到“房产销售系统”就想得很简单，觉得无非是“录入房源、展示房源、联系销售”，结果开题写需求的时候才发现，业务牵扯到用户、房源、预约、交易、营销、数据统计好几条线，没想清楚就动手，后期返工成本非常高。
如果你正好准备做SpringBoot方向的计算机毕业设计，或者想拿“房产销售系统”这个题目练手，本篇文章会完整复盘这套系统的设计思路、数据库建模、后端核心实现和部署落地过程，重点讲清楚每个模块为什么这么设计、代码怎么组织、实际开发中容易踩哪些坑。跟着这套思路走，你不仅能交出一份能跑通的系统，更能把答辩时老师爱问的技术点吃透。
1. 项目整体设计与技术选型
1.1 需求边界怎么定：三类角色与核心业务闭环
做毕业设计最忌讳一上来就写代码，先把用户角色和业务流程梳理清楚，后面所有功能的划分都会变得很自然。房产销售系统通常要覆盖三类核心角色：普通购房者、销售人员、系统管理员。购房者需要浏览房源、搜索筛选、收藏心仪楼盘、在线预约看房、登记购房意向；销售人员要维护房源信息、查看自己的销售任务和客户预约、跟进成交；管理员则负责用户审核、公告管理、楼盘上架下架以及基础数据统计。
这些需求串起来其实就是一条业务主线：房源发布 → 用户浏览 → 收藏/预约 → 销售人员跟进 → 成交登记 → 数据统计。我的建议是你先把这条主线画在纸上，然后围绕主线决定功能模块。很多学生会在这里画蛇添足，比如加一个很复杂的支付模块。站在毕设角度，接入真实支付渠道既涉及资质又没有必要，你只需要做“成交登记”和“订单状态管理”的模拟支付即可，把精力放到业务逻辑本身，课堂答辩时反而更聚焦。
1.2 技术栈选型：为什么是SpringBoot + MyBatis-Plus
题目里明确指定了SpringBoot，这其实已经给项目定了很稳的基础。SpringBoot最大的价值在于“自动装配”，它让你不需要关心一堆繁琐的XML配置，通过Starter机制把Web、数据库、安全认证等能力一键集成进来。对毕设开发来说，选SpringBoot 2.7.x版本是最稳妥的，既有足量社区资料，又能兼容JDK 1.8。如果你电脑装的是JDK 17，使用SpringBoot 3.x也能写，但我建议尽量选2.7.18，因为绝大多数学校的教学环境和企业面试题都还停留在2.x生态，遇到报错更容易搜到解决方案。
数据持久层我强烈建议使用MyBatis-Plus。它的底层是MyBatis，保留了手写SQL的灵活性，又有现成的BaseMapper提供增删改查和分页能力，能把你从重复的CRUD代码中解放出来。你可能觉得纯MyBatis更显得技术含量高，但站在产出效率来看，MyBatis-Plus能让一份核心代码少写一半，并且几乎不影响答辩展示，因为你依然可以在复杂业务处手写SQL来体现能力。
前端部分，如果你想降低整体复杂度，直接用Thymeleaf模板引擎把页面渲染出来最省心，服务端渲染的方式不太容易出前后端分离的问题。如果你的答辩陈述里想强调“前后端分离”，那就用Vue + Axios调用后端REST接口。两者没有绝对优劣，关键看你的前端基础。如果你时间紧、没系统学过Vue，我建议你用Thymeleaf + Bootstrap的组合，访问路径直接跳转到HTML页面，开发效率高得多，视觉效果也不错。
1.3 工程结构规划：先分层，别做“大泥球”
在创建项目之前，先在脑子里把包结构想好。我常用的方式是这样：
controller：接收HTTP请求，做参数校验，调用Service，返回统一结果。service：写业务逻辑，比如房源发布时需要校验楼盘信息、生成房源编号。mapper：数据访问层，继承MyBatis-Plus的BaseMapper。entity：实体对象，对应数据库表字段。dto/vo：用于前端传参的封装，以及接口出参的封装。config：配置类，比如放拦截器、跨域配置、Swagger配置。common：全局异常、统一返回结果、常量类等公共内容。
这样分层会让代码清晰很多。刚开始写代码的学生容易把一堆查询逻辑直接塞进Controller，虽然跑得通，但后面想加一个权限校验或换一个页面时，代码会越改越乱。分层的目的不是好看，是让变化可控：Controller只负责“接客”，Service只负责“做生意”，Mapper只负责“读写数据”。即使你的系统规模不大，也建议养成这个习惯，因为大部分课程设计和毕业设计答辩，老师都会看项目结构和代码规范。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据库设计：把业务拆成表
2.1 用户、角色和权限：不要写死在字段里
很多毕设项目的user表里直接放一个role字段，值为“管理员”或“销售”，这种设计在系统很小的时候能跑，但如果你想用Spring Security或者自己写一个简单的权限控制，后续扩展会很痛苦。我更推荐基础的用户-角色-权限模型。
user表负责存用户基本信息，比如用户名、密码、手机号、真实姓名、头像、注册时间；role表存角色；user_role表做关联。这里的权限控制不需要做到按钮级别，做到角色级别就够了。用户登录时查询到当前用户角色，然后通过拦截器判断访问路径是否允许该角色访问即可。
具体字段设计时，有几个地方容易被忽略：
- 手机号字段建议加唯一索引，因为用户注册和登录经常要用到手机号。
- 密码不要明文存储，用BCrypt加密。Spring Security的加密工具类可以直接调用，存进去是带盐的哈希串，即使数据库泄露也不会马上暴露明文密码。
- 添加status字段表示账号状态，比如0表示禁用，1表示正常。实际业务里管理员会拉黑一些骚扰用户，没有这个字段你只能物理删除，问题很大。
2.2 房源信息表：状态字段决定一套业务规则
房源表是整个系统的核心，字段设计需要同时满足“楼盘管理”和“前端展示”两个场景。我会把房源表拆成house和house_info两张表吗？答案是：不要为了范式过度拆分，毕设项目里使用单表加冗余字段反而更高效。
核心字段建议包含：标题、封面图、图片列表、户型、面积、单价、总价、所在城市、区域、地址、开发商、物业类型、装修情况、朝向、楼层、描述、销售负责人id、上架状态、审核状态、浏览量、创建时间、更新时间。
图片列表字段存储JSON字符串或逗号分隔的URL，在MySQL里用text类型就行。前端拿到后解析成数组。这个做法不完美，但在展示型业务里非常常见，比专门建一张图片表简单很多，也不影响索引效率。
房源的状态设计一定要用心。我习惯用两个字段：status表示上下架状态，1是上架，0是下架；audit_status表示审核状态，0是待审核，1是审核通过，2是审核拒绝。两个字段配合使用，管理员审核通过后的房源才会自动变成上架状态，这样能很好地在答辩时演示管理员审