做毕业设计或者接私活的时候看到“基于JavaSpringBootSSM物业报修系统”这种标题很多人的第一反应是这不就是拿SpringBoot套了个SSM的壳吗等你真正动手把物业报修流程跑通才发现框架配置反而是最省事的一环真正花时间的全是报修业务里的“工单怎么流转、角色怎么分工、状态怎么同步、并发下会不会被重复接单”这些具体问题。这篇文章就把我做完这套系统之后的核心设计思路、数据库表结构、关键实现和踩坑记录全部拆开来讲适合在写这类课题的在校生也适合想快速落地一个报修类管理系统的开发者参考。1. 从报修单到工单闭环物业报修系统的业务建模思路1.1 物业报修场景里的三个角色与四条主线很多同学拿到这个题目第一件事是画用例图画完发现角色和功能堆了一大堆但真正落到代码里不知道先写哪张表。我建议反过来先从“角色在这套系统里到底要干什么”去倒推。物业报修系统里最核心的角色就三个业主、维修工、物业管理员。业主提交报修、查看处理进度、完工后评价。维修工查看被分配的工单、接单、填写处理结果、申请完工。管理员审核报修、派单给合适维修工、管理用户和报修类别、查看统计报表。三条人物线一出来数据流就清楚了。业主提交一张报修单管理员收到之后判断是否合理、是否在物业维修范围内然后派给对应工种的维修工维修工接单、处理、完工业主确认后评价管理员全程看得到状态。这就是一条完整的“报修闭环”。我见过不少项目把“报修单”和“工单”当成两张分开的表去设计然后代码里还得做复杂的关联和同步后期维护特别痛苦。实际做这个体量的系统完全不需要拆成两张表。报修单就是工单用状态字段去标记当前处于哪个环节就行。一张repair_order表加上创建时间、派单时间、接单时间、完工时间这几个时间戳整个生命周期就都被记录下来了查询报表也好写。1.2 工单状态流转报修单的生命周期设计状态设计是这类系统的灵魂也是答辩时老师最爱问的点。我最终落地的状态机是这样的状态值状态含义说明0待审核业主刚提交管理员还没处理1待派单审核通过等待管理员分配维修工2待接单已派给维修工等待维修工接单3维修中维修工已接单正在处理4待验收维修工提交完工等待业主确认或管理员复核5已完成业主确认完成且已评价6已拒绝管理员审核不通过需填写拒绝原因7已取消业主在未派单前主动取消这里有一个设计要点不要允许任意状态互相跳转。比如待审核状态不能直接跳到已完成待派单状态不能直接变成维修中。状态变更必须走一条合法路径待审核 → 待派单 → 待接单 → 维修中 → 待验收 → 已完成。我建议把状态流转校验写在 Service 层用if 枚举判断当前状态是否允许执行某个操作。尽量不要用状态机框架功能太轻引入框架反而增加学习成本。比如“接单”这个方法里第一行先判断这个工单的状态是不是待接单不是就直接抛异常。这样写虽然看起来土但逻辑最直白出问题也好排查。尽量别只在前端隐藏按钮来控制状态接口层面必须做校验否则绕过前端直接调接口就能把状态改乱了。1.3 功能边界哪些模块必须做哪些可以砍掉毕设项目最怕功能贪多做到最后每个功能都是半成品答辩演示时反而露怯。我给这套系统划定的功能边界是这样的业主端报修申请、报修记录列表、报修详情、进度跟踪、取消报修限未派单时、待办评价、历史评价。维修工端我的工单、接单、填写处理记录、申请完工、查看历史工作量。管理员端待审核列表、审核操作、派单操作选择维修工、全部工单管理、用户管理、楼栋管理、报修类别管理、数据统计。公共模块登录注册、密码修改、个人资料维护。砍掉的是在线支付报修不涉及费用、消息推送改成站内通知即可、积分系统这些“看起来高端但核心用不到”的模块。如果后续想扩展可以在工单表加一个fee和pay_status字段针对需要收费的维修项目做线下登记但第一版千万别铺开做。2. SpringBoot与SSM整合这套技术组合的真实分工2.1 SpringBoot和SSM到底什么关系为什么毕设标题都爱这么写新手上路问得最多的一个问题SpringBoot 框架里已经内置了 Spring 和 SpringMVC为什么标题还要写“SpringBootSSM”实际上 SSM 指的是 Spring、SpringMVC、MyBatis 这三件套而 SpringBoot 把前两个整合掉了同时通过 starter 让 MyBatis 的配置也大幅简化。所以这套系统的真实技术栈是SpringBoot 负责自动配置和启动管理SpringMVC 负责请求分发和参数绑定MyBatis 负责数据库访问三者一起构成了完整的后端开发框架。为什么很多课程设计题目沿用“SpringBootSSM”这个叫法一方面是因为教材和参考项目长期用这个名字另一方面SSM 代表的是这套技术组合的经典路径——如果面试官问你 SpringMVC 的 DispatcherServlet 流程、MyBatis 的二级缓存机制你依然能说清楚底层原理这正是毕设题目想考察的东西。2.2 分层架构与包结构设计我的项目模块结构可以参考下面这个分包方式com.property.repair ├── controller # 控制层接收请求返回结果 ├── service # 业务接口 │ └── impl # 业务实现 ├── mapper # MyBatis数据访问接口 ├── entity # 实体类 ├── dto # 数据传输对象比如分页参数、登录返回结果 ├── vo # 视图对象用于给前端返回特定字段 ├── config # 全局配置拦截器、文件上传、跨域 ├── common # 统一返回结果、异常处理、常量、枚举 └── utils # 工具类比如JWT、日期处理这里要重点说一下 controller/service/mapper 的职责划分。实际写代码时新手最容易犯的错是把业务逻辑写在 Controller 里。比如“派单”这个操作Controller 里应该只做参数接收和结果返回真正的状态校验、数据落库、通知生成必须全部放在 Service 中。这样做的直接好处是功能变复杂之后逻辑可复用测试也好写。比如管理员派单和系统自动派单底层可以复用同一个assignOrder(orderId, workerId)方法。还有一点容易忽略实体类不要直接返回给前端。我的做法是定义 VO 类比如RepairOrderVO里面只包含前端需要的字段同时把状态码转换成对应的状态描述文字比如把status3转成“维修中”。这样前端拿到的就是可以直接渲染的数据不需要再做一次翻译。Mapper 查询时使用resultMap或者直接查视图对象不要查询所有字段再手动剔除敏感信息。2.3 关键配置与整合细节pom.xml里的依赖没有太多花样核心是这几项dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.2/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependencyapplication.yml里有一个新手很容易忽略的配置下划线字段到驼峰属性的自动映射开关。MySQL 的字段命名为create_timeJava 属性命名为createTime如果不开启驼峰映射MyBatis 查出来的结果里这个字段就是 null而且排错很费劲。mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.property.repair.entity configuration: map-underscore-to-camel-case: true logging: level: com.property.repair.mapper: debug把 Mapper 包下的日志级别设为 debug 也非常有用。开发阶段可以直接在控制台看到执行的 SQL 和参数排查问题效率翻倍。等项目上线前再调回 info 就行不需要删配置。3. 数据库设计几张核心表撑起整个报修业务3.1 用户与角色的设计取舍用户表的设计里角色字段我建议直接用roletinyint1 表示业主、2 表示维修工、3 表示管理员。不要一开始就引入 RBAC 权限表用户角色中间表、角色权限中间表对这个项目来说过度设计写起来复杂答辩时如果讲不清反而被问倒。真正的权限控制其实只需要一个拦截器校验登录状态和角色类型就行。用户表user的核心字段如下CREATE TABLE user ( id int NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL, password varchar(100) NOT NULL, real_name varchar(50) DEFAULT NULL, phone varchar(20) DEFAULT NULL, avatar varchar(255) DEFAULT NULL, role tinyint NOT NULL DEFAULT 1, building_id int DEFAULT NULL, status tinyint NOT NULL DEFAULT 1, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;两点说明第一密码不要明文存。至少用 MD5 加盐或者直接用 BCrypt。Spring Security 你可以不引入全套只把spring-security-crypto依赖拿出来用它的 BCrypt 工具类很小很实用。第二building_id关联到楼栋表用于后续统计“哪个楼栋报修最多”这也是答辩时一个不错的展示点。3.2 报修工单表核心字段与状态字段设计工单表repair_order是这个系统最重要的表字段设计要同时兼顾业务记录和统计需求。CREATE TABLE repair_order ( id int NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 工单编号, owner_id int NOT NULL COMMENT 报修人id, title varchar(200) NOT NULL COMMENT 报修标题, description text COMMENT 报修详细描述, images varchar(1000) DEFAULT NULL COMMENT 报修图片多张用逗号分隔, location varchar(255) DEFAULT NULL COMMENT 具体位置比如3栋2单元501门口, category_id int DEFAULT NULL COMMENT 报修类别水电/门窗/电梯/网络等, priority tinyint DEFAULT 2 COMMENT 优先级1紧急 2普通 3低, status tinyint NOT NULL DEFAULT 0 COMMENT 工单状态0-7, assign_time datetime DEFAULT NULL COMMENT 派单时间, worker_id int DEFAULT NULL COMMENT 维修工id, accept_time datetime DEFAULT NULL COMMENT 接单时间, finish_time datetime DEFAULT NULL COMMENT 完工时间, cancel_reason varchar(500) DEFAULT NULL COMMENT 取消原因, reject_reason varchar(500) DEFAULT NULL COMMENT 审核拒绝原因, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;order_no工单编号建议单独生成不要直接用自增主键。可以取“当前时间 三位随机数”比如20250525143012123生成规则类似于yyyyMMddHHmmss 3位随机数这样在外观上更像正式工单号演示时观感也好。唯一索引一定要加重复工单号会直接报错早发现问题比晚发现成本低。很多同学会问工单状态要不要用枚举我的回答是数据库字段用tinyint存Java 代码里一定用枚举定义这样代码里不会到处出现魔法数字。StatusEnum里同时放状态码、状态描述、可跳转的下一状态集合Service 层做状态校验时直接读枚举比散落一地的if (status 2)好维护一百倍。3.3 辅助表评价、通知、报修类别与楼栋信息报修类别表id、name、sort、status简单即可。注意在派单逻辑里每个维修工可以设置一个擅长类别派单时优先匹配同类别的维修工。评价表id、order_id、owner_id、rating1-5分、content、create_time。评价表跟工单表是一对一关系但没必要把评价字段直接塞到工单表里单独建表更符合渐进式业务演进以后想扩展“匿名评价”“评价回复”都有空间。通知表id、user_id、title、content、is_read、create_time。这个表很关键报修进度变化时往里面插入一条通知业主登录后在导航栏看到未读角标。不用对接短信、不用对接邮件这个方案对学生项目来说最合适演示效果也直观。楼栋表不做太多字段id、building_name、address即可。用户注册时可以选择所在楼栋统计页面按楼栋聚合报修数。数据库设计这块坚持一个原则能不加外键就不加外键逻辑外键用索引代替。外键会影响插入删除的性能而且写烂了之后排错非常痛苦。靠 Service 层保证数据的关联完整性对这套系统来说完全够用。4. 核心功能实现报修提交、派单接单、完工评价全链路4.1 业主端报修提交图片上传与表单处理的完整链路报修提交是整个系统的入口实现方式决定了用户第一印象。表单字段至少要包含标题、描述、图片、具体位置、报修类别、紧急程度。图片上传这部分单独说一说因为踩坑的人太多了。前端用 后端的文件上传保存逻辑我建议这样写public String uploadImage(MultipartFile file, HttpServletRequest request) { if (file.isEmpty() || file.getSize() 5 * 1024 * 1024) { throw new BusinessException(图片大小不能超过5M); } // 校验文件类型防止上传jsp等危险文件 String ext StringUtils.getFilenameExtension(file.getOriginalFilename()); if (!Arrays.asList(jpg, jpeg, png, gif).contains(ext.toLowerCase())) { throw new BusinessException(不支持的图片格式); } String dir uploadDir /images/ LocalDate.now(); File dirFile new File(dir); if (!dirFile.exists()) { dirFile.mkdirs(); } String filename System.currentTimeMillis() _ UUID.randomUUID().toString().substring(0, 8) . ext; file.transferTo(new File(dirFile, filename)); return /images/ LocalDate.now() / filename; }这里有个非常关键的点transferTo的保存路径和访问路径如果不一样前端展示时就会 404。我是在配置类里实现WebMvcConfigurer的addResourceHandlers把本地保存目录映射成一个虚拟 URL 路径Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/images/**) .addResourceHandler(file: absoluteUploadDir /images/); }这个虚拟映射配置好之后图片保存到磁盘浏览器访问的 URL 路径还是/images/xxx.jpg不需要让前端感知到服务器磁盘路径。然后是报修提交的 Service 逻辑。事务注解是必须的因为要同时插入工单表和通知表Transactional(rollbackFor Exception.class) public Long submit(RepairOrderSubmitDTO dto) { validateOwner(dto.getOwnerId()); RepairOrder order new RepairOrder(); order.setOrderNo(generateOrderNo()); order.setTitle(dto.getTitle()); order.setDescription(dto.getDescription()); // ... 其余字段赋值 order.setStatus(0); // 待审核 repairOrderMapper.insert(order); // 通知管理员可以用SQL批量插入所有管理员 notificationService.notifyRole(3, 收到新的报修工单, 工单号 order.getOrderNo()); return order.getId(); }4.2 管理员审核派单与维修工接单的双重校验派单这个操作算是整套系统里业务规则最密集的地方。管理员从待审核列表点击“通过”状态从 0 变为 1再点击“派单”弹出一个列表列出来所有维修工管理员选择某个维修工后状态从 1 变为 2同时把维修工ID写进worker_id。看起来不复杂但“派给谁”这个决策是有逻辑的。比较合理的方案是派单时按“维修工所属类别”过滤一遍。比如这张单子类别是“水电”那就只展示擅长“水电”的维修工。这样既符合真实物业的管理方式也避免了维修工接到自己不擅长的活。实际编码时用一个简单的关联查询即可完成select idselectWorkersByCategory resultTypecom.property.repair.entity.User SELECT u.* FROM user u WHERE u.role 2 AND u.status 1 if testcategoryId ! null AND u.category_id #{categoryId} /if /select维修工接单时的并发问题我单独拿出来说。两个维修工同时抢同一个工单如果代码只做了“判断状态是否为待接单”再更新那么在高并发下两个人可能都通过校验导致一个工单被接两次。解决办法有两种第一在更新语句里带上状态条件int count repairOrderMapper.acceptOrder(orderId, workerId, expectedStatus); if (count 0) { throw new BusinessException(工单已被其他人接单); }对应的 SQL 是UPDATE repair_order SET status 3, worker_id #{workerId}, accept_time NOW() WHERE id #{orderId} AND status #{expectedStatus}这个 SQL 本质上就是一个乐观锁利用受影响行数判断是否更新成功不用再引入额外的版本号字段简单可靠。这是我在这个项目里最推荐的一个写法务必掌握。4.3 完工、验收与评价闭环的最后一步维修工完工时提交处理结果可以加一个handle_content字段存维修过程描述。状态从 3 变为 4同时插入一条站内通知给业主请业主确认并评价。业主看到“待验收”状态时如果确认已经修好就点击“确认并评价”评价内容包括评分和文本。这个操作涉及两张表评价表插入一条记录工单表把状态从 4 变为 5。两件事必须在一个事务里完成否则就会出现“工单已完成但没有评价记录”的脏数据。这里涉及一个事务失效的经典坑如果这两个操作分别写在evaluationService和repairOrderService里然后在 controller 里逐个调用看起来也能成功但一旦中途抛异常可能会出现工单更新成功、评价记录没插入的情况。正确做法是把这两个操作合并到同一个 Service 方法里并加上事务注解Transactional(rollbackFor Exception.class) public void completeOrder(Long orderId, Long ownerId, Integer rating, String content) { // 校验状态是待验收 int count repairOrderMapper.finishOrder(orderId, ownerId, 4, 5); if (count 0) { throw new BusinessException(当前工单状态不允许评价); } Evaluation evaluation new Evaluation(); evaluation.setOrderId(orderId); evaluation.setRating(rating); evaluation.setContent(content); evaluationMapper.insert(evaluation); }finishOrder的参数中也可以直接指定工单的当前状态和结束状态这个方法就复用性很好。注意要设置rollbackFor Exception.classSpring 默认只回滚 RuntimeException如果业务代码里自定义异常继承了 Exception那就会事务失效。这个细节至少要能讲明白。整套流程实现下来你会发现每个操作基本上都是“先校验、再更新、再通知”的套路。不要嫌重复这个模式本身就是清晰的。维护起来看一个方法就够了不会出现到处改状态的混乱局面。5. 我在这个项目里踩过的坑和调试经验5.1 MyBatis 联表查询的 N1 问题刚开始我把工单列表的联表查询直接写在 Mapper 里一个select * from repair_order查出所有工单然后遍历每张工单再去查业主姓名、维修工姓名、类别名称。数据量小的时候页面一加载也要等两秒多日志里能看到几十条 SQL 在刷屏。这是典型的 N1 查询问题。把多条 SQL 合并成一条联表查询工单列表需要展示的业主名、维修工名、类别名、楼栋名一次 LEFT JOIN 全部带出来SELECT o.*, u1.real_name AS owner_name, u2.real_name AS worker_name, c.name AS category_name, b.building_name FROM repair_order o LEFT JOIN user u1 ON o.owner_id u1.id LEFT JOIN user u2 ON o.worker_id u2.id LEFT JOIN category c ON o.category_id c.id LEFT JOIN building b ON o.building_id b.id ORDER BY o.create_time DESC注意 LEFT JOIN 的顺序先用用户表再用类别表、楼栋表。如果有一张表的数据是可选的比如工单还没派单worker_id是 null就必须用 LEFT JOIN 而不是 INNER JOIN否则空值行会被直接过滤掉列表直接少数据。后来我又给create_time、status加了联合索引列表接口的响应时间从两秒多降到几百毫秒这个优化在答辩的时候非常加分。5.2 事务不生效都是代理机制惹的祸我遇到过一个比较隐蔽的问题RepairOrderServiceImpl里的submit()方法中我直接调用了同类里的另一个带有Transactional注解的私有方法。结果发现内部方法的事务居然没有生效数据写到一半抛异常已经插入的数据也没有回滚。原因是 Spring 的事务是通过 AOP 动态代理实现的只有通过代理对象调用方法时事务注解才会被解析。而在同类内部直接this.xxx()调用走的是真实对象不是代理对象注解自然失效。解决办法有三个把需要事务的方法拆分到不同的 Service 类里通过 Spring 注入的代理对象交叉调用。在同类的公开方法上加Transactional把内部调用包含进来不要让内部方法单独开事务。注入自身代理对象即Autowired自己类再调自己的方法。我的建议是第二个方案最直观也最不容易出问题。实际上写业务方法时一个事务封装的粒度通常就是一个完整的业务操作比如“提交报修”“完成评价”内部逻辑都在公开方法里完成基本上用不到事务自调用。5.3 图片上传后的路径回显问题前面提到过addResourceHandlers配置这个坑其实在上传成功后第一次测试时就暴露了。报修提交时图片明明上传了数据库里也存了路径但前端页面死活显示不出图片。F12 一看请求的 URL 是/images/2025/05/xxx.jpg而项目里根本没有这个目录也没有对应的静态资源映射。所有操作文件的和操作数据库的逻辑都得确认“存储路径”和“访问路径”是不是一致的。保存文件时我传进去的是绝对路径/usr/project/upload/images/xxx.jpg但数据库里存的是相对路径/images/xxx.jpg而访问映射的又是另一个目录路径。三处不一致就会 404。最后我的约定是数据库和前端永远只存/用相对路径即以/images/开头的 URL 路径。文件真实保存位置只存在于配置类里代码中拿相对路径拼接绝对根路径来存储。这样下来无论把项目部署到哪台服务器只要配置里指定 upload 根目录就行其他代码完全不用改。5.4 MySQL 8.0 驱动与时区问题的连环坑我第一次跑通项目时数据库连接一直报错控制台提示Public Key Retrieval is not allowed。原因是 MySQL 8.0 默认的认证插件和旧版驱动不兼容。解决办法是在 JDBC URL 后面加上两个参数url: jdbc:mysql://localhost:3306/property_repair?useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltruecharacterEncodingutf8serverTimezone尤其重要。不配置这个参数插入时间字段时可能会直接报错或者偏差若干小时。另外项目里的日期类型统一用LocalDateTime不要用java.util.Date配合mybatis的类型处理器直接映射省掉一堆格式转换代码。现在数据库用datetimeJava 用LocalDateTime查询出来就是直接的LocalDateTime对象前端用FastJson或Jackson序列化时统一格式不折腾。5.5 启动时遇到的数据源初始化报错还有一次改动表结构后项目直接启动失败原因是 MyBatis 在启动时就校验 SQL 映射某个 XML 里的 resultType 对应字段在数据库里不存在。这个问题好的方面是报错信息非常明确指出了哪个 Mapper XML、哪个字段有问题。不好的方面是改表结构时容易漏。因此任何一次数据库表改动都要顺手检查一遍相关联的实体类、Mapper XML 和查询 SQL。不要只改数据库否则启动时随时可能炸。这也算是一个良好的开发习惯不算额外负担。6. 从本地能跑起来到包装上线项目收尾的关键动作6.1 一套清晰的环境准备与启动流程很多同学做完项目换一台电脑就启动不起来最后等到答辩前两天还在配环境。我建议把环境的准备步骤写成一个 README 文件放到项目根目录。对你自己是备忘对老师是“该生工程素养不错”的映象分。下面的步骤是我这套项目实践下来的标准流程你可以直接参考写成自己的文档。安装 JDK 1.8 或 8 以上版本配置好 JAVA_HOME。安装 MySQL 5.7 或 8.0执行项目里的init.sql初始化脚本创建数据库和表结构。打开 IDEA导入项目等待 Maven 下载依赖。这一步如果遇到下载缓慢检查 Maven 是否配置了阿里云镜像。修改application.yml里的数据库账号密码。启动PropertyRepairApplication.java。启动成功后浏览器访问http://localhost:8080/。启动类放在一个 Application 类里不要随意改名。有同学为了“规范”把它改成SpringbootApplication或者MainApplication最终导致扫描不到 Controller启动成功但访问任何接口都 404白白浪费一小时排查。6.2 用“演示脚本”倒逼测试用例所谓演示脚本就是按角色走一遍完整流程这也是测试用例的雏形。我的脚本如下用业主账号登录提交一张带图片的报修单。换管理员账号登录看到“待审核”列表先拒绝一张再看下一条审核通过并派给水电类维修工。换维修工账号登录看到“待接单”工单接单。维修工填写处理结果并申请完工。业主看到“待验收”确认完成并评价。管理员查看统计页面看到今日报修总数、完成数量、维修中数量等数据。注册一个新用户检查楼栋选择是否生效密码是否正确加密存储。只要这个流程能连续走通项目主体就没有大问题基本可以应付答辩百分之八十的场景。在此基础上再补几个异常分支重复接单时是否有提示、状态不对时是否报错、图片超过大小限制时是否拦截。这些就是加分项。6.3 论文结构与答辩提问的准备如果你的项目包含论文/设计报告那么核心章节的层次值得好好排。这里提供一个经过验证的写作顺序需求分析问题定义、角色用例→ 总体设计架构图、模块划分→ 数据库设计E-R 图、表结构说明→ 功能实现每个核心功能的截图和代码片段→ 系统测试测试用例、结果分析→ 总结与展望。演示截图最好按“登录-提交-审核-派单-接单-完工-评价”的顺序连续拍放在论文里能形成一条完整叙事线。答辩最可能被问到的几个问题提前准备为什么选 SpringBoot SSM而不是 SpringBoot JPA回答重点SSM 组合更可控SQL 自己写适合复杂联表查询 MyBatis 有助于清晰认识数据访问层。工单状态是怎么管理的回答重点状态枚举 Service 层校验 乐观锁更新讲清楚每一步。如何处理并发接单回答重点说明 UPDATE 受影响行数为 0 的乐观锁方案。如何保证密码安全回答重点BCrypt 加密数据库不存明文。图片存哪访问路径是怎么映射的回答重点存入本地磁盘虚拟路径映射访问数据库只存相对路径。这几个问题练熟了答辩基本不会被问倒因为绝大多数同学的项目根本没有考虑过并发问题你能把乐观锁讲出来已经超出平均水平。这套物业报修系统做下来我最大的体会是真正体现工作量的地方从来不是“用没用最新框架”“代码写得多么花哨”而是业务闭环是否完整、数据逻辑是否自洽、异常情况是否有兜底。报修工单从提交到评价的每个状态我都在纸上画过一遍把每一步的状态、角色、时间字段列成清单再落实到数据库和代码里时思路清晰很多。后面做类似的管理系统比如设备报修、图书馆报修、后勤报修也都可以复用这套架构改改字段就行。如果你正在做这个课题建议先把文中的表结构建好再按“提报修→审核派单→接单→完工→评价”这条线把流程跑通剩下的扩展功能自然水到渠成。