做房产中介管理系统这套毕设之前我先把中介行业的日常业务捋了一遍。房源、客户、带看、签约四条线穿成一个大闭环系统本质上就是一个帮中介老板把“人在干活”变成“系统管事”的管理工具。用 Java SpringBoot 来落地这套全流程管理系统是当前技术栈里相当顺手的选择既能覆盖 Spring Boot 框架在业务开发中的常见用法又能体现数据库设计、权限控制、事务处理这些基本功。这篇博文就围绕这个毕设项目把业务拆解、功能设计、技术实现和踩坑排查完整过一遍给正在做类似管理系统选题的同学一个能直接参考的全流程模板。我一直有个观点毕设的价值不在“做了几个页面”而在“能不能把业务逻辑说清楚并且把技术选型的理由讲明白”。房产中介管理系统刚好是这种能全面展示开发能力的选题因为它既有复杂的关联关系又有明确的角色权限和状态流转适合用来证明你对 Java 后端的理解和工程实践能力。1. 这个系统到底要解决什么问题1.1 中介业务的完整链路分析我上手之前先花了两天时间泡在中介门店里和做房产经纪的朋友聊实际工作流程。中介日常运转遵循一条明确的业务链业主来挂牌委托房源进入系统客户上门咨询经纪人登记求购需求然后经纪人把房源和客户匹配安排线下带看客户看中之后进入价格谈判谈成则签订合同、收取佣金成交之后还要做售后跟进。这样一条链路看似简单手工用 Excel 也能维护但一旦房源数量上百、经纪人有十几个问题就全暴露了同一套房源被两个经纪人重复跟进客户客户被不同经纪人来回电话骚扰业绩归属扯不清楚经理想统计本月带看量还得挨个问。所以这套系统需要解决的绝对不只是“录数据”而是把业务状态管起来让每一步都有迹可循、有据可查。系统最终定位成三个核心闭环房源从挂牌到成交的房源闭环客户从登记到成交的客户闭环以及经纪人从接单到业绩结算的人员闭环。三个闭环互相咬合主导了后续所有表结构设计和状态字段设置。1.2 功能清单与角色权限拆解基于上面的业务链路我梳理出系统的功能需求按照角色维度拆分最清楚因为不同岗位接触的资源完全不同。管理员老板/店长需要查看全店运营数据管理所有员工账号审核房源挂牌查看成交订单和佣金账单常用功能是统计报表。经纪人业务员核心职责是房源和客户的跟进维护。需要录入新盘、修改房源状态、登记客户、记录每一次跟进电话、申请带看、提交成交意向。店长主管比普通经纪人多了带看审核、房源分配、业绩查看的权限相当于业务之间的管理枢纽。这样拆下来系统的功能模块就一目了然我在设计数据库和接口时都按照角色来判断权限边界。角色权限用一张role表加一张user_role关联表就够了走 RBAC 模型简单实用也好答辩解释。功能清单主表模块功能点说明房源管理房源增删改查、上下架、审核房源状态贯穿整个交易流程客户管理客户档案、需求标签、跟进记录客户来源统计和需求匹配带看模块带看申请、带看记录、结果反馈连接房源和客户的关键动作合同管理合同创建、审核、归档成交后生成佣金账单员工管理账号、角色、门店、状态后台账号全生命周期管理数据统计业绩排行、带看量、转化率用图表辅助决策表格列出来之后系统的开发边界就清晰了。接下来选技术路线时我首先考虑的是后续扩展和毕设论文的写作空间SpringBoot 在这两方面都比较友好。2. 技术选型与架构设计SpringBoot 为什么是正解2.1 框架选择背后的理由这套系统当时也纠结过用 SSHStrutsSpringHibernate还是 SpringBoot。对比之后果断选了 SpringBoot核心原因有三个。第一开发效率压倒一切。毕设有明确的时间节点SpringBoot 的自动配置把大量重复配置直接省掉。以前 SSH 时代要写一堆 XML 配置现在一个application.yml就能搞定数据源、端口、日志级别。内嵌的 Tomcat 也让部署变得非常简单本地打包成一个jar直接跑不用折腾外置容器。第二SpringBoot 是当前 Java 就业市场的绝对主流。去招聘网站逛一圈Java 后端岗位要求里出现频率最高的框架就是 SpringBoot。做这个毕设不仅是为了毕业更是在提前积累工作用的技术栈。面试时跟面试官聊 SpringBoot 项目对方天然会有共鸣。第三生态配套成熟。数据库层用 MyBatis Plus 操作 MySQL缓存用 Redis权限用 Spring Security 加 JWT这些都是 SpringBoot 生态内的标准套餐。遇到问题网上社区资料海量不会卡在环境配置上出不来。技术栈最终锁定了SpringBoot 2.7.x、MyBatis Plus 3.5.x、MySQL 8.0、Redis 2.6.x、Spring Security JWT、Vue 3 Element Plus 做管理端页面。这套组合在毕设和中小型项目中都是比较成熟可靠的搭配。2.2 数据库表设计的关键取舍数据库设计是这套系统的地基我这里花了比较多心思因为后面所有功能好不好写全看表建得好不好。一共设计了十几张表核心几张表的结构思路说一下。房源表house是全系统的数据核心字段要尽量完整但也不能一味堆。我的建议是区分“描述字段”和“业务字段”描述字段包括小区名称、户型、面积、楼层、朝向、装修情况业务字段包括房源编号、所属门店、录入经纪人 ID、审核状态、出售/出租状态、价格。特别注意加一个house_status字段用数字表示状态比如 0 待审核、1 已上架、2 已成交、3 已下架状态流转是后面业务逻辑的开关。为什么用数字而不是字符串因为状态判断走整数比较最稳也方便前端做字典翻译。客户表customer必须记录客户需求画像求购区域、预算范围、户型偏好、购房目的。这些字段直接服务后面的“智能匹配”功能。作为毕设智能匹配可以用最朴素的方式实现house表里的小区、价格、户型和customer表里的需求做 SQL 条件拼接不需要上什么算法。带看表inspection是很容易被忽略的一环但它其实是房源和客户之间的连接器。一个房源可能被带看多次一个客户也可能带看多套房所以这是一张典型的多对多关联表并且要额外记录带看时间、参与经纪人、客户反馈。有了这个表后面做数据统计时才能算转化率。合同表contract记录成交信息核心字段包括关联房源 ID、关联客户 ID、成交价格、佣金比例、佣金金额、签约日期、合同状态。这里涉及事务处理签约动作要同时更新房源状态为客户已购、生成佣金账单、记录成交时间必须放在一个Transactional方法里执行后面我会专门讲。用一句话总结数据库设计经验设计表之前先画流程流程上的每个节点都有对应的表节点与节点之间的连接动作建关联表。这样做出来的数据库结构答辩时顺着流程讲逻辑非常顺。2.3 前端方案选型与前后端对接前后端方案是一个让不少人纠结的点。我当时选择了 Vue 3 Element Plus 做管理端界面开发时前后端分离各自独立调试。前端工程用 Vite 构建开发环境通过代理转发请求到后端8080端口避开跨域问题。这里有一个毕设项目里很实用的部署技巧如果学校要求最终只交一个可运行的工程可以走前后端打包集成路线。先用npm run build把 Vue 项目打包成静态资源然后把生成的dist目录扔进 SpringBoot 的src/main/resources/static下后端同时提供 API 和页面访问打成一个 jar。这样演示时一条命令启动不需要前端二次构建。不过纯粹的毕设演示我更推荐另一种方式后端接口文档用 Swagger 生成前端跑在独立端口本地演示时开两个窗口即可。打包集成方案适合最终提交本地开发还是前后端分开舒服。提示前后端分离开发时CrossOrigin注解虽然能解决跨域但别每个 Controller 都加。写一个全局的 WebMvcConfigurer 实现 CORS 配置统一管理代码看起来专业得多。3. 核心功能模块的实现细节3.1 房源管理模块从录入到状态流转房源管理模块是系统的门面也是我第一个动手写的模块。录入房源时前端表单收集小区、地址、户型、面积、朝向、楼层、价格等基础信息上传户型图走文件上传接口后端接收后把图片路径存到数据库实际图片存在服务器的独立目录。房源状态流转是整个模块的重中之重。我用状态机思想来做状态管理定义这一个流转规则经纪人录入房源状态为0 待审核店长/管理员审核通过状态变为1 上架中客户成交或业主要求下架状态变为2 已成交或3 已下架在代码里状态流转不能只靠前端按钮控制后端接口要做校验。比如状态从待审核直接跳到已成交这是不合法的业务操作必须在 service 层拦截。我当时写了一个HouseService.changeStatus()方法接收房源 ID、目标状态、操作人 ID内部用 switch 判断当前状态是否允许跳转到目标状态不允许就抛业务异常。这个做法在后期写论文和答辩时特别好讲。我答辩时直接说“系统采用状态机管理模式每个状态明确前置条件和后置动作”评委听得很认可。关于列表查询还有一个小细节值得说。房源列表页必然要支持多条件搜索我直接用 MyBatis Plus 的 LambdaQueryWrapper 拼条件。重点来了像价格区间、面积区间这种要用ge和le组合而不是简单的eq。关键词搜索时用like匹配标题和小区名称搜出来的结果集要按更新时间倒序排序保证最近录入的房源排前面。3.2 客户管理与跟进记录把粘性做出来客户管理如果只做一个 CRUD那就太浪费这个选题了。实际中介业务里客户的价值在于跟进所以我特意做了一个“跟进记录”子功能让它成为客户模块的亮点。设计上follow_record表记录每次与客户的交互内容包括联系方式电话、微信、到店、沟通摘要、下次跟进时间、跟进人。每个客户创建时自动生成一条“首次登记”记录之后每次沟通都往里追加。前端页面上客户详情里可以按时间轴查看一条客户从线索到成交的全部交互历史。这个设计解决的实际问题是“客户资源被闲置”。系统可以随时筛选出“超过7天没有跟进记录”的客户列表提醒经纪人捡起沉睡客户。这个查询在业务上很实用我把它做成了一个高级检索条件也是数据统计模块的数据来源。客户模块还有一个业务点需要处理客户隐私。客户的电话号码不能直接明文显示在所有列表页我做了脱敏处理列表页展示138****5678点击“查看详情”并且当前登录用户是该客户的负责人或其上级才能看到完整号码。这点虽然代码量不大但是能体现你的业务敏感度答辩时也是一个加分细节。3.3 带看预约与成交模块核心业务的代码落地带看是房源与客户的“第一次物理接触”业务上非常关键。带看模块流程是这样的经纪人选择一套房源、一个客户填写带看时间、预计报价提交申请店长审批后生成带看单带看结束后经纪人回填带看结果看中还是未看中客户反馈是什么。这段逻辑里最有价值的是审批流设计。同样走状态流转inspection表加一个audit_status字段0 待审批、1 已通过、2 已拒绝、3 已完成。店长审批通过后才能进入带看执行阶段回填结果后会同步刷新房源和客户的跟进记录。成交模块则必须处理好几件事的联动一致性。签约动作发生在用户点击“成交”按钮之后我在ContractService.createContract()方法上加了Transactional方法内依次执行创建合同记录写入成交价格和佣金金额更新房源状态为已成交更新客户状态为已购生成一条佣金账单记录给该房源和客户各追加一条跟进记录这里不开启事务会出大问题。如果先改房源状态、再生成账单时出现异常房源变成已成交但账单没生成数据就不一致了。面试或答辩问到事务的应用场景这正是一个好例子。4. 权限控制与安全性设计不能只有登录功能4.1 基于 JWT 的认证流程很多毕设的权限控制就做了个“登录成功跳主页”这远远不够。房产中介系统的数据敏感不同角色的访问边界必须清楚所以我用了 Spring Security JWT 的组合做认证授权。登录流程是这样的前端提交用户名密码后端校验通过后用JwtUtil生成一个包含用户 ID、用户名、角色标识的 token返回给前端。前端把 token 存在localStorage里之后每次请求都在Authorization头带上Bearer token。后端通过过滤器解析 token取出用户信息放入 SecurityContext。JWT 的好处是服务端无状态不需要在 session 里存用户记录这也为前后端分离部署提供了基础。但要注意一点JWT 无法主动失效用户退出登录只能依赖前端删除 token。这个特性有隐患为了弥补我用 Redis 做了 token 黑名单。退出登录时把 token 的 jti 加入 Redis 黑名单并设置过期时间后续请求过来先查黑名单命中就拒绝访问。4.2 角色权限控制的落地姿势配合 JWT接口层用 Spring Security 的方法级注解做细粒度权限控制。比如PreAuthorize(hasRole(ADMIN))标注管理员专属接口PreAuthorize(hasRole(AGENT))标注经纪人操作接口这样一来就算前端把某个按钮藏起来恶意用户直接调用接口后端照样拦截。这是一个必须强调的安全意识。管理系统的所有数据操作都应该以“接口安全”为准而不是“界面是否展示”。我在设计时把接口访问权限清单做成一张表自己先对照检查了一遍确保没有漏开发。4.3 数据权限经纪人只能看自己的客户比接口权限更进阶的一层是数据权限。同一个店里普通经纪人应该只能看见自己录入的房源和客户而不应该看到其他经纪人的业务数据。这个需求很现实不做好就会出现经纪人之间互相抢单的问题。我用一个笨但有效的方式处理房源和客户表都带owner_id字段查询时如果当前用户角色是普通经纪人MyBatis Plus 的查询条件自动拼上owner_id 当前用户ID。管理员和店长则不做限制。实际写代码时我封装了一个DataScopeInterceptor根据当前用户角色动态拼接 SQL 条件所有查询接口统一走这个拦截器避免每个 service 里重复写。这种做法我后来在工作中的项目里也还见过类似思路。作为毕设能主动考虑到数据权限这一层已经超出大多数人不少。5. 实操过程中的坑与排查记录5.1 SpringBoot 版本与依赖冲突问题项目刚开始搭建时我在 SpringBoot 版本上踩了一个很明显的坑。当时图新鲜选了 SpringBoot 3.x结果发现和国内大量教程里的 MyBatis Plus 示例不兼容很多配置类的代码需要改写白白浪费时间。后面果断退回 2.7.x生态资料最丰富遇到问题一搜就有解法。依赖管理这里要提醒一下切不要一股脑把所有 starter 都加进来。比如你不做消息队列就没必要引spring-boot-starter-amqp多余的依赖只会增加启动时的组件扫描负担甚至引起冲突。项目需要什么组件就加什么 starter保持最小依赖集。5.2 MyBatis Plus 自动填充带来的小插曲用 MyBatis Plus 时我设想过用MetaObjectHandler做创建时间和更新时间的自动填充但最初全局策略配置没到位导致两个问题更新数据时update_time不更新插入数据时create_time是 null。后来排查发现是实体类字段上少了TableField(fill FieldFill.INSERT)这样的注解MetaObjectHandler 根本没有被触发。调整后还要注意数据库表字段名是下划线风格create_time实体类属性是驼峰风格createTime必须在application.yml里配置map-underscore-to-camel-case: true否则查询结果映射不出来。这个是 MyBatis 常见的基础问题但也是很多人第一次跑项目到处报错的根源。5.3 跨域配置的三种姿势对比前后端分离开发时跨域是最先遇到的头疼问题。我试过三种方式做个对比总结方式场景优缺点CrossOrigin注解单个接口简单但不统一每个接口都要加全局 WebMvcConfigurer整个项目推荐一次配置全项目生效Nginx 反向代理生产部署运维层面最优雅但毕设阶段没必要前端 Vite 开发时也可以用代理解决但最终演示阶段直接用全局配置最省事。关于允许的请求头务必加上Authorization否则登录后的请求全部拿不到 token。5.4 文件上传大小限制的经典踩坑房源图片上传功能写完后第一次测试大图传上去就报错。查日志发现是 SpringBoot 默认上传大小限制在 1MB超出直接被拦截。在application.yml里配置spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB还要注意一个细节如果前端用 base64 传图片而不是文件流这个限制是不生效的但 base64 传输体积会膨胀三分之一不推荐用multipart/form-data文件上传更标准。5.5 前端路由刷新 404 问题管理端页面路由用的 HTML5 History 模式后端没有处理的话点击刷新或直接输入子路径访问会 404。这个问题在前后端集成部署时更常见。后端加一个路由转发配置把非 API 路径全部转发到index.html或者在全栈部署时用 Nginxtry_files解决。作为毕设我建议直接用 Vue 默认的 Hash 路由模式虽然 URL 里多一个#但完全避免了这个刷新难题省下来的时间写业务代码不香吗。6. 给同样做这个课题的人几点实在建议如果让我重新做一遍这个课题最想优化的一件事是提前把 Mock 数据做足。开发阶段每测一个功能就得手动画数据这个工作特别琐碎。提前写一个DataInitializer类系统启动时检测到房源表为空就自动生成几十条仿真数据包含不同户型、不同价格段的房源后面联调效率翻倍。再一个建议是把模块边界写清楚。很多同学写着写着把业务逻辑全塞在 Controller 里表面看着代码量很足实际上一旦要改逻辑就牵扯一堆接口。我最后重构时把代码分成了 Controller、Service、Mapper 三层所有业务判断都放在 Service 层Controller 只负责参数接收和结果返回。重构完代码结构清爽了太多写论文时照着包结构讲也顺理成章。我感受最深的一点毕设项目的代码一定不要照抄每个表、每个字段、每个接口都要自己想过一遍。房产中介系统这种全流程项目里面涉及的数据库设计、权限控制、状态流转、事务处理都是未来 Java 开发工作中每天要面对的东西。自己亲手把整个流程走通积累下来的问题排查经验比任何网课都值钱。这个系统后续可以扩展的方向也不少比如把 Redis 用到热点房源缓存上减少数据库压力或者加一个房源与客户的匹配度打分功能用简单的规则引擎替代我当初的 SQL 条件拼接。这些都可以作为答辩时“展望”部分的素材不过核心思路是一致的先把地基打好业务闭环跑通再谈升级优化。