SSM+Vue楼市销售系统毕设指南：技术选型、数据库设计与答辩要点

毕设题目定成“SSM+Vue楼市销售系统”这个组合的，我这几年见了不在少数。很多人一开始心里犯嘀咕：SSM是不是过时了？Vue版本选哪个？和论文怎么写才能不像在凑字数？这套系统到底要做成什么样才算“能答辩”？这些问题我在带毕设、帮人改项目的时候反复遇到过。今天这篇就把这个题目掰开揉碎地讲，从技术选型的真实逻辑、数据库怎么设计、核心功能怎么做，到论文怎么和代码互相印证，一次性讲清楚。适合正在做这个题目的同学，也适合想拿一个稳妥全栈项目练手的人。

1. 为什么“楼市销售系统”是毕业设计里很稳的选题

1.1 业务场景够真实，工作量展示得出来

毕设最怕的就是“管理系统”做成增删改查的堆砌。同样是管理系统，图书管理、学生管理这类题目的问题是：业务太简单，表就三四张，答辩老师一眼看穿工作量。楼市销售系统不一样，它的业务链路天然复杂——房源要分类、要标状态；客户要看房、要预约、要跟进；订单要经历认购、签约、审核；销售数据要统计汇总。一条完整的业务闭环走下来，涉及的模块数量、交互逻辑和状态变化都足够撑起一篇像样的论文和一套说得过去的系统。

还有一点很实际：楼市销售这个领域，天然带着“前后端分离”的诉求。销售员可能在门店用电脑录客户，经理要在大屏上看销售看板，管理员要在后台维护楼盘信息。这就需要系统有清晰的权限划分和不同端的功能侧重，而“SSM提供接口，Vue消费接口”这种模式正好能把这些场景合理地表达出来。

1.2 覆盖的考核点多，从数据库到框架到前端都有东西写

我帮人审过不少毕设论文，最怕看到那种“系统实现”章节全是截图、没有代码逻辑讲解的。楼市销售系统的好处是：它的考核点多到你想回避都难。数据库设计里，房源、客户、订单、跟进记录、用户角色这些表天然就有主外键关系，能画出像样的ER图；后端方面，SSM三个框架各有各的作用，Spring管对象、SpringMVC管请求分发、MyBatis管数据访问，每一层都有可以深入写的内容；前端方面，Vue的组件化、路由守卫、状态管理都能在真实功能里找到落脚点。

换句话说，这个题目不是靠“新颖”取胜，而是靠“扎实”取胜。你不需要发明什么新东西，只需要把一套规范的、完整的、能跑通的全栈项目做出来，然后把其中的关键设计讲明白。对大多数同学来说，“稳”比“炫”重要得多。

1.3 一句话说清这套系统到底做什么

如果你想在开题报告或者论文摘要里用一句话描述它，可以这样说：本系统是一个面向房地产销售场景的信息管理平台，围绕楼盘房源、客户线索、预约看房、成交签约和销售统计等核心环节，实现从房源入库到客户成交的全流程线上化管理，并基于角色权限为销售员、销售经理和系统管理员提供差异化的功能视图。

这句话基本就是整个系统的“北极星”。后面所有的表设计、接口定义、页面开发，都是在往这句话里填细节。

2. 技术选型：为何SSM配Vue，以及版本搭配里的实际考量

2.1 后端选SSM而不是Spring Boot，怎么解释才站得住脚

现在很多同学有一个误区：觉得SSM老，Spring Boot新，毕设里肯定选新的好。实际上，很多高校的毕设题目清单里仍然写着“SSM框架”，而且教学大纲里SpringMVC和MyBatis依然是重点内容。如果你的题目明确要求SSM，那就老老实实用SSM，不用纠结。

哪怕题目没限定，用SSM也有它的合理性：SSM的配置方式更“显式”，你对请求是怎么进Controller的、事务是怎么织入Service的、SQL是怎么和Mapper绑定的，理解得更清楚。Spring Boot默认帮你做了大量自动配置，写起来快，但很多同学做完都不知道内部发生了什么。毕设是学习成果的展示，不是生产效率的竞赛，SSM这种“把配置摊开”的框架反而更适合在论文里写原理。

实际搭建的时候，我的建议是：用Spring 5.x + SpringMVC 5.x + MyBatis 3.5.x这一套，配合Maven做依赖管理和Tomcat 8.5/9.0作为运行容器。需要注意的是JDK版本，Spring 5对JDK 8的支持最稳，建议直接把JDK锁在8。别因为你的电脑上装了JDK 17就硬上，等到运行时出现一堆莫名其妙的问题再来排查，纯粹是给自己挖坑。

2.2 前端Vue：版本选择和配套生态

Vue这边，我的建议是直接用Vue 2.6+Element UI。我知道现在Vue 3已经是主流了，但毕设项目里，Vue 2的生态成熟度、教程数量、踩坑资料丰富度都远高于Vue 3，特别是Element UI这个组件库，和Vue 2是绝配，表格、表单、对话框、分页组件都是现成的，拿来就能用。你花最少的精力把前端页面做得像模像样，把时间省下来去抠后端逻辑和论文。

如果你确实想用Vue 3，那组件库要换成Element Plus，部分写法会不一样。这里我不拦你，但前提是你自己有把握在答辩时讲清楚Composition API的思路。否则，稳妥路线还是Vue 2。

配套的生态我列一下：

• 网络请求：axios，统一封装请求和响应拦截器，处理token携带和错误提示
• 路由：vue-router，配置导航守卫做登录校验和角色权限控制
• 状态管理：vuex，存用户信息、菜单权限等全局数据
• 构建工具：Vue CLI 4.x或5.x，注意Node版本别太新，Vue CLI 5对Node的要求更宽松一些

2.3 数据交互方式：JSON加RESTful风格接口

前后端分离的核心是接口约定。后端只提供RESTful风格的JSON接口，前端通过axios调用。这里有一个我在实际项目里反复强调的规范：统一返回体。不管你每个接口返回什么数据，外面都包一层固定的结构：

{ "code": 200, "message": "操作成功", "data": { } }

code为200表示成功，其他值表示各类错误；message是给前端提示用的文案；data才是真正的业务数据。前端的响应拦截器统一判断code，不是200就弹出message。这样做的直接好处是：后端的异常处理逻辑不用散落在各个Controller里，前端也不用为每个接口单独写错误处理。一个Result类搞定全局规范，论文里还能写一节“统一响应格式的设计”，一举两得。

3. 数据库设计：房产销售业务的核心表和状态流转

3.1 六张核心表，把业务撑起来

楼市销售系统的数据库设计，我建议从业务角色出发反推表结构。系统里至少有三类角色：销售员、销售经理、系统管理员。围绕他们做的事情，核心业务表大概需要这几张：

user和house、customer属于基础数据。appointment是销售流程的中间环节，order是成交环节，follow_log是客户维护的动作记录。这六张表之间关系清楚，画ER图时能画出“一对多”和“多对一”的关系，论文里的数据库设计章节就有内容可写。

3.2 房源状态和订单状态的“状态机”设计

表设计里最容易出彩、也最容易在答辩时被追问的，是状态字段的设计。房源的状态不能简单存一个字符串，我建议用数字状态码加字典表去解释。比如房源表里的status：

• 0：待上架（刚录入，还没对外展示）
• 1：在售（正常展示，可预约）
• 2：已预订（客户下单未签约）
• 3：已售（完成签约）
• 4：下架（暂时不卖）

订单表的status可以这样设计：

• 0：待审核
• 1：已签约
• 2：已付款
• 3：已取消
• 4：已退款

为什么用数字而不是直接用“在售”“已售”这样的中文？两个原因。一是数据库存储空间的考虑，数字占用更小；二是后续需求变更时，你只需要改字典表的显示名称，不需要动业务代码。更重要的是，状态之间是有流转规则的。比如房源只有“在售”状态才能被预约，只有“已预订”才能被下单签约。这个规则在Service层要写校验，在论文里可以画一张状态流转图，这也是加分项。

3.3 索引、外键和字段类型的细节建议

我审过很多同学的建表语句，常见的坑有：金额字段用float、时间字段用String、该建索引的不建、外键约束乱加。几句话总结我的建议：

金额相关字段一律用decimal，比如decimal(10,2)，避免浮点误差。面积和单价同理，decimal(8,2)。时间字段用datetime，Java后端用java.util.Date或者LocalDateTime对应。业务编号字段要建唯一索引，比如订单号order_no。查询频繁的关联字段要建普通索引，比如customer表和house表的主键。外键约束，我们一般建议在数据库层面不建物理外键，而是在应用层通过逻辑关系维护。这不是为了偷懒，而是为了后续分库分表和性能优化方便。论文里如果需要，就写“保持逻辑外键关联，物理外键不加，以提高系统灵活性和性能”即可。

4. 核心功能实现：从登录鉴权到销售流程闭环

4.1 登录鉴权和三种角色的权限控制

登录是整个系统第一个要做的功能，也是第一个要写清楚的功能。后端在Controller层接收用户名和密码，调用Service校验，成功则返回用户信息和一个token；前端拿到token后存到vuex里，同时持久化到localStorage，之后每个请求都在axios拦截器里把token放进请求头。

token的生成方式，我没有用复杂的JWT，而是用UUID加用户信息缓存到Redis。这样做的好处是：服务端可以随时让token失效，注销登录的逻辑简单直接。如果你的环境里没有Redis，也可以把session和token的映射存在ConcurrentHashMap里，但毕设里建议还是用Redis，因为轻量级的Redis服务很好装，对论文里的“技术选型”章节也是加分项。

权限控制分成两层。后端在SpringMVC的拦截器里做登录校验，并针对特定URL前缀做角色校验，比如/admin/**的接口只有管理员能访问，/manager/**只有销售经理能访问。前端在vue-router的导航守卫里做页面级别的跳转控制，根据用户角色动态生成可访问的路由菜单。这里建议你写成“静态路由加动态生成”的方式：基础路由（登录页、首页）静态定义，业务路由根据角色从后端接口获取后动态添加。这样可以避免前端把所有页面都摆在明面上，也符合实际项目里权限收敛的习惯。

4.2 房源展示：搜索、分页和条件筛选

房源列表是整个系统中用户量最大的页面之一，考察的就是你对“条件查询加分页”这个基础能力的掌握。前端列表页用一个搜索栏加一个表格，搜索栏里放关键词、区域、价格区间、户型类型等筛选项。后端对应接口接收这些条件，通过MyBatis的动态SQL拼出查询语句。

分页我用的PageHelper插件，在Service层调用PageHelper.startPage(pageNum, pageSize)后，紧跟的查询语句就会被自动拦截并分页，同时PageInfo里还能拿到总记录数。这个插件在SSM项目里太经典了，网上教程一大堆，答辩时大概率会被问到原理。你得知道它是通过MyBatis的拦截器机制，在SQL执行前动态拼接LIMIT语句和统计查询，并不是什么黑魔法。

这里有一个容易踩的坑：PageHelper的startPage方法必须紧挨着要分页的查询语句，中间不能插入其他SQL操作，否则分页会作用到错误的查询上。很多同学的列表偶尔会查出全表数据或者分页失效，十有八九是这个问题。

4.3 预约看房和订单成交的状态流转

预约看房是销售流程里的中间环节。销售员在客户列表里代客户发起预约，选择房源和看房时间；系统要校验所选房源状态是否为“在售”；预约后，销售员可以填写跟进记录，记录客户的意向变化；看房完成后，如果客户决定购买，预约状态改成“已到访”，然后进入下单流程。

订单创建这里有几个关键校验不要漏：一是房源状态必须为“在售”或“已预订”，二是同一房源不能同时被多个未取消的订单占用，所以创建订单时需要加行锁或者通过状态更新来防止并发冲突。我的做法是：创建订单时用update语句把房源状态从“在售”改成“已预订”，通过update影响行数来判断是否抢到房源。影响行数为1说明状态更新成功，可以继续生成订单；影响行数为0说明房源已经被别人订走，返回友好提示。这种“乐观锁思路”在我的项目里实测很稳，也是答辩时能拿出来讲的细节。

订单创建后进入“待审核”状态，由销售经理在后台审核，审核通过后订单状态改为“已签约”，房源状态改为“已售”。如果审核不通过，订单状态回退为“已取消”，房源状态回退为“在售”。

4.4 销售统计看板：SQL聚合和前端图表

销售经理账户要能看到一个统计看板。我自己实现时做了三个核心指标：总成交量、总成交金额、各楼盘销量排名。后端用MyBatis写聚合查询，典型的一种是：

SELECT house_type, COUNT(*) AS sold_count, SUM(total_price) AS total_amount FROM order WHERE status = 1 AND create_time BETWEEN #{startTime} AND #{endTime} GROUP BY house_type

前端图表用ECharts，柱状图展示各类型房源的成交量，饼图展示成交金额占比，折线图展示近六个月的成交量趋势。ECharts的使用本身不难，但要注意图表数据的接口返回结构设计成前端可直接消费的形式：xAxis对应一个数组，series对应一个数组，用后端直接把数据组合好，前端只负责渲染。这样做的原因是减少前端的复杂处理逻辑，也方便你在论文的系统实现章节里写“后端返回聚合数据，前端可视化展示”这种清晰的分工描述。

4.5 SSM整合里的配置文件避坑指南

SSM最劝退新手的其实是整合配置。SpringMVC配置文件、Spring配置文件、MyBatis配置文件、web.xml四者之间的配合，很多同学在这里耗掉大量时间。我把最常见的几个坑列一下：

Spring容器扫描Service层和Dao层，SpringMVC容器扫描Controller层，这个“父子容器”的划分不要搞混。如果Controller扫描到了Service层或者反过来，会导致事务失效，甚至启动直接报错。

MyBatis的Mapper接口扫描配置要写对。用MapperScannerConfigurer去扫描mapper包，同时把mapper xml文件的路径配置到SqlSessionFactoryBean中。XML文件放在resources目录下的mapper文件夹里，不要放在Java源码目录。否则打包时XML文件会被漏掉，运行时报“Invalid bound statement”错误。

事务配置用<tx:advice>加<aop:config>是SSM时代的标准姿势，切点表达式直接指向service包。注意aop依赖要引入，很多同学配置写得没问题，但漏了spring-aspects依赖导致启动报错。

拦截器注册注意顺序：先注册登录校验拦截器，再在它的excludePathPatterns里放行登录接口、静态资源等。如果注册顺序错了，登录页的请求可能也会被拦截到。

5. 论文写作：程序代码和论文怎么互相印证

5.1 目录结构：从摘要到测试的标准路线

毕设论文的结构通常有套路：摘要、绪论（背景意义、国内外现状、研究内容）、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结致谢参考文献。这个结构本身没什么特别的，但有一个原则要说清楚：论文里的每一章都要能在代码里找到对应的东西。如果论文里写了系统有“订单审核”功能，那么代码里必须真的有这个功能，测试章节里必须真的有对应的测试用例。三者的对应关系越强，论文答辩时越经得住问。

5.2 需求分析章节怎么写才不空洞

需求分析是最容易被写成“车轱辘话”的章节。很多同学直接复制粘贴：“本系统提高了管理效率，降低了运营成本。”这些话没有错，但没有信息量。我的建议是：需求分析里必须有具体的角色用例表格和业务流程描述。

比如销售员的核心用例至少要有这几条：登录、浏览房源、新增客户、发起预约、填写跟进记录、创建订单、查看个人业绩。销售经理的用例包括：查看销售看板、审核订单、管理销售员。管理员的用例包括：用户管理、房源管理、数据字典管理。把用例用表格列出来，每个用例写明主要操作和前置条件，这一章自然就有内容了。

业务流程描述里，把“客户从预约到成交”的路径写清楚，画一张泳道图或流程图。过程描述不要用“用户点击按钮”这种话，而是用“系统校验房源状态后生成预约记录，并通知销售人员”这种业务语言，体现出建模思考。

5.3 系统设计章节要给出关键表和接口说明

系统设计章节里的数据库设计部分，你需要放进完整的ER图、核心表的结构表格。表结构表格里要体现字段名、类型、是否主键、是否允许为空、说明等。不要只贴一张pictures从Navicat导出的建表语句截图，那看不出你的设计思路。接口设计部分，把RESTful接口列出来：URL、请求方式、参数、返回体结构。可以做一个接口清单表格，比如POST /api/login、GET /api/house/list、PUT /api/order/audit，这样论文的“设计感”会强很多。

5.4 测试章节的灵魂在于测试用例表

测试章节是论文里最容易被敷衍的部分。如果只写“经过测试系统运行正常”就完了，答辩老师印象分会很低。正确的做法是做一张完整的测试用例表：用例编号、测试模块、测试步骤、预期结果、实际结果。拿出几个典型的用例来写，不要写那种“输入错误密码，提示错误”的简单用例。建议写业务流程类的用例，比如“经纪人发起预约时房源状态已为已售，系统应拒绝并提示”。这种跨模块的测试用例，体现了你对业务规则有思考。

5.5 基于合理的模拟数据做演示

评审和答辩时总会被要求演示系统。你应当预填一套逼真的模拟数据，包括若干套楼盘房源、客户线索、不同状态的订单。避免在演示现场临时录入。预置演示账号也要分开，管理员、经理、销售员各一个。实测经验是，切换账号展示不同权限视图，会比较出效果，也能体现角色权限模块的完成度。

6. 一些实用的工程化建议和答辩前自检清单

6.1 从开发到打包部署的完整流程

开发环境的搭建我给一个参考流程：装好JDK 8、MySQL 5.7或8.0、Maven 3.6.x、Node 14或16。后端用IDEA导入Maven项目，配置Tomcat，启动后先访问Controller层接口确认Spring容器没问题；前端用Vue CLI脚手架创建工程，配置axios的baseURL为后端接口地址，npm install安装依赖后npm run serve启动开发服务器。

开发完成后，前端执行npm run build打包到dist目录，然后把dist目录下的静态文件放到后端webapp目录下，重打war包部署到Tomcat。这样一来，整个系统就变成了一个可直接部署的war包，并没有真正的前后端分离部署，但对于毕设来说足够了。如果你想展示线上运行的效果，把war包扔到一台云服务器上，装好MySQL和Redis，配置好数据库后即可访问。

6.2 答辩自检清单

答辩前，我一般建议按下面这个清单过一遍。第一，系统能启动吗？后台服务不能报“ClassNotFound”或者“BeanFactory”的异常。第二，每个页面的核心操作能跑通吗？特别是登录、列表查询、新增修改、删除、权限跳转这五类。第三，演示数据干净吗？别出现测试时留下的脏数据。第四，你能否在没有源码的情况下口述你的系统架构？从用户发出请求，到后端Controller、Service、Mapper，再到返回前端渲染，完整链路要能说顺。第五，你了解每个核心代码类的作用吗？不要在论文里抄了别人的代码，结果被问到哪一个类是自己写的时答不上来。

6.3 后续可以扩展的方向

如果你的时间和精力有余，这个系统还有几个自然的扩展方向。一是增加数据可视化大屏，把销售数据展示从普通图表升级为大屏样式；二是增加客户画像标签，比如偏好户型、预算区间、意向等级，为推荐算法打基础；三是引入消息通知模块，预约提醒、订单审核结果实时推送给相关人员。这些方向在答辩时可以选一个作为“未来展望”写进总结，显得思考有深度。

我个人的体会是，把SSM和Vue这一套做完整的最大收获，不是学会了某个框架，而是理解了“一个业务功能从前端页面到后端数据库，完整走一遍要经历哪些环节”。这种全栈思维在学校里很难通过一堂课建立起来，但做完一个项目之后，框架和配置之间的串联逻辑就会越来越清晰。希望这篇内容能帮你把项目做得更加稳妥扎实。