SpringBoot房产销售系统从零落地：数据库设计、状态机与营销链路完整解析

做毕设拿到“SpringBoot房产销售系统”这个题目时，我的第一反应是：这不就是一套常规的管理系统加一个商城页面吗？后来真正把题目拆开才明白，它写的是“房地产营销平台”，不是“后台管理系统”，这意味着你既要能把房源、订单这些核心数据管起来，还要让“获客-看房-认购-服务”这条营销链路跑通。过去这段时间我从需求分析、数据库建模、前后端开发到部署调试走了一遍，积累了不少可复用的经验，这篇内容就是想把SpringBoot驱动下的房产销售系统怎么落地、有哪些容易被忽略的点、毕设和答辩需要准备什么，一次性讲清楚。适合正在做选题、刚开始搭建框架，或者系统跑起来但总觉得“业务不够闭环”的同学参考。

说实话，网上关于SpringBoot房产系统的源码和教程不少，但很多都停在“用户登录、楼盘增删改查、订单管理”这种CRUD层面。这类系统想让老师认可，或者放到简历里经得起追问，至少要把三件事做透：一是数据模型能不能覆盖房产项目的真实业务，比如一栋楼下面有多个单元户型；二是流程控制有没有状态驱动，比如一套房源从“在售”到“预定”再到“成交”，状态之间的转换谁允许、谁不允许；三是营销模块有没有价值，不能只是展示图片。下面我按自己的开发顺序，把这套系统的设计思路和实操过程完整还原出来。

1. 项目整体定位：这套系统到底要解决什么问题

1.1 从题目里拆出三层需求

“SpringBoot房产销售系统”这个词可以拆成三层，每一层对应你毕业设计里的一道主线。最底层是技术主框架，SpringBoot解决的是后端服务怎么快速搭建、怎么和数据库交互、怎么提供接口给前端调用；中间层是业务实体，房产销售系统要管理楼盘、房源、客户、订单、合同、回访记录这些东西；最上层是业务目标，把线下的看房、登记、认购流程搬到线上，或者说做一个能让售楼员、渠道专员、案场经理共同使用的工作台。

举个例子，一套最简单的房源模块，在普通课设里可能是“房源表+列表页+编辑删除”。但在房产销售场景下，你必须考虑：同一个楼盘可能有高层和洋房，每种业态下有不同的楼栋，楼栋里又有不同楼层和朝向的房源。如果只建一张“house表”硬塞所有字段，到后来客户搜索“南向三房两厅、100到120平米、总价300万以下”时，写查询条件就会非常痛苦。所以拆解需求的第一步不是急着建表，而是先把类似“楼盘-楼栋-房源”的层级关系理清楚。这里我建议先画一个粗粒度的业务流程图，不用是很正式的UML，自己看得懂就行，重点把“访客从哪里来、怎么形成线索、如何变成成交客户”标出来。

1.2 为什么选SpringBoot而不用传统SSH或SSM

把标题里的SpringBoot换成SSM或者SSH一样能做房产系统，但SpringBoot之所以成为毕业设计主流选择，是因为它真正把“配置地狱”解决了。在SSM时代，光是spring-mvc.xml、spring-mybatis.xml、web.xml的配置就会劝退一大半同学，而且不同版本之间配置项经常不兼容。SpringBoot用自动配置和starter机制把常用框架整合成了“开箱即用”，你要用MyBatis就引入一个mybatis-spring-boot-starter，要用Redis就引入一个spring-boot-starter-data-redis，依赖一进来大部分默认配置已经就绪。

对企业级技术选型来说，SpringBoot并不是性能最强的框架，但它是生态最成熟、招聘需求最广的框架之一。作为一个考核性项目，选SpringBoot意味着你遇到的大部分问题都能在网上找到解决方案，教师上手检查也容易。更重要的是SpringBoot内置Tomcat，打包成jar直接java -jar就能跑，这对演示和答辩非常友好，你不用像老项目那样单独装Tomcat、改server.xml，也不容易出现“在我电脑上明明能跑”的尴尬。

这里也提醒一句，SpringBoot 版本不要盲目追求最新。如果你的运行环境是JDK 8，老老实实用Spring Boot 2.7.x；如果老师要求JDK 17，再考虑Spring Boot 3.x，因为3.x从javax包迁移到了jakarta包，很多老教程里的import javax.annotation.Resource会直接报错。项目里我看到过不少同学踩了版本太高的坑，最后又降回来，纯属浪费时间。

1.3 毕业设计和企业项目的差异在“完整性”

很多同学觉得毕设系统代码量越大越好，其实评审老师更看重的是业务能不能自圆其说。比如“登陆”功能人人都会写，但如果你的系统只是用户名密码登陆，没有任何角色区分，那么“销售顾问录入客户”“销售经理审核成交价格”这些业务就无法解释清楚。

做这套房产销售系统时，我最深的感受是：毕设的重点不是秀某个冷门技术，而是把“一条完整业务”跑通。用户在这个平台上能看房、收藏、预约线下看房；销售顾问能看到预约记录并及时录入跟进结果；经理能查看楼盘的去化率、客户转化率，给优惠活动做上下架。哪怕每个模块做得很小，把这整条链路闭合了，系统的价值就立刻不一样。后面章节里，我会按技术栈、数据库设计、关键接口、部署运维的顺序说明，实际上这也是我写论文时安排章节的顺序。

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

2.1 核心技术组件怎么搭配最稳

毕设选技术栈不要追求“新奇特”，要追求“好解释、能跑通、有亮点”。我最终采用的前后端分离方案是：Spring Boot 2.7.18 + MyBatis-Plus + MySQL 8.0 + Redis + Vue 3 + Element Plus。SpringBoot 负责提供RESTful API，MyBatis-Plus负责数据访问，Redis缓存登录Token和验证码，前端用Vue 3管理页面交互。

这套组合的主要优势是各层之间边界清晰，论文里好写“前后端通过JSON格式交互”，答辩时也好回答“为什么引入Redis”这类问题。SpringBoot方面核心依赖大概只需要spring-boot-starter-web、validation、aop，再加一个mybatis-plus-boot-starter和mysql-connector-j。redis不是必须，但建议加，因为“登录状态”用JWT+Redis实现后，被问到“怎么处理用户退出、怎么实现接口鉴权”时，会比只用拦截器更经得起追问。

建立项目时我建议直接在Spring Initializr或IDEA里先生成基础包，结构上采用controller/service/mapper三层。我的包里还加了一个common包，用来放统一返回结果类Result、业务异常类和全局异常处理器。这里有一个小技巧：统一返回结构定义成{code, message, data}，所有接口都返回同一套格式，前端拦截器只需要处理一次响应，省掉大量的逻辑判断。代码结构一开始就别乱，后面写论文画系统架构图也方便。

2.2 application.yml配置里容易踩的几个坑

SpringBoot 项目的配置文件看似简单，实际很多运行问题都出在这里。我常用的配置结构如下：

yaml复制server:
  port: 8080

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/house_sale?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false
    username: root
    password: 123456
  redis:
    host: localhost
    port: 6379
    database: 0
  servlet:
    multipart:
      max-file-size: 10MB
      max-request-size: 20MB

mybatis-plus:
  mapper-locations: classpath:mapper/*.xml
  configuration:
    map-underscore-to-camel-case: true
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

driver-class-name 一定要写带 cj 的 MySQL 8 驱动。MySQL 8 之前的驱动类是 com.mysql.jdbc.Driver，在新版本里会报警告，某些MySQL版本甚至直接连不上。url里要加上 serverTimezone=Asia/Shanghai，否则会报时间区错误。map-underscore-to-camel-case 建议打开，这样数据库表字段create_time能自动映射到实体属性createTime。log-impl配置成StdOutImpl后，控制台会直接打印SQL，排查数据问题时会方便非常多。

2.3 前端决策：完全前后端分离还是服务端渲染

很多毕设题目只写了SpringBoot，没写前端用什么，这时候你有两个选择：一是用SpringBoot的模板引擎Thymeleaf做一个多页面应用，二是把前端独立成Vue项目。我个人强烈建议用前后端分离。原因很简单：房产销售系统的页面交互很多是动态的，比如房源列表的筛选条件、预约看房的时间选择、管理后台的Tab切换，用Vue这类框架写起来远比在HTML模板里拼字符串顺手。

前后端分离还会带来一个好处：你的项目里可以多出一个“前端工程”，简历里可写的东西就多了。开发时后端启动在8080端口，前端Vite开发服务器默认在5173，需要在后端写一个CorsConfig配置跨域。生产环境则让后端打成jar包，前端构建成静态文件后部署到Nginx，再由Nginx把/api开头的请求代理到SpringBoot服务上。这个知识在面试中很常问，值得提前掌握。

3. 数据库建模是这套系统最重要的地基

3.1 从业务实体到核心表设计

数据库设计做得好不好，直接决定后面所有功能的开发效率。房产销售系统的核心实体我认为可以分成五组：用户权限类、房产资源类、交易流程类、营销活动类、内容展示类。用我实际的表来举例，大致结构如下：

• sys_user：用户表，包含用户名、密码、手机号、角色类型、所属部门
• sys_role / sys_user_role：做最简单的RBAC权限模型
• building：楼盘表，保存楼盘名称、区域、地址、均价、建筑面积、开发商、开盘时间、封面图
• house：房源表，核心字段为所属楼盘id、楼栋号、单元号、房号、户型、面积、朝向、单价、总价、装修状态、销售状态
• house_media：房源图片或VR链接表，让一个房源有多张展示图
• customer：客户表，记录姓名、电话、意向楼盘、意向户型、预算范围、来源渠道
• appointment：预约看房表，记录由哪个客户预约、预约时间、陪同销售、状态
• order_info：认购或订单表，记录客户购买哪套房产、成交单价、优惠金额、订单状态
• coupon_activity / customer_coupon：优惠券活动表和客户领券表

实际开发的时候，不要把营销活动和交易流程耦合到一张大表里。客户领取一张优惠券，它本身只是一个关联关系；等真正下订单时，再把优惠券和订单绑定，同时计算优惠金额。若是一开始就把券的字段倒在订单表，后期统计“某个活动带来多少成交”会非常费劲。

3.2 房源状态和订单状态要设计成状态机

在线房产交易最容易讲不清楚的地方是“带看、认购、签约”这些流程如何用程序表达。我的设计思路是给house表加一个status字段，命名为sale_status，用0表示待售、1表示预定、2表示已成交、3表示下架；给order表也加status，用0表示待支付、1表示已支付、2表示已签合同、3表示已取消。注意，房源的销售状态不是由后台管理员随意改的，而是由订单状态驱动改变的。

从用户端来看，一位置业者会经历：选房 -> 收藏 -> 发起预约 -> 线下看房 -> 销售在后台把房源标记为预定 -> 用户支付定金/首付 -> 订单状态从待支付变成已支付 -> 房源自动变成已成交。在这里，预约和订单这两个模块就必须引用同一个houseId，同时每次状态变更都记录操作时间。实现的时候建议把订单状态流转封装成一个枚举或者一个专门的OrderStatusHandler类，避免Controller里到处都是if状态判断。这样做不仅减少bug，论文里也可以单独画一张“交易状态图”，是个不错的加分项。

3.3 用MyBatis-Plus写复杂查询的注意事项

MyBatis-Plus 的确是效率神器，单表CRUD基本不用写SQL，但它不是银弹。房产销售系统里“按条件搜索房源”是一个典型多表关联查询，这时不要硬用QueryWrapper拼条件，直接把XML自定义SQL写得更加直观。常见的业务是：前端传关键词、区域、总价范围、户型和销售状态，后端动态拼接SQL。比如：

xml复制<select id="selectHousePage" resultType="com.example.house.entity.House">
    SELECT h.id, h.house_no, b.name AS building_name,
           h.building_id, h.floor, h.unit, h.room_no,
           h.house_type, h.area, h.total_price, h.sale_status
    FROM house h
    LEFT JOIN building b ON h.building_id = b.id
    <where>
        <if test="keyword != null and keyword != ''">
            AND (h.house_no LIKE CONCAT('%', #{keyword}, '%')
                 OR b.name LIKE CONCAT('%', #{keyword}, '%'))
        </if>
        <if test="buildingId != null">
            AND h.building_id = #{buildingId}
        </if>
        <if test="minPrice != null">
            AND h.total_price &gt;= #{minPrice}
        </if>
        <if test="maxPrice != null">
            AND h.total_price &lt;= #{maxPrice}
        </if>
        <if test="houseType != null and houseType != ''">
            AND h.house_type = #{houseType}
        </if>
        <if test="saleStatus != null">
            AND h.sale_status = #{saleStatus}
        </if>
    </where>
    ORDER BY h.create_time DESC
</select>

用标签的目的是让SQL动态变化，但不建议把字段全塞进去，比如“朝向”和“楼层”如果业务里不要求，就不需要写，减少测试组合。写动态SQL时容易踩的一个坑是“小于号”在XML里不能直接写，要用<避开，否则XML解析会挂。这个细节很小，但很多第一次做的人会卡上好久。

4. 营销平台的关键功能实现经验

4.1 楼盘展示模块不是简单列表，要有“找房”逻辑

很多毕设作品里，楼盘展示页面就是一张表加几张图片，用户只能翻页看。刚开始我也这样做，但后来发现，一个叫“数字化楼盘营销平台”的系统，如果连“找房”都做不到，那营销属性就无从谈起。所以我给出的理解是：展示模块至少要具备“多维筛选”和“个性化推荐”两层逻辑。

多维筛选我实现了区域下拉、面积区间、总价区间、户型和朝向几个条件。这里要注意，面积和总价用区间是最符合用户习惯的，但前端传值时最好约定如下格式：minPrice=2000000&maxPrice=3000000，而不是把“200万到300万”这样的中文传给后端，所有展示格式化放在前端处理。面积字段在数据库里用DECIMAL(10,2)保存，单位为平方米，不要用字符串。

“猜你喜欢”这种模块听起来很高级，但实现实际不复杂。当用户未登录时，可以将该楼盘访问次数加一，排序默认显示访问多的前几个；当用户登录后，我根据收藏过的房源查询相同户型、相同面积的房源，按总价接近程度排序。这种推荐本质上是一个简单倒排逻辑，却能在答辩时作为“数字营销的轻量尝试”来介绍。

4.2 预约看房与防重复提交

在线预约是房产销售系统的核心环节。用户的流程是选择房源、选择去看房时间、填写手机号、提交。后端需要做两件事：校验预约时间不能是过去时间，校验同一个手机号在同一个时间段不能重复预约。第二件事很多人会忽略，结果就是同一个客户同一套房源可以下单无数次，后台销售看到一堆噪音数据。

防止重复提交有一个比较稳妥的方案：在预约表对客户手机号和房源id做一个唯一索引，再加一个预约日期字段。我使用的建表SQL片段大致如下：

sql复制CREATE TABLE appointment (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    customer_name VARCHAR(50) NOT NULL,
    customer_phone VARCHAR(20) NOT NULL,
    house_id BIGINT NOT NULL,
    appointment_date DATE NOT NULL,
    appointment_time VARCHAR(20),
    status TINYINT DEFAULT 0 COMMENT '0待确认 1已确认 2已完成 3已取消',
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
    UNIQUE KEY uk_phone_house_date (customer_phone, house_id, appointment_date)
) COMMENT '预约看房表';

唯一索引只能防住数据库层面的重复，理想情况下后端还要先用Redis或查库判断一下，并给用户友好提示。预约提交成功以后，系统应向销售顾问生成一条待办事项，或者至少在后台列表中高亮显示“新预约”，这在营销场景里叫“线索分配”，是题目里隐含的亮点功能。

4.3 订单流程中的“支付模拟”与状态一致性

房产交易牵扯大额资金，线上订单不可能真接第三方支付，所以毕设中普遍用“模拟支付”来处理。点击支付按钮后，后端判断当前订单是否属于当前登录用户，如果订单状态是待支付，则将其改为已支付，同时回调房源更新接口，把房源status从在售改为已成交。这里非常容易出现状态不一致：订单改成了已支付，但是房源状态因为代码异常没有更新，造成一套房源被卖两次。

为了避免这种问题，我建议把“提交预约 -> 创建订单 -> 锁定房源 -> 支付完成 -> 房源成交”这一连串操作放到同一个事务方法里。在Spring框架下使用@Transactional注解，保证这些数据库操作要么全部成功、要么全部回滚。SpringBoot和SpringBoot Starter自带的AOP事务代理，默认允许运行时异常时回滚，但注意如果catch了异常但没有抛出，事务还是会提交，这是一个特别隐蔽的坑。具体做法是业务方法里不要为了“界面友好”把异常吞掉，先让事务能感知到，再在Controller层转成统一异常给用户看。

当用户取消订单时，也要释放房源的锁定状态，恢复为在售。订单状态如果比较复杂，我建议用一个事务脚本方式实现，把每个状态迁移方法单独写出来，甚至在方法入口做状态校验。

4.4 客户线索和营销数据统计

做“营销平台”最怕的是把业务做成一个孤立的CRUD。客户从哪个渠道来、看过哪些房源、收藏了哪些楼盘、最终有没有成交，这种数据理清楚以后就能做统计分析。我在数据库里给customer表加了一个source_channel字段，取值包括“自然来访”“老带新”“线上广告”“中介渠道”，这样后台就可以通过SQL查询出各渠道线索数量。

对于营销效果，系统里可以展示三个核心指标：线索总数、预约到访率、成交转化率。查询预约到访率主要用预约表和订单表关联，统计本月预约状态为已完成的客户里有多少产生了订单。实现并不难：

java复制Long totalVisit = appointmentMapper.selectVisitCount(month);
Long dealCount = appointmentMapper.selectDealCount(month);
BigDecimal conversionRate = totalVisit == 0 ? BigDecimal.ZERO
        : BigDecimal.valueOf(dealCount)
        .multiply(BigDecimal.valueOf(100))
        .divide(BigDecimal.valueOf(totalVisit), 2, RoundingMode.HALF_UP);

前端图表我推荐ECharts，柱状图展示近六个月成交量，饼状图展示客户来源，折线图展示预约趋势。这些图表放出来，会让系统“数字化”的形象立体不少，论文里也截图就有说服力。

5. 登录鉴权、权限控制与后端安全细节

5.1 用SpringBoot整合JWT和Redis实现登录态

房产销售系统涉及客户隐私和公司房源信息，后台不能裸奔。很多教程会用Session，但在前后端分离架构下，JWT是更合适的方案。JWT的处理流程大致是：用户登录成功后，后端生成一个带过期时间的token，返回给前端；前端每次请求在Header里带Authorization: Bearer token；后端用一个拦截器解析token，并在Redis中查询是否存在，从而判断是否有效登录。

引入Redis做二次校验的理由是，JWT 本身是无状态的，一旦签发无法手动失效。如果只靠JWT，用户点击退出后，token其实还能继续使用；把token在签发时写入Redis，退出时删除一个Key，才能真正实现“退出登录失效”。这里涉及“SpringBoot+Redis”的经典用法，适合作为简历上的技术点来写。

拦截器只负责解析token，更细粒度的权限判断建议使用Spring AOP或Spring Security来完成。如果项目时间紧不引入Spring Security，也不建议在Controller里手写一堆if判断“当前用户是否为管理员”，可以让Controller先通过RequestContext取出当前登录用户的信息，包括用户角色。管理员接口上再写自定义注解结合AOP判断，效果够用且代码更简短。

5.2 统一返回、全局异常与参数校验

把Result格式定义好以后，每一个Controller返回值都需要保证是同一格式。我的Result类大概如下：

java复制@Data
public class Result<T> {
    private Integer code;
    private String message;
    private T data;

    public static <T> Result<T> success(T data) {
        Result<T> result = new Result<>();
        result.code = 200;
        result.message = "success";
        result.data = data;
        return result;
    }

    public static <T> Result<T> error(Integer code, String message) {
        Result<T> result = new Result<>();
        result.code = code;
        result.message = message;
        return result;
    }
}

后端参数校验建议使用Spring Validation，比如接收预约请求时用@NotBlank标注手机号，用@NotNull标注houseId，Controller上加@Validated，参数不合法时Spring会抛出MethodArgumentNotValidException，再交给@RestControllerAdvice统一处理成标准错误信息。这样不会把一堆参数判断代码散落在service里。全局异常处理还要处理业务异常，比如“房源已下架”这种错误，我定义了一个BizException，凡是Service里发现业务规则被破坏就直接throw new BizException("房源已被锁定")，既简洁又不容易漏。

5.3 数据库密码与文件上传的安全处理

房产销售系统里会上传房源图片，很多毕设直接把图片保存在项目目录下，这在开发环境跑没问题，但打包成jar后用java -jar运行就会出乱子，因为图片被写到了临时目录或jar包内部，可能访问不到。正确做法是在application.yml里配置一个外部存储路径，比如file.upload-path: D:/upload或者相对路径./upload，然后用配置类实现WebMvcConfigurer做静态资源映射，将/upload/**映射到本地目录。这样重启服务后图片依然存在。

用户密码不能明文存储，至少要用BCrypt加密。Spring Security中本身带了BCryptPasswordEncoder，即使不引入整个安全框架也可以单独使用。对房产销售系统来说，后台用户密码被破解是比较严重的隐私风险，这算是毕设的加分细节。在数据库里看到明文的密码，很多老师一眼就会减分，一定不要省这一步。

6. 部署演示与答辩高频问题

6.1 项目打包：SpringBoot后端、Vue前端和上线演示环境

后端打包前，先把application.yml里数据库密码改成演示环境密码，然后执行：

bash复制mvn clean package -DskipTests

生成的目标文件一般为house-sale-system-0.0.1-SNAPSHOT.jar。运行命令：

bash复制java -jar house-sale-system-0.0.1-SNAPSHOT.jar

只要curl http://localhost:8080/api/health能返回JSON，说明后端没问题。前端Vue项目构建：

bash复制npm run build

构建产物在dist目录。演示时有两个选择：把dist目录里的文件直接拷贝到SpringBoot的static目录里重新打包，这样启动8080后前端后端在一台机器上访问；或者用Nginx托管dist，并配置转发：

nginx复制server {
    listen 80;
    server_name localhost;
    root /opt/house-front/dist;
    index index.html;

    location /api/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

用Nginx方案时要注意刷新页面路由不能404，前端Vue Router如果是history模式，需要在server里增加try_files $uri $uri/ /index.html; 否则刷新后页面会白屏。这些内容在论文的“系统部署”一节里有详细描写，会显得项目更真实。

6.2 经典问题：端口占用、MySQL连接、依赖拉不下来

演示现场最常见的问题就是后端启动失败。如果日志里出现Web server failed to start，多半是8080端口被占用，检查一下是哪个进程占用了端口，把占用进程停掉或者改端口再启动。另一个高发区是MySQL连接失败，常见原因包括MySQL服务没启动、密码不对、url中数据库名不存在。我建议在application.yml里使用一个专门为项目创建的数据库账号，不要用远程服务器上权限受限的账号。

关于依赖问题，如果用阿里云镜像就写进settings.xml或项目的repositories里，否则第一次从Maven中央仓库下载依赖，在一些网络环境下会非常慢，甚至直接卡住。SpringBoot多个依赖版本不一致也很常见，尽量使用同一个Boot版本下的starter，不要在pom里手动引入与Boot无关的jar版本，让Spring Boot BOM去统一管理，能省掉一堆NoClassDefFoundError。

6.3 答辩时如何回答“这个项目有哪些技术难点”

这项可能是整篇分享最关键的部分。很多同学做完系统后最怕老师问“你遇到的最大难点是什么”，如果答“没有难点，代码照着写的”，项目就成了纯粹的作业。实际上，即使是毕设项目也一定有一些值得讲的细节。我的项目里遇到的真实难点有三个：第一个是房产销售的状态一致性，从预约、锁定房源到支付，如何保证同一套房源不会重复卖出；第二个是动态条件搜索的SQL优化，看似简单的“组合查询”在表结构和索引设计不当时会非常慢；第三个是图片和上传文件的存储设计，如何做到本地开发和生产环境都可用。

答辩介绍项目时建议按“业务背景 -> 模块划分 -> 个人负责的内容 -> 关键字说明 -> 难点与解决”的顺序。讲到数据库时，不急着念表名，要先说“我参考了房产销售行业常见的案场管理流程，把系统拆为房源、客户、订单、营销四类核心数据”，这种行业化表达比“我有八张表”有说服力得多。老师如果追问“你如何实现权限控制”，可以用第5节的JWT+Redis和自定义注解去解释；如果问“你这个系统有什么不足”，不要慌张，可以坦诚说目前优惠券系统没有做到按批次限量，客户行为分析还不完整，下一步可以结合消息队列做异步处理，这反而说明你有思考和扩展意识。

7. 最后想分享的几个实操心得

这套系统在断断续续开发中，让我体会到毕业设计最有价值的不是把代码写完，而是把“为什么这么设计”想清楚。SpringBoot只是工具，真正让别人眼前一亮的，是你对房产交易和营销业务的理解。建议大家做一个Git仓库，每完成一个功能就提交一次，这样既能避免误删代码，又能在论文的“实施过程”里写清楚每个里程碑。

最后说一个容易被忽略但特别实用的小技巧：把系统里所有用到的样例数据准备充分。楼盘信息至少放三到五个，每个楼盘配八到十二套房源，同时造出一些不同来源、不同状态的客户数据。老师演示时点开一个楼盘，看到的是丰富的图片、不同户型的可售房源和真实的折线图，而不是一张空空如也的表格。数据永远是系统最好的门面，这比任何华丽的技术词都有说服力。