很多准备毕业设计的同学看到“基于SpringBoot的二手房管理服务平台”这个题目的第一反应往往是这又是个管理系统增删改查有什么好写的但等真正动手就会明白表面看是常规系统实际做起来到处都是选择房源状态怎么管理、买卖双方怎么撮合、并发请求来了会不会出问题、微服务到底要不要上。这篇文章我就把实际干活时会遇到的关键问题一一拆开说说该怎么把“SpringBoot Java”这套组合用起来以及为什么微服务在毕业设计里更适合做成加分项而不是绊脚石。先说结论这个题目非常适合作为Java方向的毕业设计。它覆盖的场景比较完整从用户注册登录、房源发布审核到预约看房、交易撮合、签约下单再到后台数据统计几乎把日常业务系统里的典型环节都走了一遍而难度又不至于让人做不完。适合的人群主要是这几类一是正在选题的应届毕业生二是想靠项目补强Java开发经验的人三是被“微服务”三个字吓住、想搞清楚它到底该不该用在毕设里的人。下面我按自己完整做过一遍的顺序来写尽量把每个环节“为什么这么做”讲透。1. 项目定位与毕业设计选题思路1.1 为什么选“二手房交易管理平台”而不是其他管理系统很多同学选题时习惯找经典题目比如图书管理、学生选课、仓库管理。这类系统优点是简单缺点也恰恰是太简单无非是几张表的增删改查业务上没有递进答辩时很难展示技术深度。二手房交易平台不一样它有真实的业务流转比如一套房源从业主提交到最终成交需要经历待审核、挂牌中、预约看房、已下定、交易中、已完成、已下架等状态状态之间还有合法性约束。这种“有状态、有流程、有撮合”的业务模型比单纯的管理系统更适合做毕业设计。另一个原因是它贴近真实行业。二手房交易在行业里叫存量房交易业务链条长业主挂牌、平台审核、买家搜索、预约看房、价格谈判、签约过户。把这些环节抽象成系统功能本身就是一次完整的需求分析训练。答辩时老师问你“这个系统解决了什么业务痛点”你不至于只能说“方便管理数据”而是可以从信息不透明、看房效率低、交易进度难追踪这些真实痛点切入讲出逻辑来。1.2 需求拆解从业务痛点倒推功能模块我习惯先列角色再列痛点最后倒推功能。这个平台核心是三个角色业主卖方、购房者买方、平台运营管理员。每个角色面临的问题不同角色业务痛点对应功能模块业主房源挂出去后不知道有没有人看、卖到什么进度个人房源中心、看房预约记录、成交进度追踪购房者筛选房源耗时、房源真实性难判断多条件搜索、房源详情报告、在线预约看房、收藏对比平台管理员审核成本高、信息维护混乱、难以掌握运营数据房源审核、订单管理、用户管理、数据统计看板这套模块划分下来系统的骨架就很清楚了用户模块、房源模块、预约模块、交易模块、统计模块再加上后台管理模块。功能上不复杂但每个模块都有值得深入做的细节比如房源的“多状态流转”、预约的“时间冲突检测”、交易的“并发防重”这些细节才是你和别人的项目拉开差距的地方。2. 技术选型与架构设计单体还是微服务的务实选择2.1 SpringBoot版本与Java版本的搭配建议我建议用SpringBoot 2.7.x JDK 8或者JDK 11不要一上来就追SpringBoot 3.x JDK 17。原因很现实大多数学校的教学环境、答辩老师熟悉的版本、以及网上的参考资料都集中在JDK 8SpringBoot 2.x这条线上。SpringBoot 3.x底层是Jakarta EE规范部分老版本数据库驱动、第三方工具需要额外适配对毕设来说属于不必要的风险。有人会问用新版不是显得更有追求吗问题是毕业设计第一优先级是“稳定跑通”而不是“技术最新”。真要体现学习能力不如把SpringBoot 2.7里的核心机制搞清楚自动配置原理、条件注解、事务管理、拦截器、AOP这些在面试里高频出现也足够撑起整个项目的技术亮点。2.2 微服务要不要上我的建议是模块化单体这是这个题目最容易走偏的地方。看到关键词里有“微服务”有的同学会直接上Spring Cloud Alibaba全家桶搞网关、注册中心、配置中心结果是分布式事务没做、服务间调用乱成一团最后连本地启动都费劲。我必须说句大实话毕业设计阶段真正拆微服务往往弊大于利。我推荐“模块化单体”方案用Maven多模块把项目拆成独立业务域比如user模块、house模块、trade模块、system模块每个模块内部保持独立的Service和Controller边界对外暴露清晰的接口。这样有几个好处项目结构清晰代码职责不混乱模块之间可以做到编译级隔离模拟微服务的拆分思路如果需要展示微服务能力再单独抽出一个统计服务通过OpenFeign或者RestTemplate做一个跨服务调用演示比整套微服务改造要稳得多。这样做最大的价值在于答辩时你能讲清楚“什么场景该拆、什么场景不该拆”。比如你可以说当前业务体量下单体完全够用但为了后续模块独立扩展我把Maven多模块先做了拆分未来交易量增长时可以把house模块独立成服务这就是一种务实的架构思维比硬拆微服务加分很多。2.3 数据库设计二手房系统的核心表结构拆解数据库是整个项目的地基表结构设计得好后面写代码会顺很多。我当时设计了这样几张核心表tb_user用户表包含用户名、密码、手机号、角色类型业主/买家/管理员tb_house房源表包含房源基本信息、价格、面积、户型、所在区域、状态字段tb_appointment预约看房表记录买家预约房源的时间、状态tb_trade_order交易订单表记录买卖双方进入交易环节的信息tb_house_audit_log房源审核日志表记录管理员对房源的审核历史tb_operate_log操作日志表记录关键用户行为tb_house表是核心这里想专门提醒一个容易踩的坑很多同学会把房源的“审核状态”和“交易状态”合并成一个字段这会给后续业务留隐患。比如一套房源可以是“审核通过但尚未挂牌”也可以是“挂牌中被预约看房”这是两个维度的概念不能用单一状态字段硬扛。我当时拆成了audit_status待审核/通过/驳回和status下架/挂牌中/已下定/交易中/已完成两个字段各管各的状态流转代码里判断逻辑会清晰很多。价格字段也要注意必须用decimal(10,2)而不是double。用浮点存金额看起来没什么等到算中介费、统计成交金额时会出现精度问题答辩时被老师问一句“你怎么保证金额准确”就容易被卡住。字段长度、索引、默认值这些细节往往比功能代码更能体现一个开发者的基本功。3. 六大核心业务模块的实现细节3.1 用户登录与权限鉴权JWT还是Session对毕设来说我建议用JWT Token配合拦截器实现而不是引入Spring Security那一套完整安全框架。原因很简单Spring Security的学习曲线和配置复杂度放在毕设时间表里不太划算而且它的过滤器链和你自己的业务拦截器容易打架。我的做法是登录接口校验用户名密码后生成JWT Token返回前端前端把Token存到localStorage每次请求在Header里携带后端写一个HandlerInterceptor拦截除登录、注册、房源列表等白名单之外的请求在拦截器里解析Token把当前用户信息放到ThreadLocal里方便后续业务直接从上下文取用户权限这块我用自定义注解RequireRole解决。比如管理员接口上加RequireRole(ADMIN)在拦截器里判断当前用户的角色不匹配直接返回403。这个方案简洁、可控而且代码量不大但足以说明你对鉴权机制的理解。3.2 房源信息管理数据校验与状态流转房源发布是平台最核心的基础操作。前端提交表单后后端要依次做参数校验必填字段、价格范围、面积数值、业务校验产权证号是否重复、同一个小区的房源是否已经存在、状态初始化置为待审核。这里可以用Spring的Valid配合Validation注解做参数校验减少手写if else。状态流转这块我强烈建议用枚举加前置状态判断。我在代码里定义了一个HouseStatusEnum每个状态对应一个枚举项每次更新状态前先校验当前状态是否允许变更。例如挂牌中可以被修改为已下定但不能直接跳到已完成。这个逻辑相当于一个轻量状态机面试时能非常清晰地表达出来。注意不要在同一个接口里既做房源信息修改又做房源状态修改否则会出现业务漏洞。比如业主把房源信息改了顺手把“挂牌中”改成“已下定”系统就乱了。我的做法是信息修改和状态流转分离状态流转单独走一个handler方法先校验前置状态再更新。3.3 二手房撮合匹配算法的工程化实现“撮合”是这个平台最容易做得虚的功能也是最容易做出彩的功能。我没用复杂的搜索引擎而是用MySQL加内存计分实现了一个轻量级匹配引擎效果对毕设来说完全够用。思路是买家提交筛选条件——区域、总价区间、户型、面积段系统先从库里查出符合条件的房源然后按命中条件计算匹配度得分最后按分数倒序展示。匹配度的计算方式可以做成加权计分比如区域完全匹配40分总价区间匹配30分户型匹配20分面积段匹配10分为什么用加权而不用等权因为实际业务中地段和价格是买家最先考虑的权重高更符合用户预期。这个逻辑不复杂但已经能体现“规则引擎”的思想答辩时还能引出一个扩展话题如果数据量大了怎么优化可以回答引入Elasticsearch做搜索服务或者用更细粒度的特征打分模型。能做技术演进的设计比写死一个查询接口要好得多。3.4 预约看房与交易订单一个事务搞定两件联动的事买家预约看房本质上是两个动作同时发生写入一条预约记录改变房源状态挂牌中变为被预约。这两个操作必须放在同一个事务里否则会出现“预约记录写了房源状态没变”或者反过来数据就不一致了。ServiceImpl层的核心伪代码大概是这样Transactional(rollbackFor Exception.class) public boolean createAppointment(Long houseId, Long buyerId, Date time) { // 1. 校验房源状态为挂牌中 House house houseMapper.selectById(houseId); if (house null || !Objects.equals(house.getStatus(), HouseStatusEnum.LISTED.getCode())) { throw new BizException(房源不存在或不可预约); } // 2. 检测该时段是否已有冲突预约 int count appointmentMapper.countConflict(houseId, time); if (count 0) { throw new BizException(该时段已被预约请更换时间); } // 3. 创建预约记录 Appointment appointment new Appointment(); appointment.setHouseId(houseId); appointment.setBuyerId(buyerId); appointment.setTime(time); appointment.setStatus(AppointmentStatusEnum.PENDING.getCode()); appointmentMapper.insert(appointment); // 4. 更新房源状态 house.setStatus(HouseStatusEnum.RESERVED.getCode()); return houseMapper.updateById(house) 1; }这段代码里有几个细节值得注意一是方法上加了rollbackFor Exception.class这是一个很多初学者会漏掉的点因为Spring的Transactional默认只在RuntimeException下回滚如果业务里抛的是受检异常不加这个参数事务是不会回滚的。二是预约冲突检测放在了业务层而不是数据库层虽然效率不是最优但胜在逻辑直观也方便扩展更复杂的冲突规则。3.5 数据统计报表运营后台的可视化展示后台管理除了信息审核还要让管理员一眼看清楚平台的运营情况所以统计模块不可少。我接入了ECharts做前端图表后端提供统计接口。核心是两个统计维度一是挂牌量趋势按月分组统计每个月新增挂牌房源数SELECT DATE_FORMAT(create_time, %Y-%m) AS month, COUNT(*) AS total FROM tb_house GROUP BY DATE_FORMAT(create_time, %Y-%m) ORDER BY month;二是成交转化率统计成交房源数占总挂牌房源的比例。这类统计接口要注意报表数据往往需要聚合多张表别图省事在Java里查一张表算一遍再查另一张表又算一遍最后内存里拼数据。SQL层面能解决的聚合尽量在SQL里解决性能会好很多代码也干净。3.6 前端文件上传图片路径问题的根源房源照片上传是必备功能几乎每个做这个题目的人都会在图片显示上踩坑。最典型的问题是图片上传成功了但页面访问不到。原因通常是SpringBoot的静态资源映射没有覆盖你上传文件的目录。我的实现是配置文件里通过自定义路径映射把所有上传文件统一放到项目外的upload目录同时通过WebMvcConfigurer将/upload/**映射到本地磁盘路径。注意这里不要用项目内部的相对路径不然项目打包成jar之后文件目录会跟着失效。文件重命名规则用得是日期加UUID避免重名覆盖也方便按日期归档排查。4. 实操全记录从项目初始化到核心接口联调4.1 项目初始化与依赖选择创建项目我用的是IDEA的Spring Initializr。依赖选择上有几个核心必须加spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java、spring-boot-starter-validation、lombok。如果想要缓存预热和热点房源统计再加上spring-boot-starter-data-redis。mybatis-plus强烈建议用它对单表CRUD的简化非常明显能省下大量重复的Mapper XML编写时间。配置文件里需要留意的是数据库连接串、Redis连接、MyBatis-Plus的日志输出。其中map-underscore-to-camel-case这个配置要打开否则数据库下划线字段和Java驼峰属性映射不上查询结果会出现一堆null。4.2 房源发布与审核接口开发实录我从“房源发布”这个入口写起。定义一个Result 统一响应体格式为code、message、data整个项目所有接口统一返回这个结构。前端只需判断code是否为200处理逻辑完全统一。发布接口的校验链条是先做参数校验再做业务校验。参数校验包括价格非空且大于0、面积在合理范围、户型字段枚举正确业务校验包括产权证号不能重复、该业主名下已挂牌的房源不能超过某个数量防止一个人刷几百套房源。审核接口是管理员侧的功能流程如下RequireRole(ADMIN) PostMapping(/audit) public ResultVoid auditHouse(RequestBody AuditRequest request) { House house houseMapper.selectById(request.getHouseId()); if (house null) { return Result.error(房源不存在); } if (!Objects.equals(house.getAuditStatus(), AuditStatusEnum.PENDING.getCode())) { return Result.error(该房源已审核请勿重复操作); } house.setAuditStatus(request.getPass() ? AuditStatusEnum.APPROVED.getCode() : AuditStatusEnum.REJECTED.getCode()); house.setAuditRemark(request.getRemark()); houseMapper.updateById(house); auditLogMapper.insert(new HouseAuditLog(...)); return Result.success(); }这里特别加了“重复审核校验”防止审核两次造成状态覆盖也是把状态机思想落到了实际代码里。4.3 并发控制实战一房多卖的兜底策略毕业设计能写到并发控制已经算很不错的亮点。这个项目里最典型的并发场景是“一房多卖”多个买家在同一时刻对同一套房源发起交易意向如果不加控制就会产生多条有效预约或订单。我的方案是乐观锁加状态条件更新。具体来说不直接用updateById而是用带条件的更新语句int rows houseMapper.updateStatusByCondition( houseId, HouseStatusEnum.LISTED.getCode(), HouseStatusEnum.RESERVED.getCode() ); if (rows 0) { throw new BizException(房源已被抢先预约请刷新后重试); }这里的核心思想是用“当前状态挂牌中”作为更新条件MySQL的行锁会保证同一时刻只有一个事务能更新成功受影响行数不为1就说明被别人抢占了。这比单纯查一次判断再更新要可靠得多因为查和更新之间的时间窗口可能被插队。能把这个场景讲清楚答辩老师基本不会再问你并发相关的问题。4.4 Redis缓存热点房源与列表查询优化搜索页的房源列表是访问最频繁的接口不适合每次都查数据库。我的做法是用Redis缓存热门小区和首页推荐房源缓存Key设计为house:recommend:top20缓存时间为5分钟缓解数据库压力。缓存更新策略采取“更新数据库后主动删缓存”。不用更新缓存的原因是更新缓存的逻辑容易和业务状态耦合删缓存则简单得多等下次请求再回源。这个策略在一致性上足够满足毕设场景而且能体现出经典的缓存模式思维。4.5 多模块联调与微服务演示模块化单体落地时我单独拆了一个“统计报表服务”模拟微服务之间的调用。交易模块需要查询成交数据时通过OpenFeign客户端调用统计服务的接口。这里不用把OpenFeign整得很复杂引入spring-cloud-starter-openfeign依赖在启动类加EnableFeignClients然后定义接口声明即可。为了降低演示成本注册中心可以直接用Nacos也可以更轻量地弄一个本地端口直连。答辩时说清楚“当前是模块化单体的演进阶段未来可以替换为独立服务”就够了。5. 常见问题与排查技巧来自现场的真实错误5.1 图片上传后访问404这个坑出现次数极多根因通常是SpringBoot的静态资源没覆盖upload目录。解决方式是显式配置资源映射Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceHandler(file: uploadDir /); } }注意两个细节第一file:后面的路径必须存在第二路径末尾要加斜杠漏掉会匹配不到文件。图片能存不能显示八成是这个问题。5.2 MyBatis-Plus分页插件失效分页是后台列表最常见需求但很多同学发现添加了Page参数后返回结果还是全量数据。原因基本都是没有注册PaginationInnerInterceptor拦截器。用MyBatis-Plus必须在配置类里明确创建MybatisPlusInterceptor并添加分页拦截器。还有一个分页配合多表联查的坑分页插件自动生成的count语句在复杂join查询下可能出错导致total不对。解决办法是自定义count查询或者尽量分页只作用于主表字段明细再单独查。5.3 Transactional不生效的三种情况这个知识点我在面试题里反复见也在实操里反复踩。最常见的不生效场景是同一个类内部调用带事务的方法调用方绕过Spring代理事务失效异常被try-catch吞掉事务感知不到异常不会回滚默认Rollback策略只对RuntimeException生效受检异常不触发回滚解决办法是事务方法放到不同Service中调用异常要么不吞要么重新抛出事务注解显式写rollbackFor Exception.class。能说出这三条不但项目里少踩坑面试里也是加分项。5.4 跨域配置和拦截器冲突前端和后端分离部署时会出现跨域问题。我之前遇到过CORS配置明明写了但带Token的请求还是报跨域错误。原因是拦截器先于跨域处理执行导致预检请求OPTIONS直接拦截了。解决方案是拦截器里对OPTIONS请求直接放行同时把CorsFilter或者WebMvcConfigurer的addCorsMappings配置好。6. 常见问题速查表问题现象可能原因排查方向分页查询返回全表未注册分页拦截器检查MybatisPlusInterceptor配置金额数据出现精度误差数据库字段用了float/double改为decimal(10,2)图片上传显示404静态资源映射缺失检查addResourceHandlers配置事务没有回滚方法自调用或异常被捕获拆分Service方法并显式抛出异常属性全是null下划线转驼峰未开启检查map-underscore-to-camel-case一房多卖缺少并发控制使用条件UPDATE状态字段跨域请求失败拦截器拦截OPTIONS预检放行OPTIONS请求最后分享几个我实际折腾下来的体会。第一毕业设计能不能出彩关键不在技术多花哨而是能不能把一两个细节做扎实。这个项目里我选的就是“房源状态机”和“并发防重”代码量不大但答辩时老师明显更愿意在这些点上追问我也确实都有话可说。第二微服务不要为了做而做模块化单体把这些概念都以最小成本演示清楚了这种克制其实是更成熟的设计判断。第三项目写完一定要自己重新走一遍核心流程从业主发房到管理员审核再到买家预约看房最后交易完成任何一个环节断了都要知道断在哪里、为什么断这才是做毕设真正留给你的东西。这套SpringBoot二手房平台做完你收获的不仅是一个能跑的系统和一份及格论文更是一整套从需求到设计再到实现落地的思考习惯以后不管做工程还是应付面试都会省力很多。
SpringBoot二手房管理平台实战：从单体架构到微服务演进指南
很多准备毕业设计的同学看到“基于SpringBoot的二手房管理服务平台”这个题目的第一反应往往是这又是个管理系统增删改查有什么好写的但等真正动手就会明白表面看是常规系统实际做起来到处都是选择房源状态怎么管理、买卖双方怎么撮合、并发请求来了会不会出问题、微服务到底要不要上。这篇文章我就把实际干活时会遇到的关键问题一一拆开说说该怎么把“SpringBoot Java”这套组合用起来以及为什么微服务在毕业设计里更适合做成加分项而不是绊脚石。先说结论这个题目非常适合作为Java方向的毕业设计。它覆盖的场景比较完整从用户注册登录、房源发布审核到预约看房、交易撮合、签约下单再到后台数据统计几乎把日常业务系统里的典型环节都走了一遍而难度又不至于让人做不完。适合的人群主要是这几类一是正在选题的应届毕业生二是想靠项目补强Java开发经验的人三是被“微服务”三个字吓住、想搞清楚它到底该不该用在毕设里的人。下面我按自己完整做过一遍的顺序来写尽量把每个环节“为什么这么做”讲透。1. 项目定位与毕业设计选题思路1.1 为什么选“二手房交易管理平台”而不是其他管理系统很多同学选题时习惯找经典题目比如图书管理、学生选课、仓库管理。这类系统优点是简单缺点也恰恰是太简单无非是几张表的增删改查业务上没有递进答辩时很难展示技术深度。二手房交易平台不一样它有真实的业务流转比如一套房源从业主提交到最终成交需要经历待审核、挂牌中、预约看房、已下定、交易中、已完成、已下架等状态状态之间还有合法性约束。这种“有状态、有流程、有撮合”的业务模型比单纯的管理系统更适合做毕业设计。另一个原因是它贴近真实行业。二手房交易在行业里叫存量房交易业务链条长业主挂牌、平台审核、买家搜索、预约看房、价格谈判、签约过户。把这些环节抽象成系统功能本身就是一次完整的需求分析训练。答辩时老师问你“这个系统解决了什么业务痛点”你不至于只能说“方便管理数据”而是可以从信息不透明、看房效率低、交易进度难追踪这些真实痛点切入讲出逻辑来。1.2 需求拆解从业务痛点倒推功能模块我习惯先列角色再列痛点最后倒推功能。这个平台核心是三个角色业主卖方、购房者买方、平台运营管理员。每个角色面临的问题不同角色业务痛点对应功能模块业主房源挂出去后不知道有没有人看、卖到什么进度个人房源中心、看房预约记录、成交进度追踪购房者筛选房源耗时、房源真实性难判断多条件搜索、房源详情报告、在线预约看房、收藏对比平台管理员审核成本高、信息维护混乱、难以掌握运营数据房源审核、订单管理、用户管理、数据统计看板这套模块划分下来系统的骨架就很清楚了用户模块、房源模块、预约模块、交易模块、统计模块再加上后台管理模块。功能上不复杂但每个模块都有值得深入做的细节比如房源的“多状态流转”、预约的“时间冲突检测”、交易的“并发防重”这些细节才是你和别人的项目拉开差距的地方。2. 技术选型与架构设计单体还是微服务的务实选择2.1 SpringBoot版本与Java版本的搭配建议我建议用SpringBoot 2.7.x JDK 8或者JDK 11不要一上来就追SpringBoot 3.x JDK 17。原因很现实大多数学校的教学环境、答辩老师熟悉的版本、以及网上的参考资料都集中在JDK 8SpringBoot 2.x这条线上。SpringBoot 3.x底层是Jakarta EE规范部分老版本数据库驱动、第三方工具需要额外适配对毕设来说属于不必要的风险。有人会问用新版不是显得更有追求吗问题是毕业设计第一优先级是“稳定跑通”而不是“技术最新”。真要体现学习能力不如把SpringBoot 2.7里的核心机制搞清楚自动配置原理、条件注解、事务管理、拦截器、AOP这些在面试里高频出现也足够撑起整个项目的技术亮点。2.2 微服务要不要上我的建议是模块化单体这是这个题目最容易走偏的地方。看到关键词里有“微服务”有的同学会直接上Spring Cloud Alibaba全家桶搞网关、注册中心、配置中心结果是分布式事务没做、服务间调用乱成一团最后连本地启动都费劲。我必须说句大实话毕业设计阶段真正拆微服务往往弊大于利。我推荐“模块化单体”方案用Maven多模块把项目拆成独立业务域比如user模块、house模块、trade模块、system模块每个模块内部保持独立的Service和Controller边界对外暴露清晰的接口。这样有几个好处项目结构清晰代码职责不混乱模块之间可以做到编译级隔离模拟微服务的拆分思路如果需要展示微服务能力再单独抽出一个统计服务通过OpenFeign或者RestTemplate做一个跨服务调用演示比整套微服务改造要稳得多。这样做最大的价值在于答辩时你能讲清楚“什么场景该拆、什么场景不该拆”。比如你可以说当前业务体量下单体完全够用但为了后续模块独立扩展我把Maven多模块先做了拆分未来交易量增长时可以把house模块独立成服务这就是一种务实的架构思维比硬拆微服务加分很多。2.3 数据库设计二手房系统的核心表结构拆解数据库是整个项目的地基表结构设计得好后面写代码会顺很多。我当时设计了这样几张核心表tb_user用户表包含用户名、密码、手机号、角色类型业主/买家/管理员tb_house房源表包含房源基本信息、价格、面积、户型、所在区域、状态字段tb_appointment预约看房表记录买家预约房源的时间、状态tb_trade_order交易订单表记录买卖双方进入交易环节的信息tb_house_audit_log房源审核日志表记录管理员对房源的审核历史tb_operate_log操作日志表记录关键用户行为tb_house表是核心这里想专门提醒一个容易踩的坑很多同学会把房源的“审核状态”和“交易状态”合并成一个字段这会给后续业务留隐患。比如一套房源可以是“审核通过但尚未挂牌”也可以是“挂牌中被预约看房”这是两个维度的概念不能用单一状态字段硬扛。我当时拆成了audit_status待审核/通过/驳回和status下架/挂牌中/已下定/交易中/已完成两个字段各管各的状态流转代码里判断逻辑会清晰很多。价格字段也要注意必须用decimal(10,2)而不是double。用浮点存金额看起来没什么等到算中介费、统计成交金额时会出现精度问题答辩时被老师问一句“你怎么保证金额准确”就容易被卡住。字段长度、索引、默认值这些细节往往比功能代码更能体现一个开发者的基本功。3. 六大核心业务模块的实现细节3.1 用户登录与权限鉴权JWT还是Session对毕设来说我建议用JWT Token配合拦截器实现而不是引入Spring Security那一套完整安全框架。原因很简单Spring Security的学习曲线和配置复杂度放在毕设时间表里不太划算而且它的过滤器链和你自己的业务拦截器容易打架。我的做法是登录接口校验用户名密码后生成JWT Token返回前端前端把Token存到localStorage每次请求在Header里携带后端写一个HandlerInterceptor拦截除登录、注册、房源列表等白名单之外的请求在拦截器里解析Token把当前用户信息放到ThreadLocal里方便后续业务直接从上下文取用户权限这块我用自定义注解RequireRole解决。比如管理员接口上加RequireRole(ADMIN)在拦截器里判断当前用户的角色不匹配直接返回403。这个方案简洁、可控而且代码量不大但足以说明你对鉴权机制的理解。3.2 房源信息管理数据校验与状态流转房源发布是平台最核心的基础操作。前端提交表单后后端要依次做参数校验必填字段、价格范围、面积数值、业务校验产权证号是否重复、同一个小区的房源是否已经存在、状态初始化置为待审核。这里可以用Spring的Valid配合Validation注解做参数校验减少手写if else。状态流转这块我强烈建议用枚举加前置状态判断。我在代码里定义了一个HouseStatusEnum每个状态对应一个枚举项每次更新状态前先校验当前状态是否允许变更。例如挂牌中可以被修改为已下定但不能直接跳到已完成。这个逻辑相当于一个轻量状态机面试时能非常清晰地表达出来。注意不要在同一个接口里既做房源信息修改又做房源状态修改否则会出现业务漏洞。比如业主把房源信息改了顺手把“挂牌中”改成“已下定”系统就乱了。我的做法是信息修改和状态流转分离状态流转单独走一个handler方法先校验前置状态再更新。3.3 二手房撮合匹配算法的工程化实现“撮合”是这个平台最容易做得虚的功能也是最容易做出彩的功能。我没用复杂的搜索引擎而是用MySQL加内存计分实现了一个轻量级匹配引擎效果对毕设来说完全够用。思路是买家提交筛选条件——区域、总价区间、户型、面积段系统先从库里查出符合条件的房源然后按命中条件计算匹配度得分最后按分数倒序展示。匹配度的计算方式可以做成加权计分比如区域完全匹配40分总价区间匹配30分户型匹配20分面积段匹配10分为什么用加权而不用等权因为实际业务中地段和价格是买家最先考虑的权重高更符合用户预期。这个逻辑不复杂但已经能体现“规则引擎”的思想答辩时还能引出一个扩展话题如果数据量大了怎么优化可以回答引入Elasticsearch做搜索服务或者用更细粒度的特征打分模型。能做技术演进的设计比写死一个查询接口要好得多。3.4 预约看房与交易订单一个事务搞定两件联动的事买家预约看房本质上是两个动作同时发生写入一条预约记录改变房源状态挂牌中变为被预约。这两个操作必须放在同一个事务里否则会出现“预约记录写了房源状态没变”或者反过来数据就不一致了。ServiceImpl层的核心伪代码大概是这样Transactional(rollbackFor Exception.class) public boolean createAppointment(Long houseId, Long buyerId, Date time) { // 1. 校验房源状态为挂牌中 House house houseMapper.selectById(houseId); if (house null || !Objects.equals(house.getStatus(), HouseStatusEnum.LISTED.getCode())) { throw new BizException(房源不存在或不可预约); } // 2. 检测该时段是否已有冲突预约 int count appointmentMapper.countConflict(houseId, time); if (count 0) { throw new BizException(该时段已被预约请更换时间); } // 3. 创建预约记录 Appointment appointment new Appointment(); appointment.setHouseId(houseId); appointment.setBuyerId(buyerId); appointment.setTime(time); appointment.setStatus(AppointmentStatusEnum.PENDING.getCode()); appointmentMapper.insert(appointment); // 4. 更新房源状态 house.setStatus(HouseStatusEnum.RESERVED.getCode()); return houseMapper.updateById(house) 1; }这段代码里有几个细节值得注意一是方法上加了rollbackFor Exception.class这是一个很多初学者会漏掉的点因为Spring的Transactional默认只在RuntimeException下回滚如果业务里抛的是受检异常不加这个参数事务是不会回滚的。二是预约冲突检测放在了业务层而不是数据库层虽然效率不是最优但胜在逻辑直观也方便扩展更复杂的冲突规则。3.5 数据统计报表运营后台的可视化展示后台管理除了信息审核还要让管理员一眼看清楚平台的运营情况所以统计模块不可少。我接入了ECharts做前端图表后端提供统计接口。核心是两个统计维度一是挂牌量趋势按月分组统计每个月新增挂牌房源数SELECT DATE_FORMAT(create_time, %Y-%m) AS month, COUNT(*) AS total FROM tb_house GROUP BY DATE_FORMAT(create_time, %Y-%m) ORDER BY month;二是成交转化率统计成交房源数占总挂牌房源的比例。这类统计接口要注意报表数据往往需要聚合多张表别图省事在Java里查一张表算一遍再查另一张表又算一遍最后内存里拼数据。SQL层面能解决的聚合尽量在SQL里解决性能会好很多代码也干净。3.6 前端文件上传图片路径问题的根源房源照片上传是必备功能几乎每个做这个题目的人都会在图片显示上踩坑。最典型的问题是图片上传成功了但页面访问不到。原因通常是SpringBoot的静态资源映射没有覆盖你上传文件的目录。我的实现是配置文件里通过自定义路径映射把所有上传文件统一放到项目外的upload目录同时通过WebMvcConfigurer将/upload/**映射到本地磁盘路径。注意这里不要用项目内部的相对路径不然项目打包成jar之后文件目录会跟着失效。文件重命名规则用得是日期加UUID避免重名覆盖也方便按日期归档排查。4. 实操全记录从项目初始化到核心接口联调4.1 项目初始化与依赖选择创建项目我用的是IDEA的Spring Initializr。依赖选择上有几个核心必须加spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java、spring-boot-starter-validation、lombok。如果想要缓存预热和热点房源统计再加上spring-boot-starter-data-redis。mybatis-plus强烈建议用它对单表CRUD的简化非常明显能省下大量重复的Mapper XML编写时间。配置文件里需要留意的是数据库连接串、Redis连接、MyBatis-Plus的日志输出。其中map-underscore-to-camel-case这个配置要打开否则数据库下划线字段和Java驼峰属性映射不上查询结果会出现一堆null。4.2 房源发布与审核接口开发实录我从“房源发布”这个入口写起。定义一个Result 统一响应体格式为code、message、data整个项目所有接口统一返回这个结构。前端只需判断code是否为200处理逻辑完全统一。发布接口的校验链条是先做参数校验再做业务校验。参数校验包括价格非空且大于0、面积在合理范围、户型字段枚举正确业务校验包括产权证号不能重复、该业主名下已挂牌的房源不能超过某个数量防止一个人刷几百套房源。审核接口是管理员侧的功能流程如下RequireRole(ADMIN) PostMapping(/audit) public ResultVoid auditHouse(RequestBody AuditRequest request) { House house houseMapper.selectById(request.getHouseId()); if (house null) { return Result.error(房源不存在); } if (!Objects.equals(house.getAuditStatus(), AuditStatusEnum.PENDING.getCode())) { return Result.error(该房源已审核请勿重复操作); } house.setAuditStatus(request.getPass() ? AuditStatusEnum.APPROVED.getCode() : AuditStatusEnum.REJECTED.getCode()); house.setAuditRemark(request.getRemark()); houseMapper.updateById(house); auditLogMapper.insert(new HouseAuditLog(...)); return Result.success(); }这里特别加了“重复审核校验”防止审核两次造成状态覆盖也是把状态机思想落到了实际代码里。4.3 并发控制实战一房多卖的兜底策略毕业设计能写到并发控制已经算很不错的亮点。这个项目里最典型的并发场景是“一房多卖”多个买家在同一时刻对同一套房源发起交易意向如果不加控制就会产生多条有效预约或订单。我的方案是乐观锁加状态条件更新。具体来说不直接用updateById而是用带条件的更新语句int rows houseMapper.updateStatusByCondition( houseId, HouseStatusEnum.LISTED.getCode(), HouseStatusEnum.RESERVED.getCode() ); if (rows 0) { throw new BizException(房源已被抢先预约请刷新后重试); }这里的核心思想是用“当前状态挂牌中”作为更新条件MySQL的行锁会保证同一时刻只有一个事务能更新成功受影响行数不为1就说明被别人抢占了。这比单纯查一次判断再更新要可靠得多因为查和更新之间的时间窗口可能被插队。能把这个场景讲清楚答辩老师基本不会再问你并发相关的问题。4.4 Redis缓存热点房源与列表查询优化搜索页的房源列表是访问最频繁的接口不适合每次都查数据库。我的做法是用Redis缓存热门小区和首页推荐房源缓存Key设计为house:recommend:top20缓存时间为5分钟缓解数据库压力。缓存更新策略采取“更新数据库后主动删缓存”。不用更新缓存的原因是更新缓存的逻辑容易和业务状态耦合删缓存则简单得多等下次请求再回源。这个策略在一致性上足够满足毕设场景而且能体现出经典的缓存模式思维。4.5 多模块联调与微服务演示模块化单体落地时我单独拆了一个“统计报表服务”模拟微服务之间的调用。交易模块需要查询成交数据时通过OpenFeign客户端调用统计服务的接口。这里不用把OpenFeign整得很复杂引入spring-cloud-starter-openfeign依赖在启动类加EnableFeignClients然后定义接口声明即可。为了降低演示成本注册中心可以直接用Nacos也可以更轻量地弄一个本地端口直连。答辩时说清楚“当前是模块化单体的演进阶段未来可以替换为独立服务”就够了。5. 常见问题与排查技巧来自现场的真实错误5.1 图片上传后访问404这个坑出现次数极多根因通常是SpringBoot的静态资源没覆盖upload目录。解决方式是显式配置资源映射Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceHandler(file: uploadDir /); } }注意两个细节第一file:后面的路径必须存在第二路径末尾要加斜杠漏掉会匹配不到文件。图片能存不能显示八成是这个问题。5.2 MyBatis-Plus分页插件失效分页是后台列表最常见需求但很多同学发现添加了Page参数后返回结果还是全量数据。原因基本都是没有注册PaginationInnerInterceptor拦截器。用MyBatis-Plus必须在配置类里明确创建MybatisPlusInterceptor并添加分页拦截器。还有一个分页配合多表联查的坑分页插件自动生成的count语句在复杂join查询下可能出错导致total不对。解决办法是自定义count查询或者尽量分页只作用于主表字段明细再单独查。5.3 Transactional不生效的三种情况这个知识点我在面试题里反复见也在实操里反复踩。最常见的不生效场景是同一个类内部调用带事务的方法调用方绕过Spring代理事务失效异常被try-catch吞掉事务感知不到异常不会回滚默认Rollback策略只对RuntimeException生效受检异常不触发回滚解决办法是事务方法放到不同Service中调用异常要么不吞要么重新抛出事务注解显式写rollbackFor Exception.class。能说出这三条不但项目里少踩坑面试里也是加分项。5.4 跨域配置和拦截器冲突前端和后端分离部署时会出现跨域问题。我之前遇到过CORS配置明明写了但带Token的请求还是报跨域错误。原因是拦截器先于跨域处理执行导致预检请求OPTIONS直接拦截了。解决方案是拦截器里对OPTIONS请求直接放行同时把CorsFilter或者WebMvcConfigurer的addCorsMappings配置好。6. 常见问题速查表问题现象可能原因排查方向分页查询返回全表未注册分页拦截器检查MybatisPlusInterceptor配置金额数据出现精度误差数据库字段用了float/double改为decimal(10,2)图片上传显示404静态资源映射缺失检查addResourceHandlers配置事务没有回滚方法自调用或异常被捕获拆分Service方法并显式抛出异常属性全是null下划线转驼峰未开启检查map-underscore-to-camel-case一房多卖缺少并发控制使用条件UPDATE状态字段跨域请求失败拦截器拦截OPTIONS预检放行OPTIONS请求最后分享几个我实际折腾下来的体会。第一毕业设计能不能出彩关键不在技术多花哨而是能不能把一两个细节做扎实。这个项目里我选的就是“房源状态机”和“并发防重”代码量不大但答辩时老师明显更愿意在这些点上追问我也确实都有话可说。第二微服务不要为了做而做模块化单体把这些概念都以最小成本演示清楚了这种克制其实是更成熟的设计判断。第三项目写完一定要自己重新走一遍核心流程从业主发房到管理员审核再到买家预约看房最后交易完成任何一个环节断了都要知道断在哪里、为什么断这才是做毕设真正留给你的东西。这套SpringBoot二手房平台做完你收获的不仅是一个能跑的系统和一份及格论文更是一整套从需求到设计再到实现落地的思考习惯以后不管做工程还是应付面试都会省力很多。
