Java Spring Boot + 微信小程序：一套房地产销售管理系统的完整复盘

做毕业设计或者自己接外包项目，只要是涉及“房源管理 + 客户预约 + 销售跟进”这类场景，基本绕不开一套房销系统。最近刚好把我手头这一套基于微信小程序 + Spring Boot 的房地产销售管理系统从需求梳理到落地部署完整跑了一遍，实现了后台管理员对房源、户型、销售数据的统一管理，也实现了购房客户在微信小程序端浏览房源、在线预约看房、填写购房意向的功能。整体技术栈就是 Java + Spring Boot + MyBatis Plus + 微信小程序原生前端，是我认为目前做毕设项目或者中小型房销系统性价比最高的一套组合。

这篇文章我就把这套系统的完整思路、核心功能、数据库设计、关键代码逻辑以及我在实际部署和运行过程中踩过的坑，一次性全部梳理出来。不管是正在做这个课题的学生，还是想快速搭一套房销系统雏形的开发者，应该都能从里面拿到可以直接用的东西。

1. 项目整体设计与思路拆解

1.1 需求定位：这套系统到底在解决什么问题

先说业务背景。传统的房地产销售管理大多依赖销售顾问各自用 Excel 记录客户、用纸质台账登记房源信息，客户想看房得打电话问、约时间、再跑售楼处。一旦楼盘体量上来，几十套甚至上百套房源在各个销售手里流转，很容易出现这些问题：同一套房被两个销售重复登记、预约看房时间撞车、客户信息散落丢失、销售业绩月底统计对不上账。

这套系统的核心目标就是解决上面这些基层痛点。它面向三类角色：来浏览房源、提交预约的普通客户（小程序端）；负责管理房源、审核预约、处理订单的销售人员或运营人员（后台管理端）；以及拥有最高权限、看数据报表的系统管理员（后台管理端）。业务链路我梳理下来是这样的：管理员先在后台录入楼盘信息与楼栋户型数据，小程序端按区域、户型、价格等维度展示在售房源，客户看到感兴趣的房源后可提交“预约看房申请”，后台收到申请后分配给对应的销售顾问跟进，销售在线更新跟进状态（待联系、已联系、已成交、已失效），最终成交的数据沉淀成可统计的销售报表。

这么一拆，系统边界就很清晰了：小程序端不用管复杂的业务逻辑，只负责信息展示与自助预约；真正的业务流转全在后台管理端完成。这种前后端分离、职责清晰的架构，是最适合这个体量项目的设计方式。

1.2 技术选型：为什么是 Spring Boot + 微信小程序

技术选型从来不是越新越好，而是越合适越好。这套系统在后端选择了 Spring Boot 2.x，持久层框架用 MyBatis Plus，数据库用 MySQL 5.7，前端小程序则使用微信原生小程序框架开发。这套组合在选择时有几点明确考量。

第一，Spring Boot 极大降低了后端搭建成本。它内置 Tomcat，简化了依赖管理和配置方式。一个规范的 Java 后端项目，如果用传统的 SSM 框架手动整合，光 spring-context、spring-mvc、mybatis 这些依赖的版本匹配就够折腾半天，而 Spring Boot 通过 spring-boot-starter-parent 统一管理版本，起步就是 Web 项目跑通 Hello World。对于需要快速交付毕设或外包项目的场景，这是最大的效率优势。

第二，MyBatis Plus 让数据库操作回归简单。它内置了通用的 insert、delete、update、select 方法，单表 CRUD 基本不用手写 SQL。业务代码里常见的分页查询，只需要调用 selectPage 并传入一个 Page 对象即可。不过需要说明的是，一旦涉及到多表关联查询，比如查询房源列表时同时带出所属楼栋名称和户型图，我仍然会手写 SQL，而不是把全部逻辑堆在 Java 代码里做内存关联。

第三，微信小程序作为 C 端载体，最大的优势是零安装成本和天然的微信生态流量。客户在微信里搜索小程序或扫码即可打开，无需下载 App，对不熟悉智能手机操作的中老年购房群体非常友好。小程序提供的登录能力（wx.login 获取 code，后端再通过 code 换取 openid）也免去了自己手机号验证码注册登录的开发量。只要在微信公众平台注册一个小程序账号，下载微信开发者工具，就可以直接开发与调试。

1.3 模块划分与整体架构

系统按功能域划分为两层：

后端管理端（Web 管理后台 + RESTful API）包含以下模块：

• 管理员登录与权限拦截模块
• 房产信息管理模块（楼盘、楼栋、房源）
• 预约看房管理模块
• 客户信息管理模块
• 销售数据统计模块

小程序用户端包含以下页面：

• 首页（楼盘推荐、最新房源）
• 房源列表页（条件筛选）
• 房源详情页（户型图、价格、预约入口）
• 在线预约页（选择看房时间、填写联系方式）
• 个人中心（我的预约、收藏）

为了把这两个端串联起来，后端对外提供一套统一的 RESTful API，所有接口都返回统一的 JSON 结构：{ code: 200, message: "success", data: {...} }。小程序端通过 wx.request 与后端进行数据交互。架构上大致是“小程序客户端 → Nginx/直接访问 → Spring Boot API 服务 → MySQL 数据库”，开发阶段可以直接用 IP + 端口访问，生产部署再加一层 Nginx 转发。

这样设计的价值在于：小程序端只关心页面渲染和用户交互，所有权限校验、数据校验、业务状态流转都在后端完成，避免把业务规则散落到前端导致同一个规则在多端出现不一致的情况。

2. 数据库设计：一张表一张表地讲清楚

2.1 核心业务表关系

数据库设计是这类管理系统的地基。我把它拆成了 8 张核心表：管理员表、用户表（小程序端客户）、楼盘表、房源表、户型表、预约看房表、收藏表、留言反馈表。其中楼盘与房源是一对多关系，房源与户型是多对一关系，用户与预约是一对多关系，用户与收藏是多对多关系（通过收藏表关联）。

我建表的思路遵循几个原则：

• 凡是业务上有归属关系的数据，用外键字段关联而不是直接存冗余文本。例如房源表存 building_id（所属楼盘 ID），这样后台可按楼盘维度统计。
• 状态字段用 int 或 tinyint 存储，而不是字符串。因为字符串状态容易写得不一致（比如“已联系”和“已联系 ”带空格），用数字常量在代码里做枚举映射更可控。
• 创建时间、更新时间统一用 datetime 类型，并且由后端代码统一填充，不依赖数据库触发器，便于以后迁移或做数据同步。

2.2 房源表与预约表的设计细节

房源表是整个系统信息量最大的表。我设计的字段包括：

• id、house_name（房源名称，如“A栋1单元302”）
• building_id（关联所属楼栋）
• house_type_id（关联户型）
• cover_image（封面图）
• area（面积，单位平方米）
• price（总价，单位元）
• unit_price（单价，单位元/平方米）
• decoration（装修情况：毛坯/简装/精装）
• orientation（朝向）
• floor（所在楼层）
• status（销售状态：在售/已预定/已售）
• detail（房源描述）
• create_time、update_time

在设计时，我把 price 和 unit_price 都设置成 decimal(12,2) 而不是 int。原因是房产交易中的金额没有“整数化”的硬需求，保留两位小数便于后续按折扣或分期方案计算。千万不能把金额存成 float，否则在做累计比较时可能出现精度问题。

预约表 house_appointment 的字段包括：id、user_id、house_id、appointment_time（计划看房时间）、contact_name、contact_phone、status（待确认/已联系/已完成/已取消）、remark（备注）、create_time。这张表是连接 C 端客户和 B 端销售的核心表。销售在后台看到一条新的预约记录后，即可电话联系客户，并在系统中把状态推进到下一阶段。通过这张表，我可以在后台很自然地实现“每位销售的跟进列表”，后续统计销售转化率时，只要按预约的最终成交状态汇总即可。

2.3 我踩过的设计坑：为什么最后加了户型表

第一次开发这类系统时，我把户型信息（几室几厅、建筑面积、参考总价）直接放在房源表里，结果录入数据时苦不堪言：同一个楼盘的同一个户型，在不同楼层、不同房号上重复录入十几条，而且一旦户型面积需要调整，就要逐条更新房源数据，容易漏改，还容易出现同一楼盘同户型价格不一致的脏数据。

后来我单独抽了一张户型表 house_type，记录 id、building_id、name（如“三室两厅两卫”）、area、layout_img（户型图）、description；房源表只保留 house_type_id 外键。这样带来的最直接好处是房源录入效率大幅提升——销售团队新建房源时只需要选择已有户型，再补充楼