Spring Boot护工服务系统这个毕设题目最近找我聊的同学真不少。乍一看名字挺垂直其实它把业务管理、多角色权限、订单流转、审核机制、数据统计这些后端高频知识点全串起来了性价比非常高。我帮几个同学从零到一梳理过这个项目从表结构怎么设计到护工接单状态机怎么定踩过的坑和验证过靠谱的方案整理成一篇完整的心得给正在做同类题目的你做个参考。1. 护工服务系统的业务画像与模块边界1.1 这一类系统到底在管什么三个角色的三套诉求护工服务系统的核心是连接需要照护的家庭和提供服务的护工。它和普通的商城系统不一样商城卖的是标准化商品而护工服务卖的是非标准化的、强依赖线下履约的“人”。这就决定了系统不能简单套用商品下单的逻辑。围绕这个业务场景系统里至少要存在三类角色每类角色的诉求完全不同用户/家属端核心诉求是“快速找到靠谱的护工”。他们要浏览护工列表看资质、看服务评分、看档期然后发起预约或下单服务完成后可以评价。用户端不需要太多花哨功能但信息展示要清晰下单链路要短。护工端核心诉求是“接到合适的单子”。护工有自己的服务类别、服务区域、按时或按天计费的规则。他们希望系统推送订单、能自主接单或拒单服务开始和结束时能记录操作最后能看到自己的收入和评价。平台管理端核心诉求是“保证服务质量和资金安全”。管理员负责审核护工入驻资质、管理服务分类、处理用户投诉和订单仲裁还要看平台的整体运营数据比如订单量、服务完成率、护工等级分布。这三套诉求叠在一起才是完整的系统闭环。只做用户端和护工端不管审核和统计答辩的时候很容易被追问“平台怎么控制服务质量”答不上来就会露怯。反过来三端都做但每端都只是增删改查又显得没有设计感。所以模块边界的划分直接决定这个毕设的档次。1.2 从零梳理功能清单哪些功能必须做哪些可以只做演示刚拿到题目很多同学的第一反应是功能越多越好。其实护工服务系统最忌讳“大而全”。你想想光是“排班管理”就能拆出日历视图、轮班规则、冲突检测、调班申请真要全做完两个月都搭不完。更务实的做法是把功能分成“核心链路”和“辅助链路”两档。核心链路是一条必须完整跑通的主流程它决定了系统的可用性链路阶段用户端动作护工端动作管理端动作服务准备注册登录、浏览服务分类、查看护工档案申请入驻、管理服务时间段审核护工资质下单预约选择护工、填写服务地址和时间、提交预约单查看待接订单、决定接单或拒单查看全部订单处理争议服务履约等待护工上门查看服务状态开始服务、结束服务、提交服务小结跟踪订单状态处理状态异常服务完成确认完成后付款/确认、提交评价和评分查看评价累计服务时长和收入查看评价统计做数据汇总辅助链路则是让系统有完整感的模块不需要做深但要有个人中心用户端维护地址簿、查看订单记录护工端维护服务区域、计费标准。消息通知用户下单后护工收到新订单提醒订单被接单后用户收到确认通知。这个可以用简单的站内信或短信SDK模拟不建议真接短信平台。数据看板管理端首页展示今日订单量、待审核护工数、各服务分类订单占比。查询SQL不复杂但能让演示时一开场就有视觉焦点。优惠券/会员体系这类功能对护工系统来说不是核心如果没有现成的业务需求建议直接砍掉。做出来容易讲清楚业务价值反而难。明确了哪些做、哪些砍下一步就是技术选型和数据库设计了。技术选型决定你开发的舒服程度数据库设计决定后面所有查询能不能写顺这两件事必须在写第一行业务代码之前定下来。2. 技术选型与数据库设计2.1 技术栈为什么这么组合护工服务系统属于典型的中小型业务管理系统技术上不需要上微服务那一套。我在帮同学梳理时一直推荐一个组合Spring Boot MyBatis Plus MySQL Redis JWT认证 Vue 3 Element Plus。原因很简单这套组合覆盖面广、社区成熟、遇到问题搜得到答案而且每个组件都能在答辩时讲出“为什么选它”。技术组件在本项目中的用途选择理由Spring Boot 2.7.x后端基础框架自动配置简化开发主流版本资料多MyBatis Plus持久层框架单表CRUD不用写SQL分页插件好用适合快速开发MySQL 8.0业务数据存储事务支持可靠绝大多数本地环境都能跑Redis缓存热点数据缓存护工列表、订单状态锁顺带做Token黑名单Sa-Token 或 JWT登录认证与鉴权三端角色权限控制前端存储Token无状态便于联调Vue 3 Element Plus前端管理界面组件化开发表格、表单、弹窗开箱即用Hutool工具类库日期处理、Bean拷贝、随机ID生成减少重复代码这里重点解释两个容易被问到的选型逻辑。第一为什么持久层用MyBatis Plus而不是Spring Data JPA护工服务系统里订单查询条件非常多按状态查、按用户查、按护工查、按时间段查、按服务分类查还要分页。MyBatis Plus的Wrapper可以很方便地拼动态查询条件而且自定义SQL的能力比JPA直观对基础偏薄弱的同学来说更可控。写原生SQL时也能清楚地看到查询逻辑调试起来不玄学。第二为什么用Redis缓存护工列表护工档案在用户端首页是高频访问的数据几百条护工数据反复查MySQL性能没问题但如果你把“热门护工排行”做成实时计算数据库压力就上来了。用Redis存一个缓存列表设置10分钟过期访问量再大也扛得住。答辩时可以讲清楚缓存解决的是读多写少场景下的数据库压力问题这个思路是通用的。还有一个细节项目包名统一用com.nursing.home或者com.example.care这种不要用“demo”“test”这种命名。包名会直接体现在代码结构上规范命名能让评分老师第一眼判断你有没有工程意识。2.2 数据库表设计思路与关键字段护工服务系统的表数量控制在12到14张之间比较合适。我梳理了一份完整表清单按业务域分组用户域用户表、护工表、管理员表服务域服务分类表、护工服务配置表交易域预约订单表、订单状态流转记录表履约域服务记录表、评价表系统域轮播图表、通知公告表、字典表、用户地址表重点说一下最容易出问题的两张表订单表和护工服务配置表。订单表的字段设计直接决定状态机能不能顺畅跑起来。我的建议是保留这些核心字段CREATE TABLE service_order ( id BIGINT PRIMARY KEY COMMENT 主键ID, order_no VARCHAR(32) NOT NULL COMMENT 订单编号, user_id BIGINT NOT NULL COMMENT 下单用户ID, caregiver_id BIGINT NOT NULL COMMENT 接单护工ID, category_id BIGINT COMMENT 服务分类ID, service_date DATE NOT NULL COMMENT 预约服务日期, service_start_time TIME COMMENT 预约开始时间, service_end_time TIME COMMENT 预约结束时间, address VARCHAR(255) COMMENT 服务地址, contact_name VARCHAR(50) COMMENT 联系人姓名, contact_phone VARCHAR(20) COMMENT 联系人电话, order_status TINYINT NOT NULL DEFAULT 0 COMMENT 订单状态0待接单 1已接单 2服务中 3待确认 4已完成 5已取消, amount DECIMAL(10,2) COMMENT 订单金额, pay_status TINYINT DEFAULT 0 COMMENT 支付状态0未支付 1已支付, remark VARCHAR(500) COMMENT 备注, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );这里两个细节值得展开。订单状态为什么用TINYINT整数而不是字符串因为整数枚举在Java里可以用枚举类一一对应业务代码里OrderStatus.CONFIRMED.getCode()这样写清晰可靠数据库里占用空间也小。很多同学喜欢直接存“待接单”这样的中文看起来直观但查询排序、统计分组都不方便遇到状态名称要改还得写一堆UPDATE。用整数枚举改前端显示的文案就够了后端逻辑纹丝不动。订单编号为什么要单独设一个order_no而不是直接用自增ID因为订单编号会暴露给用户看也会出现在服务记录里用雪花ID或者yyyyMMdd加随机数的规则生成比自增ID更规范也避免了别人从订单号直接推测出你的平台单量。我在项目里用Hutool的IdUtil.getSnowflakeNextIdStr()生成简单可靠。护工服务配置表的核心是“一护工多服务配置”。一个护工可能同时提供老人陪护、医院陪诊、康复护理三类服务每类服务的计价方式还不一样可能是按小时计费也可能是按天。如果直接在护工表里加一个service_type字段遇到多服务场景就只能存逗号分隔的字符串查询时还要模糊匹配这是典型的反范式设计。拆一张子表才是正解CREATE TABLE caregiver_service_config ( id BIGINT PRIMARY KEY, caregiver_id BIGINT NOT NULL COMMENT 护工ID, category_id BIGINT NOT NULL COMMENT 服务分类ID, price_hourly DECIMAL(10,2) COMMENT 按小时计费, price_daily DECIMAL(10,2) COMMENT 按天计费, service_area VARCHAR(100) COMMENT 服务区域, status TINYINT DEFAULT 1 COMMENT 是否启用 );表关系理清之后还有一类表很容易被忽略字典表和状态流转记录表。我刚做这个项目时就没建状态流转记录表结果演示时被问了一个问题——用户取消订单了但护工已经出发怎么处理我说管理员可以手动改状态对方追问那这个状态的变更过程有据可查吗当场就愣住了。后来补了一张order_status_log表每次状态变更都插入一条记录包含订单ID、旧状态、新状态、操作人ID、变更时间、备注。这张表既能在前端做“订单轨迹”展示又能在答辩展示“数据留痕”的设计思路非常加分。3. 核心业务流程与接口实现3.1 用户下单到护工接单状态机是这类系统的命根子护工服务系统的订单流程比商品订单复杂因为中间多了“人工履约”环节。商品下单之后是物流流转系统能自动更新轨迹护工服务不一样订单状态必须靠人来触发用户下单、护工接单、开始服务、结束服务、用户确认每一步都要有人操作还要防止两个人同时操作造成状态错乱。我采用的方案是在状态变更的Service方法里统一做校验和更新而不是让每个Controller直接改状态。核心思想很朴素状态不能随意跳每一步都要校验前置状态。Transactional public boolean acceptOrder(Long orderId, Long caregiverId) { ServiceOrder order orderMapper.selectById(orderId); // 核心校验只有待接单状态才能接单 if (order.getOrderStatus() ! OrderStatus.WAITING_ACCEPT.getCode()) { throw new ServiceException(订单当前状态不可接单); } // 防并发同一时间只有一个护工能接单成功 boolean locked redisTemplate.opsForValue() .setIfAbsent(order:lock: orderId, caregiverId, Duration.ofSeconds(10)); if (!locked) { throw new ServiceException(订单正在被其他护工处理请勿重复操作); } order.setOrderStatus(OrderStatus.ACCEPTED.getCode()); order.setCaregiverId(caregiverId); orderMapper.updateById(order); // 记录状态流转日志 insertOrderStatusLog(order.getId(), OrderStatus.WAITING_ACCEPT.getCode(), OrderStatus.ACCEPTED.getCode(), caregiverId); // 清理订单锁 redisTemplate.delete(order:lock: orderId); return true; }这段代码里有两个细节是我实际测试时踩过坑才加上的。第一个是Redis分布式锁。刚开始我图省事直接用updateById把订单状态改成“已接单”但测试并发场景时发现两个护工同时刷同一个订单前端都提示接单成功最后订单只认了后更新的那一个人。原因是两个请求都先查到了“待接单”状态校验都通过了然后各自UPDATE覆盖了彼此。加了Redis的setIfAbsent之后第二个请求在10秒内会拿到false直接提示“订单正在被处理”成功挡住了并发问题。Order的Redis锁的超时时间设置成10秒足够完成状态更新和日志写入又不会长时间占锁。演示的时候可以现场开两个浏览器窗口模拟并发这个细节讲出来很有说服力。第二个是事务加状态校验的顺序。事务保证订单更新和日志插入要么都成功、要么都失败状态校验前置保证无效操作不会进事务。这里还有一个隐藏的坑Redis锁的释放顺序。我第一次写把删除锁放在了事务外面结果事务还没提交锁已经释放了极端情况下会重复接单。现在把删除锁放到了事务方法内部最后一行确保事务提交完成后再释放。3.2 护工入驻与审核资质审核流程怎么做得有说服力护工入驻是这个系统里业务逻辑最完整的模块之一。护工不能注册后立刻接单必须由管理员审核通过才能上线。整个流程可以简化为提交资料 - 待审核 - 审核通过/驳回 - 维护服务配置 - 出现在用户端护工列表。这里有一个容易被忽视的细节前端传过来的资质信息是JSON字符串比如身份证照片URL、健康证URL、工作经历描述。直接存进数据库没问题但审核员看的时候体验很差。更专业的做法是把多个资质字段拆开存形成一张护工资质表让管理员分项审核每一项都标记“已通过/不通过”。演示的时候管理员端看到的是明细列表操作上一项一项点审核比对着一个JSON字符串审核要真实得多。护工的“服务时间冲突检测”也是审核通过后的必备逻辑。护工可以设置每周哪些时段可服务生成预约订单时要检测冲突。比如某护工在周一到周五的9:00到18:00可服务新订单时间是周三下午2点就必然冲突。这个逻辑的实现方式不复杂public boolean checkCaregiverTimeAvailable(Long caregiverId, LocalDate serviceDate, LocalTime startTime, LocalTime endTime) { Integer weekday serviceDate.getDayOfWeek().getValue(); // 1. 检查护工本周期的可服务时段 ListCaregiverSchedule schedules scheduleMapper .selectByCaregiverAndWeekday(caregiverId, weekday); boolean inSchedule schedules.stream().anyMatch(s - !startTime.isBefore(s.getStartTime()) !endTime.isAfter(s.getEndTime())); if (!inSchedule) return false; // 2. 检查已有订单是否时间重叠 Integer conflictCount orderMapper.countConflictOrders( caregiverId, serviceDate, startTime, endTime); return conflictCount 0; }这个方法的两个检查是必须分开写的不然后面加“取消订单自动释放档期”时会乱。注意第一个检查判断的是“新订单时间段是否被包含在护工的可服务时间段内”不是简单的开始时间等于开始时间。有些同学写成equals导致护工设置了9点到18点但用户预约8点半到10点系统误判成可接后面的冲突检查又没拦住数据就脏了。3.3 评价与结算这两个模块怎么做不踩坑评价模块实现起来不难难在业务逻辑怎么闭环。护工服务完成后用户端应该收到“待评价”提醒点进去可以打分1到5星和写文字评价。评价完成后护工端能看到平均分和最新评价管理端可以看到评价列表并支持回复或删除不合适的内容。评价表字段里我建议加一个anonymous字段允许用户选择匿名评价。这个细节很多同学想不到但实际业务中很常见——家属可能担心影响后续合作关系不想暴露身份。考虑到这个字段后护工端展示评价时可以显示“匿名用户”而不是用户ID这个设计思路在答辩时可以自然讲出来体现你思考过真实场景。结算模块是护工系统里最容易被问崩的地方。一个护工服务完成后怎么计算收入如果是按次计费就是单次金额如果是按时长计费要按实际服务开始结束时间算差。我建议做一个简单但原理清晰的演示版结算逻辑用户下单时按照护工服务配置表的price_hourly或price_daily生成订单金额。护工结束服务后如果订单是按小时计费用实际服务分钟数除以60乘以单价计算最终金额如果按天计费用固定价格。订单完成后生成一条护工收入流水状态为“待结算”。管理员每个月可以做一次批量结算把累计收入标记为“已结算”。这里有一个必须处理的边界情况如果实际服务时长超过了预约时长要不要加钱我在项目里的方案是超过30分钟以内不额外计费超过30分钟要额外计费这个规则在系统参数表里配置。这样设定的原因很简单护工服务存在现场情况不可控的情况给一个宽容值更符合人性也避免用户和护工因为几分钟扯皮。这个细节加到代码注释里答辩时讲出来就是加分项。评价和结算都涉及金额和时间这里再提醒一句数据库里金额字段一律用DECIMAL(10,2)不要用FLOAT或DOUBLE。浮点数精度丢失导致的对账不平是财务类功能最常见的新手错误之一。用过一次FLOAT后你就知道对账差了0.01元排查半天都查不出来万事都用DECIMAL从源头避开。4. 实操过程从空项目到能跑起来的完整落地4.1 环境准备与项目初始化一个能跑起来的护工服务系统开发环境需要JDK 8或JDK 11、MySQL 8.0、Redis 6或更高版本、Idea、Navicat或DataGrip、Postman。这些工具的版本宁可保守一点也不要追新我见过一个同学用JDK 17搭配老版本Spring Boot结果一堆Javax依赖不兼容光调环境就花了两天。项目初始化建议直接用Idea的Spring Initializr创建依赖选择Lombok、Spring Web、MyBatis Framework、MySQL Driver然后手动在pom.xml里加上MyBatis Plus。我惯用的MyBatis Plus版本组合是这样的dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependencyMySQL驱动建议用mysql-connector-j而不是老版的mysql-connector-java因为新驱动包直接兼容了MySQL 8的认证插件少一步时区问题的排查。接着配置application.ymlserver: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/care_system?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 database: 0 mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0这里有一个我调整过多次的经验MyBatis Plus的逻辑删除字段deleted是全局配置配置上之后所有表的查询都会自动追加WHERE deleted 0删除操作自动变成UPDATE。这个特性在前端展示“已删除数据不出现但不物理删除”时非常省心。但要特别注意如果哪张表不需要逻辑删除要单独配置或者把字段补齐否则查询报告了一个表没有deleted字段启动不报错但查询直接报Unknown column排查起来很窝火。4.2 接口调通与前端联调接口调通阶段最容易卡住的地方是跨域和登录拦截。我的做法是先写一个全局跨域配置类用一个CorsFilter搞定所有跨域问题而不是在每个Controller上加注解。Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedHeader(*); config.addAllowedMethod(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }有一点必须提醒setAllowCredentials(true)和addAllowedOriginPattern(*)搭配是允许带Cookie的跨域请求但如果前端用了localhost:5173作为Vite开发服务器地址后端这个配置就能覆盖到。实际联调时如果发现前端请求还在报跨域检查一下前端请求有没有自己加了Access-Control-Allow-Origin的请求头加了反而会触发浏览器双重校验报错。这个坑我调试了很久才发现去掉前端手动设置的请求头就好了。登录拦截用Spring MVC的HandlerInterceptor实现。放行规则要格外小心/api/auth/**、/api/public/**、/uploads/**这几个路径应该放行其他业务接口统一检查Token。还有一种更省心的方案是使用Sa-Token框架拦截逻辑已经封装好了直接在配置里写notMatch列表。相比手写JWT解析和拦截器Sa-Token的开发体验更接近“配置即用”适合时间紧张的毕业设计。用Sa-Token的典型拦截配置如下Configuration public class SaTokenConfigure implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new SaInterceptor(handle - StpUtil.checkLogin())) .addPathPatterns(/api/**) .excludePathPatterns( /api/auth/doLogin, /api/auth/register, /api/caregiver/list, /api/category/list ); } }这样配置之后所有/api/下的请求都会先走登录检查未登录直接抛出NotLoginException前端收到特定的状态码后跳转到登录页。前端联调时不再需要每个接口都手动写登录校验逻辑统一在拦截器里处理。4.3 部署与演示数据准备本地演示阶段不需要部署到云服务器直接在Idea里运行Spring Boot主类前端用npm run dev起Vite开发服务器就够了。但最后还是建议打一次包因为答辩现场万一开发环境出问题打包成可执行JAR能救场mvn clean package -DskipTests java -jar target/care-system-0.0.1-SNAPSHOT.jar打包时要注意Spring Boot的spring-boot-maven-plugin不要漏配mainClass否则打出来的JAR找不到启动类会报错。另外-DskipTests是跳过测试但要注意这个参数会让测试类编译产物不打进包里如果有用测试类初始化的演示数据得专门留意一下。演示数据这块我的建议是不要等正式演示前再手工录入而是写一个DataInitializer组件应用启动时自动插入一批演示数据。护工数据要20条以上覆盖不同服务分类、不同评分段、不同服务区域用户和订单数据要模拟不同的状态分布至少有一个待接单、两个已接单、三个服务中、五个已完成这样演示时点到每个选项卡都有数据展示不会出现空页面。更进阶的做法是加一个/api/dev/mock-data接口管理员登录后在演示前点击按钮触发造数脚本生成一次性数据。这样答辩现场可以现场演示数据生成过程很有仪式感。但脚本要可控别生成几百上千条垃圾数据把页面搞卡了。5. 常见问题与调试实录5.1 必踩的五个坑及排查方法我帮同学调试这个项目时有几个问题出现的频次极高几乎每个用Spring Boot做管理系统的人都躲不过去。整理成速查表遇到了直接对照着看。问题现象根本原因排查方法解决方案查询返回时间总是少8小时数据库时区和应用时区不一致查看MySQL的time_zone变量和JDBC URL参数JDBC URL加serverTimezoneAsia/Shanghai同时MySQL运行SET GLOBAL time_zone8:00前端调用业务接口一直返回401登录拦截器没放行登录接口登录请求也被拦了检查访问日志看拦截器执行的顺序在excludePathPatterns里添加上登录和注册路径MyBatis Plus分页不生效返回全量数据没配置分页插件查看SQL日志观察是否带有LIMIT在配置类里注册MybatisPlusInterceptor并添加PaginationInnerInterceptor护工列表图片加载不出来项目路径和上传文件实际路径不一致F12看请求的图片URL看后端访问日志配置虚拟路径映射把本地磁盘路径映射到/uploads/**订单状态被覆盖两个护工同时接同一单缺少并发控制打开两个浏览器同时点击接单用Postman并发测试加Redis分布式锁配合订单状态校验时间时区问题几乎每个项目都会遇到而且出问题的位置千奇百怪。最常见的场景是前端传过来的日期是“2025-06-01 14:00:00”后端存入数据库后变成了“2025-06-01 06:00:00”显示时又差了一截。排查思路要抓住一条主线从前端请求到后端参数、从后端实体到MySQL插入、从MySQL查询到JSON返回每一步都打印日志看时区偏差是在哪一步产生的。90%的情况是JDBC连接字符串里没加serverTimezone剩下一部分是JSON格式化没有按yyyy-MM-dd HH:mm:ss输出导致前端解析错误。5.2 答辩现场的实用建议技术问题排查完再聊聊答辩这件事。护工服务系统这种业务管理型毕设答辩老师最关心的往往不是代码写得多么花哨而是三个问题系统解决了什么实际问题核心业务的完整流程是什么哪些环节遇到过困难、又是怎么解决的回答第一个问题时不要上来就背功能清单而是讲一个场景“用户家里有老人需要短期陪护用户打开平台看到护工列表可以看到护工的服务年限、服务评分、服务价格选择合适的护工发起预约护工收到订单提醒确认接单服务完成后用户确认并评价管理员在后台看到所有订单数据。”这样讲老师马上就能抓住系统的运行逻辑。回答第二个问题时可以拿出数据库设计的ER图或表结构清单讲解订单状态从待接单到已完成是怎么流转的每个状态的触发条件和权限。这套思路只要你在开发时理清过状态机讲起来非常有底气。回答第三个问题时一定要真实。比如你确实在并发接单环节遇到过状态覆盖问题就讲这个问题怎么发现的Redis锁怎么加的。哪怕最终方案不完美但老师想听的是“你有独立排错的能力”而不是你背了多完美的答案。我见过太多同学把这个问题答成背诵“深拷贝浅拷贝”的八股等于放弃了展示自己项目经验的最好机会。最后再提一点操作层面的建议答辩现场一定不要用本地Idea里开着一堆断点的调试环境来演示。正式演示前把系统打包好重新启动一遍测试一次完整流程。这样你能提前发现端口占用、Redis没开、数据库连接失败这类环境问题而不是在演示时被老师盯着调试代码。这个项目做完之后有一个体会特别深护工服务系统虽然是毕设题目但它把真实业务系统中的三端角色、状态流转、并发控制、权限管理这些核心概念都完整覆盖了。把这样一个项目从数据库设计到最终跑通后端开发的核心技能也就掌握了大半。做的时候多想一想“为什么这么设计”哪怕是一个小小的状态枚举也能给答辩带来不小的帮助。
