SpringBoot房产销售系统毕业设计完整实战指南

这个题目我在实际带毕业设计的过程中见过太多次了，很多学生一看到“房产销售系统”就想得很简单，觉得无非是“录入房源、展示房源、联系销售”，结果开题写需求的时候才发现，业务牵扯到用户、房源、预约、交易、营销、数据统计好几条线，没想清楚就动手，后期返工成本非常高。

如果你正好准备做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只负责“读写数据”。即使你的系统规模不大，也建议养成这个习惯，因为大部分课程设计和毕业设计答辩，老师都会看项目结构和代码规范。

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是审核拒绝。两个字段配合使用，管理员审核通过后的房源才会自动变成上架状态，这样能很好地在答辩时演示管理员审核流程。状态字段的取值建议用常量类统一定义，比如HouseStatusEnum，不要散落在代码里的各种魔法数字中。

2.3 预约看房与成交订单：流程要能追溯

预约看房是销售转化的重要节点。这个场景最容易踩的坑是：发现只在表里记录一个预约时间，后续的流程无法扩展。预约表至少要包含这些字段：房源id、客户id、销售id、预约类型（线上咨询或线下看房）、期望看房时间、实际看房时间、状态、备注、创建时间。

状态流转建议这样设计：待确认（预约提交，销售人员未处理） → 已确认（销售同意本次看房） → 已完成（线下看房结束） → 已取消。每一步的变更都应该记录操作时间，这样答辩时老师问“你怎么追踪用户的看房进度”，你就可以清晰回答：通过预约表中的状态字段和更新时间来追踪，并且销售人员的操作都会写入日志。

成交订单表则对应最终交易，核心字段包括订单编号、关联房源id、关联客户id、关联销售id、成交金额、定金状态、合同编号、创建时间等。订单编号不要用自增id，建议生成一个类似FK202506071030001的字符串序列号，前期可能看不出差别，但当系统需要导出报表或线下核实时，这种可读编号比数字id方便得多。

2.4 数字化营销：收藏、浏览记录和营销活动表

既然题目强调“数字化楼盘营销平台”，营销相关数据不能完全缺席。不然题目里那部分价值无法体现，答辩时也说不出亮点。

设计一张user_favorite表来保存用户的收藏。字段包含用户id、房源id、创建时间，建议用联合唯一索引保证同一用户不能重复收藏同一个房源。再设计一张house_view_log表保存用户的房源浏览足迹，用于后续推荐逻辑和后台统计。浏览表只做插入，不用做唯一约束。

真正支撑“数字化营销”的是统计逻辑。你看后台需要展示三个维度的数据：今日新增咨询量、预约看房转化率、各房源浏览量排名。这些数据从哪里来？就是从收藏表、预约表和浏览日志表里查询聚合得到。如果每次都实时统计，数据量大时会变慢，但毕设规模下完全没问题，先不加缓存就足够。

至于更复杂的营销活动，比如满减优惠、定向折扣、优惠券，可以放到最后看时间是否充裕再决定加不加，优先级比较低。守住核心链路，比堆功能更能让你的系统完整可用。

3. 后端核心模块实现：代码怎么写才能逻辑清晰

3.1 统一返回结果与全局异常处理

写后端接口最容易出现的风格问题是：有的接口返回Map，有的接口直接返回实体类，有的接口返回null，前端对接时完全没法判断成功还是失败。建议项目启动后第一件事就设计统一的返回结果类。

一个典型的Result<T>包含三个基础属性：code、message、data。成功时code为200，业务失败时code可以定义为500，参数校验不通过时可以是400，登录失效为401。配套的静态方法通常是Result.success(data)、Result.fail(msg)。有了它，所有Controller方法的返回值都统一成Result<?>，前端只要判断code是否为200就可以决定后续操作。

单单有返回结果还不够，必须再把全局异常处理器加上。使用@RestControllerAdvice注解定义一个Controller增强类，在类内部定义不同的异常处理方法：BizException处理业务异常，MethodArgumentNotValidException处理参数校验异常，Exception兜底处理未知异常并返回友好提示。这样做的好处是，你业务代码里出现异常时，不需要在每个方法里try-catch，系统会自动将异常转成标准格式返回前端，同时打印error日志供排查。

3.2 登录鉴权基于JWT与拦截器实现

毕设项目的登录鉴权，我不建议一上来就引入Spring Security全家桶，它的过滤器链对学生来说很不友好，搜索问题也容易找到跟你版本不匹配的示例。更可控的做法是自己实现JWT + 拦截器。

用户登录成功后，后端生成一个JWT令牌，令牌里面携带userId和用户名，设置过期时间，返回给前端。前端将token存储到localStorage里，在每个请求的header中带上Authorization: Bearer token。后端定义一个拦截器，在preHandle里对需要认证的路径进行令牌校验，校验通过后把userId解析出来存入ThreadLocal或者Request attribute中，后续业务代码即可直接获取当前登录用户。

有几个细节需要注意：拦截器要排除登录接口和访问首页资源的路径，比如/api/auth/login、/api/house/list这些公开接口，避免用户没登录就没法浏览。对“我的收藏”、“我的预约”这类接口，拦截器必须生效。另外JWT的密钥不要硬编码在代码里，写进application.yml配置中，答辩时还能解释一下“配置与代码分离”的思想。

有一点必须说明：JWT一旦签发很难在服务器端主动失效，所以如果系统需要“管理员封禁用户后立即让该用户无法访问”这种能力，需要在拦截器中额外查一次用户状态。如果不查，被封禁用户仍然可以继续访问，直到token过期。建议在拦截器中只做解析和过期判断，白名单管理再配合一份内存/数据库配置即可。

3.3 房源条件检索与分页：SQL上的细节决定性能

房源列表页是访问频率最高的接口。支撑“按区域”、“按价格区间”、“按户型”进行筛选，以及关键词模糊搜索，对应SQL条件是拼接动态查询。使用MyBatis-Plus的LambdaQueryWrapper可以很优雅地完成查询条件构造。

举个例子，查询条件包含城市city、最大价格maxPrice和关键词keyword，代码如下：

java复制LambdaQueryWrapper<House> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(StringUtils.isNotBlank(city), House::getCity, city)
       .le(maxPrice != null, House::getPrice, maxPrice)
       .and(StringUtils.isNotBlank(keyword), qw -> qw
           .like(House::getTitle, keyword)
           .or()
           .like(House::getAddress, keyword));
wrapper.eq(House::getStatus, 1);
wrapper.orderByDesc(House::getCreateTime);

Page<House> page = new Page<>(pageNum, pageSize);
houseMapper.selectPage(page, wrapper);

这段代码很好地把“可选条件”封装成了动态查询。特别注意le方法只有当maxPrice不为空时才会拼接小于等于条件，避免前端不传价格导致SQL条件为空，这个细节经常有人忽略。另外要强调：列表接口不要一口气把房源的全部字段查询出来，尤其图片列表和描述信息都是text字段，非常占带宽。此时你需要用Page<HouseVO>的方式，通过select指定要返回的字段，或者在实体类对应字段上使用@TableField(select = false)自动排除。

分页查询出来的结果，建议返回给前端的数据中包含“总记录数、总页数、当前页、列表数据”四个部分，这样前端分页组件才能正常工作。排序规则使用创建时间倒序，让最新上架的房源排在前面；当浏览数很高时，可以切换成按浏览量倒序，后台运营时用得上。

3.4 预约看房的状态流转与防重复提交

预约功能看起来只是插入一条数据，但真正要做好，还得回答几个问题：同一客户能否预约同一个房源多次？销售确认后客户能否取消？客户到时间没来怎么记录？

我设计的规则是：同一用户对同一房源，如果已存在一个“待确认”或“已确认”状态的预约，就不能再次提交预约，防止销售被重复打扰。判断代码置于事务方法中：

java复制// 在插入新预约之前查一次
long count = appointmentMapper.selectCount(new LambdaQueryWrapper<Appointment>()
        .eq(Appointment::getHouseId, houseId)
        .eq(Appointment::getCustomerId, currentUserId)
        .in(Appointment::getStatus, Arrays.asList(0, 1)));
if (count > 0) {
    throw new BizException("您对该房源已有进行中的预约");
}
Appointment appointment = new Appointment();
appointment.setStatus(0);
appointment.setCreateTime(new Date());
appointmentMapper.insert(appointment);

这个判断需要放在带有@Transactional注解的方法中。但有一点要提醒自己：即使是事务方法，也无法在高并发的极端情况下百分百防止重复插入，除非给表加唯一索引。毕设场景里并发很低，通过先查后插已经足够，不用过度设计分布式锁。

当销售确认预约后，需要给客户一个可感知的状态变化。很多系统只改了字段，页面没动静，用户会以为提交失败。所以我会在状态更新后，将联系人姓名和电话在“已确认”状态时返回给前端展示，体验好得多。对于超时未到达的预约，可以提供一个“标记爽约”按钮，由销售人员操作，爽约次数在客户详情页统计展示。

3.5 后台管理统计接口的设计思路

营销平台必须要有数据看板，后台首页通常会展示几个仪表盘统计卡片和柱状图、折线图。后端需要准备的统计接口如下：

• 统计总房源数、上架房源数、下架房源数。
• 统计今日新增用户数、今日新增预约数。
• 统计近7日预约量走势。
• 统计每个销售的房源成交金额排行。

实现时不必写复杂的SQL，MyBatis-Plus的聚合查询即可完成多数统计。以近7日预约量为例，先把7天的日期区间算好，然后小于该区间末端且大于起点的所有预约记录，通过group by DATE_FORMAT(create_time, '%Y-%m-%d')按日期分组，再用List封装返回。需要注意MySQL的日期函数，如果你在SQL里用了日期函数，结果集中要取到日期这个字段，否则前端画图没有横坐标。

返回给前端的格式建议统一为两个数组：日期数组和数据数组，方便ECharts直接接收。或者你可以返回一个List对象，每个对象包含date和count两个字段，前端再做一次映射。我个人比较推荐返回一个结构化对象，前后端的分工更清晰，面试介绍项目时也更有说法。

3.6 事务控制与MyBatis-Plus的坑

事务非常重要，尤其在一个业务操作涉及多张表时。发布房源并给统计表插入一条记录、确认预约并减少该房源的库存、删除用户时同时清除他的收藏，这些都是典型的多表操作。我建议你在Service类的public方法上添加@Transactional(rollbackFor = Exception.class)注解，注意rollbackFor这个参数不能省。

默认情况下Spring事务只回滚RuntimeException和Error，如果代码抛出了受检异常，事务不会自动回滚，数据会出现一半成功一半失败的情况。加上rollbackFor=Exception.class，才能对所有异常都回滚。这是答辩时的高频加分点，你可以主动演示一次。

另外一个常见坑是MyBatis-Plus的updateById方法默认不更新值为null的字段，导致某个字段想清空为null时怎么都更新不了。解决方案是在实体字段上添加@TableField(updateStrategy = FieldStrategy.IGNORED)，或者使用UpdateWrapper显式调用.set(字段, null)条件，具体方法选择要看业务是否需要频繁将字段置空。实际项目中更建议用UpdateWrapper方式，灵活且不影响全局配置。

4. 实操落地：从零把项目跑起来

4.1 环境版本组合与工具清单

动手写代码之前，先检查好自己的环境。我建议一套经过验证的组合如下：

• JDK 1.8（如果你的系统不是老机器，使用JDK 11也只是小幅调整）
• Maven 3.8.x
• IDEA 2023及以后版本
• MySQL 5.7或8.0
• Redis（可选，如做验证码缓存和session存储，则建议加）

这一套组合的兼容性问题最少。网上大量报错都源于JDK和SpringBoot版本不匹配，比如SpringBoot 2.1与JDK 11在CGLIB代理方面会出问题。你最好先执行java -version确认JDK版本，再创建项目。

4.2 使用IDEA初始化SpringBoot项目

创建项目时，推荐使用Spring Initializr。在IDEA中选择Spring Initializr，填写Group和Artifact，然后选择SpringBoot版本。依赖上勾选：Spring Web、MyBatis Framework（如果你用MyBatis-Plus，可以不用官方MyBatis，改用自定义增加）、MySQL Driver、Validation、Lombok。

你如果使用MyBatis-Plus，需要在pom.xml中手动添加依赖。其中和SpringBoot 2.7匹配的版本是MyBatis-Plus 3.5.3左右。建议在依赖管理里使用如下坐标：

xml复制<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-boot-starter</artifactId>
    <version>3.5.3</version>
</dependency>

这里有一个容易出问题的地方：不要同时引入mybatis-spring-boot-starter和mybatis-plus-boot-starter，两者的自动建号和SqlSessionFactory配置会互相冲突，导致项目启动时报循环依赖或找不到SqlSessionFactory。

4.3 application.yml中的关键配置

配置文件的书写决定了项目能不能在本地顺利连接数据库。一个常用模板如下：

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&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true
    username: root
    password: root

mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
    map-underscore-to-camel-case: true
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

url中serverTimezone=Asia/Shanghai不能省略，否则MySQL 8会报时区错误。useSSL=false也很重要，因为MySQL 8默认开启SSL，如果你本地没有配置SSL证书，连接时大概率会收到警告或异常。allowPublicKeyRetrieval=true在MySQL 8中使用caching_sha2_password认证时经常需要。

MyBatis-Plus配置项中，将map-underscore-to-camel-case设置为true可以让数据库字段create_time自动映射到Java实体类属性createTime，不用手动写注解。如果你的表字段全部采用下划线风格，这个配置能让代码简洁很多。逻辑删除配置建议开启，在表中添加deleted字段，可以有效防止误删业务数据，也方便保护用户记录。

4.4 接口调试与Swagger配置

接口调试阶段，Postman当然够用，但在C层和V层之间同步API文档比较麻烦，我建议开发期集成Swagger。SpringBoot 2.7中Swagger可以选用springfox 3.0，或者直接使用knife4j（基于Swagger增强的API文档工具）。knife4j的页面比Swagger UI清爽，而且天然支持Controller分词和接口搜索，能极大提升自测效率。

配置knife4j时你需要在pom中引入依赖，然后写一个OpenAPI配置类，声明应用标题和描述，并设置全局的Authorization参数，这样你登录后只要在文档页面填一次token，所有需要鉴权的接口都能直接调试。答辩时现场演示登录并调用受保护接口会非常流畅。

4.5 使用Maven打包与本地运行

项目写完后，执行以下命令打包，这也是答辩准备阶段的必做步骤：

bash复制mvn clean package -DskipTests

打包完成后，target目录下会生成一个可执行jar包，运行：

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

这样就能以“线上生产环境”的方式启动项目，而不是依赖IDEA运行。也可以把jar包和启动脚本直接放到一台服务器上进行展示。

如果你只是本地演示，IDEA一键运行是最方便的。但我更建议你在答辩前至少模拟一次服务器部署：因为在IDEA中运行时加载的classpath和服务器上运行jar包时有些细微差异，比如静态资源路径大小写问题、上传文件目录问题，提前模拟可以避免答辩当天的翻车事故。

5. 常见问题排查与解决实录

5.1 Maven依赖导入失败或下载慢怎么处理

Maven中心仓库在国内访问速度不稳定，依赖下载失败最常见的表现就是pom文件里大量红色波浪线。解决方式有两个：一是阿里云Maven镜像，在settings.xml中加入：

xml复制<mirror>
    <id>aliyunmaven</id>
    <mirrorOf>*</mirrorOf>
    <name>阿里云公共仓库</name>
    <url>https://maven.aliyun.com/repository/public</url>
</mirror>

二是IDEA中右键项目选择Maven -> Reload Project，强制重新加载。如果还不行，最好删除本地仓库中对应的lastUpdated文件，再reload一次。很多同学改了settings.xml还是无法解决，就是因为本地仓库的失败缓存没有清理干净。

5.2 MySQL连接失败：时区、SSL和驱动类名

这类错误高频出现在MySQL 8版本上。异常里如果包含Server returns invalid timezone，说明需要添加serverTimezone参数；如果连接建立后提示Public Key Retrieval is not allowed，说明需要在url中加入allowPublicKeyRetrieval=true。另外驱动类名也要注意，MySQL 8对应com.mysql.cj.jdbc.Driver，而MySQL 5.x用的是com.mysql.jdbc.Driver，用错会导致ClassNotFoundException。

我自己调试项目时会先打开MySQL命令行，用相同账号密码执行select 1确认账号本身能连接，排除MySQL服务没启动的问题。Windows系统上MySQL经常因为服务没启动导致项目连接拒绝，这种错误最容易浪费人时间。

5.3 端口占用与路径404

SpringBoot默认端口是8080，如果本地装了其他服务占用8080，项目会报Port already in use。你可以通过命令找出占用8080的进程并结束，也可以直接在application.yml中换一个端口，比如8088。

另一个常见问题是部署后访问页面一直404。这里要区分两种情况：如果你用的是Thymeleaf，Controller返回的是视图名称，请求URL不匹配return值就会404；如果你用的是前后端分离，后端接口路径全部带/api前缀，前端代理没配置好也会404。检查的第一步，是打开浏览器开发者工具的Network面板看请求是否真的发出、实际访问路径是什么，这个习惯比反复猜题高效得多。

5.4 前端页面跨域问题

前后端分离部署时，Vue页面运行在localhost:5173，后端运行在localhost:8080，前端直接访问后端接口会触发同源策略。解决方法有很多，推荐在后端写一个配置类实现CORS跨域。

这里有一个细节必须注意：如果你同时使用了拦截器做登录校验，跨域预检请求（OPTIONS请求）需要在Interceptor中直接放行，否则浏览器发送OPTIONS请求时会被拦截器拦截，导致正常GET请求无法携带鉴权头。

java复制@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
    if ("OPTIONS".equalsIgnoreCase(request.getMethod())) {
        return true;
    }
    // 其余鉴权逻辑...
}

5.5 分页查询不准或统计出错的常见原因

分页数据不准确，多半是MyBatis-Plus分页插件没有配置。使用MyBatis-Plus时只在pom里引入依赖还不够，还需要设置一个分页拦截器：

java复制@Configuration
public class MybatisPlusConfig {
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));
        return interceptor;
    }
}

如果不配置分页插件，看似调用了selectPage，实际返回的列表并不会真正分页，甚至返回全部数据。这个问题极其隐蔽，因为程序不报错。项目里可以先写一个测试接口，故意把pageSize设为1，看看返回的列表长度，如果为所有记录总数，就说明分页插件没有生效。

统计结果不准，则要重点检查时间字段的类型。MySQL的datetime类型和Java侧的LocalDateTime在进行范围查询时，建议使用ge和lt而不是like字符串，否则可能出现前1天数据统计重叠的问题。另外，把时间初始化和时区类型统一成一个标准，能避免极多线上统计误差。

5.6 事务失效、序列化、字段命名等隐蔽问题

事务失效是很隐蔽的问题。最常见的场景是在Controller中调用两个Service方法，而不是在一个Service方法内部完成两个操作。事务代理机制只在进入Service方法时生效，如果你从Controller直连两个不同的Service方法，第一个方法的事务提交后第二个方法失败，不会滚回第一个方法。所以多表更新逻辑要主动聚合到一个Service方法中，而不是放在Controller中编排。

还有一个小问题，使用Lombok的@Data注解时，如果实体类字段是isHot这种布尔类型，Lombok生成的getter方法名叫isHot()，MyBatis映射可能存在偏差。建议避免使用is开头的布尔字段，命名为hot或recommended配合@TableField注解就能避免这类问题。

序列化方面，LocalDateTime默认会被Jackson序列化为一串数字时间戳。要变成标准yyyy-MM-dd HH:mm:ss，需要在application.yml中配置：

yaml复制spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

不然前端拿到时间后无法直接展示，排版也难看。

5.7 数据初始化与演示数据的准备技巧

答辩演示时，如果数据库空空如也，页面展示效果会大打折扣。建议你在设计数据库时同步准备一份sql脚本，里面包含3到5个城市、10条以上房源、不同状态（上下架、审核、已售）、若干预约记录和用户。房源图片可以使用网络中免费的占位图或本地static目录下的示例图片，不要加载外链，因为答辩现场网络不一定稳定。

可以在项目的resources目录下加入db/init.sql，并在文档中写清楚如何执行初始化。这个小小步骤会让你的系统在别人电脑或服务器上部署时友好得多，因为很多老师检查项目时，第一步就是导入数据库脚本，你看上去的准备程度会直接拉开与其他同学的距离。

写在最后的实操心得

纵观整份SpringBoot房产销售系统开发过程，我最大的体会是：这类毕业设计项目难的不是某个技术点，而是把所有功能串起来的整体建模能力。一开始可能人人都能写一个“房源新增”接口，但当需求扩展到预约状态流转、统计报表、销售权限控制时，表结构设计的优劣就立刻暴露出来。前期少花一小时画表关系，后期可能要花一天改代码。

另外一个感受是：尽量在项目早期就在全局配置中把统一返回、全局异常、分页插件、跨域和Swagger搭好，再开始写业务接口。这个基础建设虽然不直接产生业务价值，但绝对是整个开发周期的效率催化剂。我自己带的很多学生，前期觉得这些是额外功夫，越写到后面越能理解其必要。

最后再分享两个容易被忽视的小技巧：项目里所有用到的时间字段最好统一由后端在Service层设置，不要依赖数据库的默认时间，否则批量插入和测试数据会出现时区不一致的问题；对房产这类涉及图片上传的系统，建议把上传目录配置成可配置项，而不是直接写死在代码里。这样你写完这个毕设，再想扩展成其他类似的管理系统时，几乎不用大改架构，只是换个业务骨架而已。