每年到了毕业季校园里最热闹的话题十有八九是毕设怎么选题。如果你点进这篇文章说明你大概率正在跟“基于SpringBoot的房产中介看房预约系统”这类题目较劲。这个方向我在做毕设时完整跑通了一遍从需求梳理、数据库建模、后端接口编写、前端页面组装到最后的部署演示录制踩过的坑比代码行数还多。今天把这套东西从设计到落地完整拆开讲一遍不绕弯子直接给你能“抄作业”的实操方案。这个系统到底做什么一句话房产中介可以在后台发布房源、维护信息用户看房前先在线预约中介或管理员审核预约并安排看房时间看房结束后更新跟进状态。听起来简单真正做起来涉及用户权限体系、房源状态机、预约时间冲突检测、消息通知等多个模块每一步都有讲究。这篇文章尤其适合正打算用SpringBoot做Java毕设的同学也适合想跑通一个完整前后端分离项目、需要一个可靠源码参考的初学者。下面按我的真实开发顺序来讲先想清楚设计再定数据库然后写核心接口最后解决部署和答辩那些琐碎但致命的问题。1. 选型与整体设计从题目反推需求别一上来就写代码1.1 为什么同类毕设绝大多数选择SpringBoot你翻一圈网上的毕设题目十套里面至少有六套是SpringBoot。不是因为大家没创意而是SpringBoot确实是当前Java后端开发里性价比最高的选择没有之一。一方面它内置了Tomcat不用再像SSH、SSM时代那样配一堆XML另一方面Spring生态的整合能力很强MyBatis、Redis、Spring Security这些主流组件都能快速接入。对于毕设来说最重要的是学习成本可控一个具备Java基础和Servlet概念的本科生看一周SpringBoot教程就能写出能跑通增删改查的接口。这种上手速度是SSH那种要理解Struts2拦裁器链的框架完全没法比的。还有一个隐性因素答辩老师基本上都熟悉SpringBoot。你写一个Struts2老项目的毕设老师可能还要现翻资料才能问出问题但你写SpringBoot老师随便就能追问自动配置原理、starter机制、依赖注入方式、事务传播行为这些问题你提前准备一下就能答上来。技术选型本身就是答辩的加分项这也是我强烈建议没特殊情况不要换技术栈的原因。1.2 功能模块怎么拆分才不显得假大空很多同学拿到“房产交易服务平台”这种题目第一反应是功能写得越多越好什么在线签约、按揭计算、地图找房、VR看房全塞进去。我劝你千万别这么干。毕设是有限时间内跑通的完整系统不是商业平台。功能堆太多代码质量一塌糊涂数据库表几十张但每张都只有三五个字段答辩时反而漏洞百出。我当时拆分功能的原则只有一条围绕“看房预约”这条核心业务链去扩展不相关的功能一律砍掉。最后落地的功能模块是这些用户端普通访客和注册用户房源浏览、房源详情查询、看房预约提交、预约记录管理、个人中心。中介端房源信息维护增加、修改、上下架、预约审核、看房日程管理、预约记录跟进。管理端用户管理、中介审核、房源分类管理、预约统计、系统公告维护。这个功能划分背后是有业务逻辑的。用户的核心诉求是“找到房子并预约看房”中介的核心诉求是“管理房源并有序安排看房”管理端的职责则是“保证平台上的房源和人员是可信的”。三者互为支撑形成一个闭环用户发起预约中介审核安排管理员兜底治理非法数据和纠纷订单。我在做需求文档的时候还专门画了一张业务流转图用户查询房源 - 提交预约申请 - 中介端收到待审核记录 - 同意并设置看房时间和联系人 - 用户收到审核结果通知 - 用户按时到店看房 - 中介更新带看状态为已完成或已取消。这整条链路里的每一步都对应数据库里的一张表、一个状态字段和一组接口。功能拆到这个颗粒度开发时心里就有底了。1.3 角色权限与业务流程梳理权限设计也是容易被忽略的一块。很多同学在项目里建了一张user表所有登录进来的人都在一个controller里处理没有任何角色区分。这种项目一旦答辩老师问“你怎么保证中介不能修改管理员的数据”就卡住了。我采用的是比较经典的RBAC基于角色的访问控制模型但做了简化没有搞五张表那么复杂用户表里加一个role字段0管理员、1中介、2普通用户再配一个全局限流器或拦截器在访问某些接口前校验当前用户的角色。比如发布房源只允许role1的中介调用审核中介入驻只允许role0的管理员调用。这样下来权限校验的代码量不大但整个系统的安全逻辑完整了。在业务流程上我总结了三条最核心的链路这三条链路打通了系统的主干就通了链路一房源发布与审核。中介提交房源 - 房源状态为待审核 - 管理员后台审核 - 通过后状态变为已上架。链路二看房预约。用户选择房源 - 填写预约时间与联系方式 - 提交预约 - 系统校验时间是否冲突 - 生成待审核预约 - 中介审核并通过/拒绝。链路三消息通知。每次状态变化都生成一条站内消息用户在个人中心能看到历史通知。这三条链路串起来后你会发现其实不需要写很多冗余的功能就已经能覆盖一个房产中介平台最核心的运营场景了。这个设计文档写清楚之后后面开发不是在“创作”而是在按图纸施工。2. 数据库设计是整套系统的地基直接决定开发效率和答辩质量2.1 核心表结构设计与字段规划数据库设计是我在毕设过程中花时间最长的部分不是因为我一开始就会而是因为我真的吃过“表没设计好导致返工”的苦。第一次写的时候我把用户和中介都塞进一张表结果发现中介需要维护多套房源而用户要维护多条预约两者数据根本没对齐。后来静下心重新设计了表结构才把项目往前推进下去。我最后定的核心表有这几张你可以直接参考sys_user用户表id、username、passwordMD5加盐或BCrypt加密、real_name、phone、role、status、create_time。house_info房源表id、agent_id中介用户ID、title、description、area、price、address、house_type、cover_image、status0待审核 1已上架 2已下架 3已删除、view_count、create_time、update_time。appointment看房预约表id、house_id、user_id、appointment_date、appointment_time、status0待审核 1已通过 2已拒绝 3已完成 4已取消、remark、agent_id、create_time、update_time。house_image房源图片表可选id、house_id、image_url、sort_order。message站内消息表id、user_id、content、is_read、create_time。admin_log操作日志表可选id、admin_id、operation、method、params、create_time。这里我要特别强调几个关键字段的取舍逻辑。第一个是status字段。几乎所有业务表我都加了status因为业务状态流转是毕设命中率最高的考点。你要能说出来为什么预约表要区分“待审核”和“已完成”因为业务上一个预约从发起到达成带看是有一个状态周期的用户能看到当前预约在哪个环节中介能根据状态做后续跟进。第二个是house_info里的agent_id。这个字段将房源表和用户表关联起来是“中介发布房源”这个功能的物理基础。没有这个外键关系你写中介端房源管理的时候会发现自己根本没法查询“某个中介名下的所有房源”。第三个是appointment表里的appointment_date和appointment_time。我特意把日期和时间拆成两个字段而不是合并成一个datetime。原因是预约系统的查询场景往往是“查某一天中介所有的带看安排”拆开后SQL写起来非常自然后续做周视图、月视图都方便。2.2 字段设计里容易被忽略的毁坑点数据库设计和写代码一样有些问题不运行到你面前你根本察觉不到。第一密码字段长度。很多同学建表时把password设成varchar(20)结果用BCrypt加密后存进去直接报错。BCrypt生成的哈希字符串固定是60位所以密码字段至少要给varchar(64)。这问题我帮同学调过不止一次每次都是字段长度不够导致登录注册一直失败。第二decimal和float的选择。房源的面积和价格我用的是decimal(10, 2)而不是float。float在Java里转BigDecimal处理价格时会出现精度问题答辩时如果你说“我用了BigDecimal精确计算金额”结果数据库字段是float那就是自己打自己脸。第三时间字段默认值。create_time我直接设置了DEFAULT CURRENT_TIMESTAMPupdate_time设置ON UPDATE CURRENT_TIMESTAMP。这样在插入和更新时Java代码里不需要显式处理这两个字段省不少事。还有一个小细节如果你用了MyBatis Plus的自动填充记得在实体类上配置TableField(fill FieldFill.INSERT)和fill FieldFill.INSERT_UPDATE别以为数据库设了默认值就万事大吉。第四逻辑删除而不是物理删除。房源下架我建议用一个状态字段如status2或3来表示而不是直接把记录delete掉。原因是业务数据需要保留完整链路管理员查历史数据时需要看到“曾有一套房源后来下架了”。而且MyBatis Plus的TableLogic可以帮你自动处理逻辑删除只需要在实体类字段上加上对应注解。2.3 看房预约状态机让业务流程有据可依预约状态是整套系统里最值得讲的一个点我在这里专门用一节来说因为它在笔试和答辩里的存在感太强了。我把预约状态定义为五个0待审核、1已通过、2已拒绝、3已完成、4已取消。状态之间的合法流转路径是待审核 - 已通过中介审核通过并填写看房安排。待审核 - 已拒绝中介审核不通过填写拒绝原因。待审核 - 已取消用户自己取消预约。已通过 - 已完成看房结束后标记完成。已通过 - 已取消用户或中介临时取消。为什么要限制这些状态流转路径因为如果你不在代码层面检查状态可能会出现“已拒绝的预约又被改成已完成”这种逻辑错误。我实现的方式是在Service层写一个状态流转的校验方法每次更新前先查当前状态只有符合流转规则的更新才放行否则抛出业务异常。代码大致是这样public void updateStatus(Long appointmentId, Integer oldStatus, Integer newStatus) { Appointment appointment appointmentMapper.selectById(appointmentId); if (appointment null) { throw new BusinessException(预约记录不存在); } // 校验状态流转是否合法 if (!canTransition(appointment.getStatus(), newStatus)) { throw new BusinessException(非法状态流转); } appointment.setStatus(newStatus); appointmentMapper.updateById(appointment); }状态不用枚举类的原因是为了灵活枚举类在扩展时得改代码重新编译但用常量定义也一样。你只要在代码里把状态值都定义成静态常量并写好流转校验整个系统在状态管理这块就能做到逻辑自洽。这个设计会在答辩时给你加很多印象分因为老师会觉得你不是简单写了一堆增删改查而是真正思考了业务约束。3. 核心功能实现预约、审核与状态流转的关键细节3.1 登录认证与接口权限控制拒绝裸奔式接口站在我个人的角度看一套毕设代码质量高不高第一个看他登录认证怎么写的第二个看接口有没有做权限验证。很多同学写的前后端分离项目后端接口全部裸奔前端跳一下登录页就算权限控制了这属于自欺欺人。我用的是比较适合毕设的JWT方案。用户登录成功后后端生成一个包含用户ID和角色信息的token返回给前端前端存储token并在每次请求的header里附带后端通过拦截器在进入controller之前校验token的合法性和时效性。核心逻辑大致是三步登录接口校验username和password成功后生成token返回。写一个HandlerInterceptor在preHandle里解析header中的token解析失败或过期则返回401状态码。把解析出的用户信息放入ThreadLocal或请求上下文中后续业务代码直接从上下文中取当前用户。这里踩过的一个大坑是“放行路径”没配好导致静态资源和部分公开接口也被拦截。我当时的处理是维护一个公开路径数组比如/apis/user/login、/apis/house/list、/apis/house/detail等放行其余请求全部需要token。用的是SpringBoot的注册拦截器方式registry.addInterceptor(jwtInterceptor()) .addPathPatterns(/apis/**) .excludePathPatterns(/apis/user/login, /apis/user/register);在角色控制上我再加了一层注解定义一个RequireRole(AGENT)注解或者直接在controller里用判断逻辑。毕设阶段不用做太复杂写一个简单的角色校验工具类在进入新增房源接口时校验当前用户角色是否为中介即可。成本很低但答辩时回答“接口权限怎么控制”就非常清楚。3.2 看房预约时间冲突检测不只是查一条记录做预约系统如果要挑一个最有区分度的功能点那就是时间冲突检测。很多初版实现就是直接insert一条预约记录完全不检查同一个时间段是否已经被其他看房预约占用。结果一个中介同一个上午被安排了三组客户在同一时间看同一套房这在实际业务里是完全不可接受的。我的实现思路是这样的在插入预约之前按“中介 房源 预约日期 预约时间段”维度去查询是否已存在状态为待审核或已通过的同时间段预约。如果查到了提示“该时间段已被预约请选择其他时间”。这里的时间段我做了个简单的划分上午09:00-11:30、下午14:00-17:00。在数据库里用appointment_time字段存储AM或PM即可。这样冲突检测的SQL就很好写SELECT COUNT(*) FROM appointment WHERE house_id #{houseId} AND appointment_date #{date} AND appointment_time #{timeSlot} AND status IN (0, 1)实际开发中我发现只按房源查不够应该再加一个agent_id。因为一个中介不止带看一套房他的日程需要全盘管理。比如同一时间段A房源和B房源的看房时间重叠这个中介也忙不过来。所以查询条件加上agent_id后整个冲突检测更符合真实中介的工作习惯。在代码层面我建议把冲突检测放在一个事务里先查询冲突再插入预约记录。用Transactional把这两个操作包起来避免并发下出现双写。虽然毕设一般不会真有并发压测但这样写了以后你可以在论文里理直气壮地写一段“通过事务和唯一约束实现预约排他性”。3.3 房源状态流转与筛选逻辑房源的上下架逻辑要和中介端、用户端联动。中介提交房源时默认状态是待审核管理员审核通过后变为已上架用户端才能看到。这个逻辑不难但很多同学会漏掉一个关键条件用户端房源列表查询时必须强制加状态过滤否则把管理员后代数据全暴露出来了。我实现的房源查询接口支持多条件组合筛选包括类型、区域、价格区间、关键词搜索。这里不得不提MyBatis Plus的条件构造器确实是个利器几行代码搞定动态SQLLambdaQueryWrapperHouseInfo wrapper new LambdaQueryWrapper(); wrapper.eq(HouseInfo::getStatus, 1); // 只查询已上架 if (StringUtils.hasText(type)) { wrapper.eq(HouseInfo::getHouseType, type); } if (minPrice ! null) { wrapper.ge(HouseInfo::getPrice, minPrice); } wrapper.orderByDesc(HouseInfo::getCreateTime);这里有个坑是分页。如果你直接使用传统的limit来手写分页配合前端的分页组件也不是不行但用MyBatis Plus自带的分页插件会更规范。需要配置一个分页插件拦截器Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }配置好后分页查询就是Page page对象传进去返回结果直接带总记录数和列表数据省很多事。4. 完整源码结构与部署上线从本地跑到演示视频4.1 项目目录结构与核心包职责好的项目结构不仅看起来专业更重要的是你自己开发时低班会少。我强烈建议后端代码按“controller - service - mapper - entity”四层结构组织并用Maven管理依赖本地打成jar包直接运行。一个标准目录大概是这样的src/main/java/com/example/house/ ├── common/ // 统一返回结果、异常处理、常量类 ├── config/ // WebMvc配置、拦截器注册、跨域配置 ├── controller/ // 接口层只做参数接收和返回 ├── entity/ // 数据库实体类 ├── mapper/ // MyBatis的Mapper接口 ├── service/ // 业务逻辑层 │ └── impl/ // 业务实现类 └── utils/ // JWT工具、日期工具、加密工具这个结构最大的好处是职责分明。controller层不写复杂业务serviceimpl里处理校验和状态流转mapper只跟SQL打交道。答辩时老师问你某个功能在哪实现你可以直接回答“在AppointmentServiceImpl的createAppointment方法里”听起来非常专业。前端部分我用的是Vue Element UI模板项目跑起来很快页面组件化开发对毕设来说足够友好。如果你不熟悉Vue也可以用简单的Thymeleaf服务端渲染但前后端分离的项目在演示时会更灵活简历上写“前后端分离项目”也比写“单体模板项目”好看。4.2 本地运行和部署时的踩坑记录很多毕设源码给出去以后最常被问的问题不是“这功能做得怎么样”而是“我怎么把项目跑起来”。我在自己部署的时候也折腾过几轮把典型的坑列一下第一个是数据库版本和连接配置问题。我用的是MySQL 8.0JDBC驱动包需要是com.mysql.cj.jdbc.DriverURL要带serverTimezoneCST这样的时区参数。很多同学配的是MySQL 5.x的驱动和旧URL连接直接报错。直接在springboot配置里写清楚这几个参数能省很多排查时间。第二个是Redis和中间件的问题。如果项目里集成了Redis本地没装Redis服务的话启动就会连不上。如果只是当缓存用我建议毕设阶段可以不用Redis减少部署时的一个不稳定因素。我当时做了一个站内消息功能用数据库表实现就好没必要硬上Redis。第三个是端口被占用的问题。SpringBoot默认8080端口如果本地开了别的服务启动时会提示端口被占用。直接在resources里把server.port改成8081或者其他端口就好。这个问题虽然简单但我在帮人调的时候遇到频率相当高。第四个是跨域问题。前端跑在5173端口Vite或8080端口之类的后端跑在8081前端请求时会有跨域拦截。我在后端Config里写了一个CorsFilter的配置放行所有来源毕设阶段这样做最稳妥。第五个是前端API地址写死的问题。默认模板里的axios请求地址可能还是localhost:8080如果后端改了端口前端不跟着改就会一直报请求失败。这里做一个建议配置把baseURL单独抽到一个配置文件里如果后面要换服务器只需改一处。部署方式上我建议打jar包mvn clean package -DskipTestsjar包生成在target目录下放到装有JDK和MySQL的服务器上直接运行java -jar house-0.0.1-SNAPSHOT.jar演示时你先启动MySQL再运行jar包前端项目启动npm run dev或打包后的dist目录放进Nginx整个系统就完整跑起来了。整个操作步骤录一个五分钟的演示视频绰绰有余。4.3 演示视频录制与答辩前调试清单演示视频这东西看起来容易实际录制起来也要花点心思。视频不要求多华丽但逻辑要顺。我第一次录的时候直接录屏幕鼠标乱晃、页面加载慢、还忘记展示数据库数据效果很差。后来按顺序录了一遍流程是启动后端和前端展示系统登录页。先演示普通用户注册、登录、搜索房源、查看详情、提交预约。切换到中介账号查看收到的待审核预约、通过预约、尝试在同一个时间段重复预约可故意碰一下冲突检测然后再演示另一个时间段预约成功。切换管理员账号展示用户管理、房源审核功能。最后展示数据库里对应的数据变化尤其是appointment表状态字段的变化这一步很加分。在答辩前我还专门调试了一遍系统里最容易出问题的点刷新页面时登录状态是否保持、预约审核后通知消息是否生成、分页点击第二页后筛选条件是否丢失。这些问题如果你不逐项检查演示现场翻车的概率非常大。我吃过一次亏演示视频录到一半发现用户预约后中介端看不到记录原因是中介端接口只按agentId查而预约表里agentId是在审核通过时才反填的待审核状态还没关联中介。这个逻辑在联调时才发现加班改了一晚上。这个经验告诉你接口调试时一定先想清楚数据是从哪来、到哪去而不是“前端有数据就自认为后端正常了”。5. 毕设答辩常见追问与嵌入式避坑经验5.1 论文LW里容易露怯的四个点论文这块很多同学都会在后半段开始写写得极其痛苦。我的经验是别把论文当作文要当作系统的说明书加设计依据。有几个位置是最容易暴露“你没真正做过”的第一个是“技术选型理由”部分千万别说“SpringBoot很好用所以我选了”要写清楚对比了SSM、SSH之后SpringBoot在自动配置、内嵌容器、微服务生态方面的优势以及本项目为什么适合用它。第二个是“数据库设计”部分最好附上ER图和表结构说明并把核心表的字段、类型、约束列出来尤其是appointment表的状态设计逻辑这是一个显示你进行了业务思考的关键点。第三个是“系统测试”部分不要只写“系统运行稳定”要有具体的测试用例。比如用例编号、输入数据、预期结果、实际结果。我的做法是准备了一张Excel表格把中断测试、重复预约测试、非法权限访问测试这些用例一条条列出来然后从系统里截图结果贴到论文里。答辩老师一眼就能看出这些是你真实跑过的不是编的。第四个是“总结与展望”别写“以后要加入大数据分析、人工智能推荐”这种不切实际的话。写点什么写“后续可以引入日历视图优化中介的日程管理通过WebSocket实现实时通知推送并优化移动端适配”。这些都是基于当前系统的合理扩展有落地可能老师不会觉得你想一出是一出。5.2 答辩现场的高频问题与回答样板根据我被提问的经验和后来帮同学模拟攒下来的题库这四类问题出现频率最高。第一类是关于“项目亮点”的提问。老师会问“你觉得你这个系统里最大的亮点是什么”。不要答“用了SpringBoot”这种一句话要具体。我当时的回答是“预约时间冲突检测和状态机约束机制。系统在预约提交时会校验同一中介同一时间段是否已经存在预约避免看房安排冲突同时预约状态严格按照预先定义的流转路径变化拒绝非法状态跳跃保证业务逻辑的严谨性。”这样答既有深度又有代码支撑。第二类是关于“某个业务的具体实现”。比如“用户取消预约后中介端怎么知道”。对应回答取消操作在service层中更新预约状态为已取消同时插入一条站内消息记录中介端首页查询最新的消息通知即可。你可以在演示时给他看站内消息那一块边点边讲。第三类是关于“安全和性能”的提问。比如“别人怎么保证系统安全密码存的是什么形式”。说清楚用了BCrypt加密token用JWT且设置了过期时间。性能方面则回答“目前毕设规模下通过索引优化查询列表接口在万级数据量下响应时间在100ms内若数据量进一步增长可通过Redis缓存和分库分表优化”。注意这类回答的准则就是实话实说不要吹牛。第四类是关于“部署方式”的提问。老师会问“这个项目你在哪里跑的线上有没有部署”。哪怕你只是在本地跑也可以说是“可以部署到CentOS服务器后端jar包运行前端dist静态资源放到NginxMySQL单独部署数据库连接通过配置控制”。把部署文档里写的流程清晰地讲一遍就行。5.3 给学弟学妹的几条实操心得最后这一部分不说空话直接给能落地的心得。第一不要迷信“完整源码一条龙”。市面上的“全bao”资源质量参差不齐很多源码能跑但你根本说不清业务逻辑答辩一问三不知。我的做法是拿一份结构清晰的源码做参考然后自己把核心模块预约、状态流转、权限控制重新写一遍。这样代码理解了论文也有素材了。第二开发顺序一定不要乱。你先建表写实体、再写mapper、再写service、再写controller、再连前端。每写一个接口就用postman或者curl测一下别攒到最后一下子联调。联调阶段的bug往往是最难定位的因为你不知道是前端参数传错了还是后端逻辑有误。第三数据库初始化脚本一定要维护好。我的做法是建一个sql目录里面按顺序放建库脚本、建表脚本、初始数据脚本。这样不管到哪台机器上都能一键重建环境。别直接用Navicat手动建表后不管后面换新环境就是灾难。第四尽量写单元测试。不需要很全面但至少要覆盖service层的核心业务逻辑尤其是预约时间冲突和权限校验这两个点。写几个单元测试一方面自己重构时有信心另一方面论文“软件测试”部分也有真东西可写。说实话这个项目做完以后你对SpringBoot的理解、对数据库设计的理解、对业务状态管理的理解都会上一个明显的台阶。不要把它当作一个“任务”去应对而是当作一个“完整的软件产品”去思考。当你能把这套房源、预约、状态、权限串成一个完整的业务故事讲给别人听的时候你的毕设就已经成功了一大半。最后再说一个实操里的小技巧答辩演示时把数据库的sql窗口放在屏幕一角边操作前端边指着后端日志或数据库变化这种“全链路”演示效果是最好的。祝各位顺利拿下。