做毕业设计这件事最怕的不是没创意而是代码写得云里雾里答辩的时候老师一问就卡壳。我陪学生折腾过不少课题今天要聊的这套基于SpringBoot的房屋售后服务系统算是其中最适合拿来当毕业设计原型的项目之一。它业务闭环清晰技术栈主流源码结构不复杂但五脏俱全从业主报修、工单派发到维修评价一条线全通。搞定它你相当于同时摸清了SpringBoot后端开发、Vue前端交互、MySQL表设计和Redis缓存的一整套流程。这篇文章我会把系统设计、核心表结构、关键代码片段、部署流程和答辩时的高频考点完整拆开内容全部基于我手头整理过多次的源码适合Java方向的大三、大四学生也适合想快速上手SpringBoot的初学者。下面我们开始。1. 项目定位与核心业务拆解1.1 房屋售后服务到底是一个什么系统房屋售后服务系统听起来有点企业级但本质上就是物业维修管理的信息化底座。小区住户遇到水管漏水、电路故障、墙面开裂这类问题以前是打电话给物业物业再手写派工单维修师傅干完活还要回办公室补登记住户有没有满意也无人跟踪。这套系统就是把整条链路搬到线上住户在线提交报修客服或管理员审核派单维修师傅接单干活最后住户评价完单子才算真正闭环。它解决的痛点非常明确一是进度不可见二是责任难追溯三是维修记录散落。作为毕业设计这个选题好就好在业务规模不大但流程完整。它天然横跨多个角色包含权限控制、状态流转、文件上传、数据统计既有增删改查又有业务规则判断。哪怕只做单体的 SpringBoot 工程也能讲出足够多东西。更重要的是答辩老师一听“房屋售后”就能直观理解系统价值不需要像解释“企业级中台”那样费半天口舌。你后续如果想加亮点还可以拆微服务、接消息队列扩展空间非常清晰。1.2 角色划分和功能清单这套系统我按四种角色来拆每个角色的页面和接口都不一样这在答辩时很好讲清楚职责边界业主注册登录、绑定房屋、提交报修单、上传现场照片、查看维修进度、完成后评价。物业客服审核报修单、派单给维修工、催单、关闭异常工单、确认费用清单。维修师傅查看被派工单、接单、更新维修状态、填写维修材料和费用。系统管理员维护用户、房屋、基础字典、查看全局统计报表。功能模块大致包括登录注册、房屋绑定、报修单管理、工单派发、维修处理、材料费用记录、服务评价、消息通知、统计看板。我实际做项目时还加了一个费用审核环节维修工提交材料后要客服二次确认才计入结算这样流程更严谨。你在做自己的毕设时可以按需裁剪但核心的“报修—派单—维修—评价”这条闭环一定不能少少了就撑不起“售后服务”这个题目。角色和可用模块我习惯用一张表直接列出来也方便后面写权限设计文档功能模块业主客服维修工管理员房屋绑定是否否是提交报修是否否否报修审核否是否是派单调度否是否是接单与维修否否是否材料费用登记否是是是服务评价是否否否统计报表否是否是这张表在开题报告里可以直接复用老师扫一眼就知道你不是只做了一张表随便增删改查。2. 技术选型与SpringBoot底层原理2.1 后端为什么选SpringBoot 2.7 MyBatis-Plus后端技术栈我最终定的是SpringBoot 2.7.x、JDK 1.8或11、MyBatis-Plus 3.5.x、Redis、Spring Security JWT。这里特别说明一点我刻意避开 SpringBoot 3.x虽然3.x已经很成熟但毕业设计更看重资料丰富度和环境兼容性。3.x从javax.*换成了jakarta.*很多老教程、老代码片段直接复制会报错实验室老电脑上还可能遇到 JDK 版本不匹配的问题。用2.7.x网上问题库最全踩到坑基本搜一下就能解决。MyBatis-Plus 比原生 MyBatis 舒服的地方在于 CRUD 不用写 SQLBaseMapper直接提供selectById、insert、updateById分页插件也现成。配合LambdaQueryWrapper比如“查询某个用户待处理的报修单”这种操作一行就能写出来业务代码能少三分之一。但你要能说清楚它底层是怎么动的答辩才不会露怯MyBatis-Plus 本质上是在 MyBatis 基础上封装了通用 Mapper 和条件构造器最终仍会生成 SQL 交给数据库执行。SpringBoot 的自动装配原理是另一个必考点。要记住SpringBootApplication里藏着EnableAutoConfiguration它会扫描spring.factories或spring-autoconfigure-metadata.properties中声明的 AutoConfiguration 类再通过ConditionalOnClass、ConditionalOnMissingBean这类条件注解判断是否真正创建 Bean。比如你引入了spring-boot-starter-data-redis但当前环境里没有 Redis 相关类RedisTemplate 就不会被装配。这个机制就是“约定大于配置”的技术底座。2.2 前端技术栈与接口交互设计前端我用的是 Vue3 Element Plus Axios Vue Router这套组合对毕设足够视觉上也不至于太简陋。如果你对 Vue 不熟网上确实有很多现成脚手架可以直接改但既然是毕业设计还是建议至少自己搭一遍不然后面答辩时路由守卫、跨域这些概念根本答不上来。前后端交互一定要定统一规范。我的接口返回结构统一是{ code, message, data }登录成功后在响应头返回 token前端通过 Axios 拦截器塞进后续请求头里。全局请求拦截器收到 401 就跳转登录页并清除本地用户信息。路由守卫里根据角色动态渲染菜单比如业主登录后根本看不到“派单管理”入口。这个细节在答辩时非常加分因为它证明你理解了“前端展示层”和“接口权限”是两件事。2.3 文件存储用本地还是上MinIO报修单往往要传现场照片这天然带出一个存储问题。毕业设计我不建议一上来就接阿里云 OSS 或腾讯云 COS除非你本来就在云服务器上折腾否则只会白白增加支付和密钥管理的复杂度。最省事的方案是本地存储上传文件保存到服务器或本机的某个目录再让 Nginx 直接指向这个目录做静态访问路径存进数据库就行。等你把核心功能全部跑通有余力再换 MinIO。MinIO 的好处是开源、自建、兼容 S3 协议用 Docker 起一个容器也就一分钟的事。我在项目里专门抽象了FileStorageService接口本地实现类就是save(file)然后返回 URLMinIO 实现类换成putObject那套 SDK 调用。业务层只依赖接口切换存储方案时改一个配置就行。这种面向接口的设计也是答辩时的加分项。3. 数据库设计与工单状态机3.1 核心表结构与业务关系梳理这套系统的数据库我建议按九个核心表来做用户表、角色表、用户角色关联表、菜单权限表、房屋表、报修单表、工单表、维修材料费用表、服务评价表。其中用户、角色、菜单三张表做 RBAC用户角色关联表是为了多角色扩展比如一个用户既是业主又是物业工作人员登录时加载不同权限集合。表关系大概是这样的一个用户可绑定多个房屋一个房屋可提交多条报修单一条报修单经过审核后生成一张工单一张工单对应多条维修材料费用记录和一条服务评价。房号地址我建议只存一个house_no字符串字段比如“3栋2单元501”后台管理员维护楼栋字典前端下拉选择就行不用硬去建模小区—楼栋—单元—房号的四级树那是企业级的需求毕设时间做不完也讲不透。3.2 报修单表 DDL 与字段设计逻辑以报修单表为例我贴一下实际跑通过的简化版本CREATE TABLE repair_order ( id bigint NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL, user_id bigint NOT NULL, house_id bigint DEFAULT NULL, repair_type varchar(50) DEFAULT NULL, description text, image_urls varchar(1000) DEFAULT NULL, status tinyint NOT NULL DEFAULT 0, priority tinyint NOT NULL DEFAULT 1, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;字段设计上几个点容易答辩被追问。order_no是业务编号加了唯一索引因为前台展示、客服电话沟通都需要一个可读编号直接用自增主键看上去不够规范而且后面统计、导出Excel和数据迁移都靠这个编号关联。status用 tinyint 存状态枚举值不直接用字符串一是存储更紧凑二是代码里可以用枚举类控制合法流转。image_urls我的做法是存 JSON 数组字符串比如[/upload/a.jpg,/upload/b.jpg]读取时用 Fastjson 或 Jackson 解析成 List比另建一张子表简单得多而且多图场景完全够用。3.3 工单状态机与状态流转控制工单的状态流转是这个项目最重要的业务逻辑也是最值得讲的点。我这里定义一套状态枚举状态码状态含义可流转到0待审核已派单、已取消1已派单维修中、已取消2维修中待验收、已取消3待验收已完成、维修中4已完成已评价5已评价无6已取消无实现时建议在 Service 层统一写一个changeStatus(order, targetStatus, userId)方法先根据当前状态和目标状态查枚举表判断是否存在合法流转再更新数据库并写入一张操作日志表。不要把状态判断散落在 Controller 和 Mapper 里否则后期维护和排查问题会非常痛苦。答辩时老师如果问“怎么避免维修工恶意把已完成回退到已派单”你就可以答“状态机只允许从待验收回退到维修中不允许逆向跳过多级”这个回答比简单说“我在前端禁用了按钮”要硬核得多。4. 核心功能实现与源码级拆解4.1 登录认证与JWT权限控制登录模块我使用 Spring Security JWT这里给出一个极简的 JWT 生成工具示例public String generateToken(Long userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(role, role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() 7200 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); }生成 token 时会塞入 userId 和 role过期时间设为两小时。登录接口收到用户名密码后先拿 BCrypt 加密密码和数据库比对通过后生成 token 返回前端。接下来是一个OncePerRequestFilter拦截所有/api/**请求解析 token、校验签名和过期时间把 userId 和角色存进SecurityContextHolder。如果解析失败直接返回 401 JSON而不是跳到登录页。配置层的核心是放行白名单和受保护路径Bean SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.csrf().disable() .authorizeRequests() .requestMatchers(/api/auth/**, /upload/**).permitAll() .requestMatchers(/api/repair/**).hasAnyRole(USER, WORKER, ADMIN) .requestMatchers(/api/worker/**).hasRole(WORKER) .requestMatchers(/api/admin/**).hasRole(ADMIN) .anyRequest().authenticated(); return http.build(); }这里要注意/api/auth/**一定不能拦截否则登录都进不去。很多同学第一次做毕设时把整个鉴权过滤器注册到了所有接口上结果登录接口反复飘 401排查了半小时才发现是白名单没配。提这个坑是想提醒你排版上简单的配置实际执行顺序很容易出问题。4.2 报修单提交与文件上传实现业主提交报修是最常见的操作前端表单里填写维修类型、问题描述再上传一到三张照片。后端接口我设计了两个接收参数一个是文件数组一个是 JSON 格式的报修单 DTO用RequestPart和RequestBody分开接收PostMapping(/repair) public Result createRepair(RequestPart(files) MultipartFile[] files, RequestPart(repair) String repairJson) throws Exception { RepairOrderDTO dto objectMapper.readValue(repairJson, RepairOrderDTO.class); ListString urls fileStorageService.upload(files); return Result.ok(repairOrderService.createRepair(dto, urls)); }Service 层里必须做几个业务校验查询当前登录用户的 userId、判断houseId是否属于该用户、描述是否为空、近期是否已经存在同一房屋同一类型的待处理报修单防止用户重复下单。全部通过后才插入repair_order表和操作日志。这个校验逻辑是答辩时展示“你考虑到了真实场景”的绝佳素材因为绝大多数同学只会做“拿到表单直接 insert”。4.3 派单调度与维修工负载均衡派单是这套系统里最有技术含量的一环也是我建议你重点优化的地方。最简单的手动派单是客服在工单列表里选中一个维修工点击“派单”更新工单表的worker_id。更聪明一点的做法是自动派单根据报修单的repair_type匹配维修工技能再统计每个维修工当前正在处理的未完成工单数选择最少的那一个。我直接用一条 SQL 就能完成SELECT u.id, COUNT(w.id) AS handling_count FROM user u LEFT JOIN work_order w ON w.worker_id u.id AND w.status IN (1, 2) WHERE u.role WORKER AND u.skill_type #{repairType} GROUP BY u.id ORDER BY handling_count ASC LIMIT 1;这条 SQL 看似简单但体现了“负载均衡”的思想不选最闲的而是选当前处理工单最少的人避免个别师傅被累死、另一个师傅闲到发慌。自动派单后生成一条工单记录并给维修工发送一条站内消息。项目里如果不接 WebSocket 推送前端可以用轮询定时刷新待办数效果也足够。4.4 评价闭环与统计报表维修工把状态改成“已完成”之后业主那边就能看到评价按钮。评价表记录了工单号、评分、评价内容、评价时间。这里要注意业务规则一张工单只能评价一次如果已经存在评价记录后端直接拒绝二次提交。ServiceImpl 里先按workOrderId查评价表再判断工单当前状态是不是已完成双重校验后才写入评价记录并把工单状态改为已评价。统计报表我建议至少给管理员提供三个维度本月报修单数量、按维修类型分组统计、维修平均完成时长。实现上不需要复杂的 OLAP直接SELECT repair_type, COUNT(*) FROM repair_order WHERE create_time BETWEEN ? AND ? GROUP BY repair_type就能出来前端用 ECharts 画柱状图和折线图。答辩时展示一个动态图表比纯表格输出效果好很多。5. 部署落地与避坑指南5.1 本地开发环境搭建这套系统我开发时用的是 JDK 1.8、Maven 3.8.8、MySQL 8.0、Redis 5.0、Node.js 16IDE 用的 IDEA。环境准备顺序建议是先装好 MySQL 和 Redis再导入数据库脚本init.sql然后启动后端最后启动前端。SpringBoot 后端配置集中在application.yml我摘取关键部分server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/house_repair?serverTimezoneAsia/ShanghaiuseUnicodetruecharacterEncodingutf8 username: root password: 123456 redis: host: localhost port: 6379 mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml global-config: db-config: logic-delete-field: deleted这里有两个必须提前做的动作一是 MySQL 上先建库不然启动会直接报连接失败二是serverTimezoneAsia/Shanghai一定要加上否则时间字段可能出现 8 小时时差。Redis 如果本地没装去官网下载 Windows 版本或直接用 Docker 拉一个redis:5.0镜像都很简单。5.2 服务打包与上线部署毕业设计如果只是本地跑给老师看其实已经合格。但如果你想加分可以提前部署到云服务器上。后端打包非常简单mvn clean package -DskipTests nohup java -jar target/house-service-0.0.1-SNAPSHOT.jar app.log 21 前端打包npm run build生成的dist目录放到 Nginx 的html目录下再配置反向代理location /api/ { proxy_pass http://localhost:8080; proxy_set_header Host $host; }这个配置的意思是前端把接口请求都写成/api/xxxNginx 收到后转发到 SpringBoot 的 8080 端口。注意前端 Axios 的 baseURL 要写成/api不要带着 8080 写死否则上线就跨域。如果你只是本地联调直接在 IDEA 里启动后端再用 dev 模式跑前端更省事部署方案等答辩前一天准备也不迟。5.3 开发期踩过的5个高频坑这里把我的踩坑记录整理成列表每一条都是实战中真实出现过的MyBatis-Plus 自动填充时间不生效。即使你在数据库设置了DEFAULT CURRENT_TIMESTAMP代码层面仍然可能在插入时传空值。我忘了给实体类的createTime加TableField(fill FieldFill.INSERT)注解也没有实现MetaObjectHandler结果所有新增数据的创建时间都是 null。这个坑遇到一次就不想遇到第二次。前端跨域报错。直接写http://localhost:8080去请求结果浏览器拦截。解决方案两种后端加CorsFilter或者前端把请求统一为/api并让 Nginx 或代理转发。毕设阶段用CorsFilter最快记得allowedOriginPatterns(*)要写到allowedOrigins才会生效。LocalDateTime 序列化问题。后端返回LocalDateTime字段前端看到的是{year:2025,month:7,day:1}这种数组结构不是预期的2025-07-01 12:30:00。原因是 Jackson 默认序列化 Java 8 时间类型有问题需要配置ObjectMapper注册 JavaTimeModule 并指定日期格式。JWT 过滤器把白名单拦截了。我一开始把自定义过滤器加在TokenContextFilter上但是SecurityConfig里没有放行登录、注册接口导致前端登录请求直接 401。加一遍白名单配置再顺手验证toString()也没用得用requestMatchers精确匹配。Redis 反序列化乱码。用默认的JdkSerializationRedisSerializer存对象控制台能看到\xAC\xED\x00\x05的乱码前缀排查问题异常痛苦。要改成Jackson2JsonRedisSerializerObject并且把存储的 DTO 类实现可序列化接口这样缓存内容能直接看清结构。每一条坑都适合写进答辩“难点与收获”里老师听了会觉得你是真调试过不是拿别人的源码硬背。6. 项目结构、答辩要点与源码获取6.1 后端分层结构与代码规范我习惯把代码按这种结构组织简单清晰也符合课程设计习惯springboot-house-service/ ├── controller/ # 接口层负责参数接收和结果返回 ├── service/ # 业务层接口impl ├── mapper/ # MyBatis-Plus Mapper接口 ├── entity/ # 数据库实体 ├── dto/ # 前端传入参数 ├── vo/ # 前端展示对象 ├── config/ # 配置类Security、Redis、MybatisPlus ├── utils/ # 工具类JwtUtil、ResponseUtil ├── common/ # 公共类结果封装、异常处理 └── resources/ ├── mapper/ # XML文件 └── application.ymlController 只负责参数接收和结果封装业务逻辑全部下沉到 ServiceM层不写复杂 SQL只承担查询和更新。这样答辩时老师打开代码一看结构就明白你懂分层而不会看到一个 N 万行的 Controller 喷你设计不合理。entity和vo分开也很重要前端要的是脱敏字段数据库表可能存了密码你总不能直接把用户实体整个返回出去。6.2 论文和答辩高频问题一览结合我这几年带毕设的体验房屋售后系统这个题目被老师盯住的问题基本集中在下面这些为什么选 SpringBoot 而不是 SSM回答重点SpringBoot 基于“约定优于配置”自动装配省去大量 XML 配置且生态成熟starter 一键集成第三方组件。同时补一句“底层仍然是 Spring 容器”显得你不是只会用脚手架。工单状态是怎么保证不会乱跳的回答重点状态枚举定义合法流转表Service 统一校验非法状态直接抛业务异常数据库层可以用CHECK约束兜底。你写不出复杂状态机模式但这个回答足以证明思路。用户权限怎么控制回答重点RBAC 数据模型用户—角色—权限三层登录签发 JWT后端通过 Spring Security 过滤器解析 token方法上按角色加PreAuthorize。如果短时间内大量用户同时提交报修系统会不会挂回答重点至少答出 Redis 缓存热点小区和维修类型数据、数据库连接池调优、接口做幂等防重、静态资源走 Nginx 缓存。然后承认毕设阶段未做分布式压力测试是自己后续改进方向。这样既展示了思考深度又显得诚实。为什么把报修单和工单拆成两张表回答重点报修单是业主提交的信息工单是维修执行流程的数据两者状态不同、操作角色不同。拆分后便于派单记录历史、多维修工协作、统计维修工时。这些问题你按答案写成文档答辩前背熟三遍基本不会冷场。6.3 源码获取与二次扩展建议这套系统的完整源码我已经整理到 Gitee 上仓库名是house-service-springboot里面有init.sql、后端完整工程、前端 Vue3 工程和一份 README 部署说明。你 clone 下来之后按 README 里的步骤改数据库账号密码和 Redis 地址大概率一个小时之内就能跑起来再对着数据库脚本看二遍核心表结构整个业务逻辑就通了。如果你想在毕设基础上做二次扩展我建议优先考虑三个方向一是给维修工端接入 WebSocket工单派发后页面实时弹通知替代目前的前端轮询二是增加维修工绩效排行榜按完成工单数和客户评分加权计算这会让项目更有业务深度三是把报修单模块抽成独立微服务用 OpenFeign 调用工单服务配合 Nacos 注册中心这样项目就能往“分布式架构”上聊聊了。三个方向任选其一工作量可控答辩时亮点却非常突出。我个人做完这套系统后最大的体会是毕业设计不一定要追求高大上但一定要有一条从头打到尾的闭环业务。报修、派单、维修、评价这条链路代码量不多却把权限、状态、存储、统计全串起来了。你真正照着敲一遍理解的不只是 SpringBoot 怎么用更是“一个系统从需求到落地到底经历了什么”。希望我这些踩坑经验能帮你少走一段弯路也祝你答辩那天地超常发挥一次性通过。