Spring Boot+SSM宠物服务系统：预约、寄养、护理全流程实战

做宠物服务系统这类Spring BootSSM项目的同学挺多的不少人是第一次接触“医疗、寄养、护理”三合一的服务类业务系统。说实话这类系统真正难的不是框架搭建而是业务模块之间怎么建表、状态怎么流转、预约冲突怎么处理。这篇文章围绕一个典型的宠物服务系统把全流程设计从需求拆解、数据库设计、接口实现到部署排查整个链路过一遍重点讲讲医疗、寄养、护理三个核心模块的实现思路适合已经有CRUD基础、准备做完整项目的开发者参考。现在很多演示项目停留在“用户管理宠物档案增删改查”的层面没有把服务过程串起来。实际业务里宠物主人会预约挂号、带宠物看病、办寄养、约美容护理服务完成之后还要结算费用、生成报表这中间涉及预约状态、服务记录、费用明细、时段冲突等多个环节。单独看每个模块都不复杂但放在一起就会暴露设计问题要么是表结构之间没有统一的主体关联要么是状态字段散落各处、订单和服务记录各玩各的最后统计营收时写SQL写到怀疑人生。所以我建议先讲清业务链路再动手建表比一上来就写实体类要省事得多。1. 实战项目背景与整体设计思路1.1 业务场景与角色拆解这个系统的核心链条是什么宠物服务系统的使用场景可以归纳成一条主链路宠物主人注册账号、登记宠物档案然后在小程序或管理后台发起服务预约服务人员接单执行最后结算费用。围绕这条链路系统角色一般有四个宠物主人维护档案、预约服务、查看历史记录和费用前台/客服代客下单、确认预约、处理寄养入场离场医生/护理师接诊写病历、开处方、填写护理/照护记录管理员维护服务项目、管理房间、查看经营报表。一开始设计角色时别急着给每个角色单独建一套表。我的习惯是把“服务预约”提炼成一张核心表用类型字段区分医疗、寄养、护理再各自附加业务扩展信息。这样既能统一预约流程又不会让表数量膨胀。很多新手会犯的错是医疗建一张预约表、寄养建一张登记表、护理再建一张排队表每张表都写一遍宠物ID、主人ID、状态字段、备注字段。短期内开发挺快后面做统计报表或者跨模块查询时每次都要UNION多张表维护成本很高。1.2 技术选型Spring Boot SSM为什么这么搭标题里出现“Spring BootSSM”很多人一开始会疑惑Spring Boot本身已经集成了Spring再提SSM是不是重复了实际上这里的“SSM”指的是Spring MVC和MyBatis这套经典组合。用Spring Boot做基础骨架Web层依然是Spring MVC持久层用MyBatis整体既保留了SSM时代清晰的开发习惯又能享受自动配置和内置容器带来的效率提升。我在项目里通常还会加MyBatis-Plus增强工具主要负责单表CRUD和条件构造器复杂查询仍然手写XML。选择这条路的原因是中小型服务系统对框架要求并不高团队熟悉什么就用什么。如果你们学校或团队要求“必须体现SSM”那么Spring Boot加MyBatis的组合也算符合预期Spring MVC的Controller、Service、Mapper分层结构都能完整保留。技术栈本身不是重点重点是你能否把业务模块讲清楚。具体用到的核心依赖包括spring-boot-starter-web、mybatis-spring-boot-starter、mysql-connector-java、lombok以及可选的spring-boot-starter-validation用于参数校验。JDK使用8以上即可项目不复杂时没必要追高版本稳定压倒一切。1.3 模块划分与数据流设计预约、服务、结算三阶段如何串起来把三个核心模块的数据流拆开看会发现都遵循“预约、服务、结算”三段式结构医疗模块创建挂号预约 → 医生接诊写病历 → 开具处方 → 生成费用明细寄养模块创建寄养预约 → 入场登记 → 每日照护记录 → 离场结算护理模块创建美容护理预约 → 服务执行 → 完成回执 → 费用结算。三段式中最容易被忽略的是“状态流转”。预约状态我建议统一设计成四个待确认、已确认、已完成、已取消。寄养订单在预约基础上再多加“待入住、寄养中、已离场、已取消”四个状态。这里要注意状态枚举不要散落在业务代码里最好用常量类或枚举统一管理避免出现写“1”“2”这种魔法值后过两个月自己都看不懂的情况。另外费用结算必须统一。我见过不少项目每个模块各建一张费用表最后老板想看“本月寄养收入和医疗收入分别多少”只能到处拼SQL。合理做法是建一张统一的费用明细表通过业务类型和业务单号关联到对应模块这样日报、月报、项目营收占比都能用同一套逻辑取数后面写统计接口会轻松很多。2. 数据库设计三张核心业务表之外的细致功夫数据库设计是这类项目的重头戏。我的习惯是先梳理好基础档案、模块业务表、费用结算三部分再回到MySQL建库建表。2.1 基础档案设计用户、宠物档案与员工表用户表和宠物档案表是整个系统的地基。用户表字段比较简单除了常见的用户名、密码、手机号、角色还需要注意密码不能明文存储建议用加密算法处理后再入库。角色字段用tinyint即可0表示宠物主人、1为前台、2为医生、3为管理员。宠物档案表才是核心。字段包括宠物名称、类型犬/猫/其他、品种、性别、出生日期、体重、绝育标识、过敏信息、主人ID等。这里有一个关键设计思路所有服务记录都挂在宠物档案上而不是挂在用户上。为什么因为用户可能有两只猫、三只狗看历史病历时必须按宠物维度筛选如果只关联用户会把多只宠物的数据搅在一起。之后统计“某只宠物累计消费”“某只宠物病史”时只要按pet_id关联查询即可。员工表可以复用用户表靠角色区分也可以单独建员工表用于维护医生和护理师的信息。我建议直接用用户表加角色字段承担员工功能避免重复维护账号体系管理员登录后根据角色跳转到不同功能菜单。2.2 医疗模块预约、病历与处方的表结构思路医疗模块涉及三张关键表通用预约表、病历表、处方明细表。预约表我采用统一设计字段包含预约类型、宠物ID、用户ID、服务人员ID、服务项目ID医疗对应科室或医生服务、预约日期、时段、状态、备注。用预约类型区分医疗、护理可以避免为每个模块各建一张预约表。医疗场景下“时段”字段很关键需要提前定义好固定时段例如上午9点到12点每半小时一个号方式是在程序里维护时段字典而不是任由用户填写任意时间。病历表字段包括宠物ID、医生ID、接诊日期、主诉、诊断结果、治疗方案、状态。病历和预约的关系是一对一可以在预约完成后生成病历草稿医生再接诊更新。处方明细表用来记录某次就诊开了哪些药包含病历ID、药品名称、单次剂量、频次、天数、单价、数量。处方通常是一对多的所以独立成表方便后续做药品收入统计。2.3 寄养模块房间、订单与每日照护记录设计寄养模块建议建三张表寄养房间表、寄养订单表、每日照护记录表。寄养房间表包含房间编号、房间类型小型犬、大型犬、猫舍等、每日价格、房间容量、当前已用数量、状态。房间状态分为空闲、占用、维修。这里要注意“已用数量”这个冗余字段理论上可以通过查询订单统计出来但寄养入场离场频繁实时统计会很麻烦。我在实操中会把房间使用人数冗余在房间表里办理入场时加一、离场时减一配合乐观锁防止并发更新问题。寄养订单表包含宠物ID、主人ID、房间ID、开始日期、结束日期、每日价格、总金额、状态待入住、寄养中、已离场、已取消、入场时间、离场时间、特别备注。核心难点是日期区间冲突判断例如同一只宠物不能在两个寄养订单时间重叠稍后我会专门讲冲突查询SQL。每日照护记录表则记录寄养期间每天的情况含义为“寄养订单下的每日动态”喂养内容、是否外出溜放、身体状态描述、照护人、记录日期。这块内容最容易在演示项目里被省略但它恰恰是寄养业务与普通预约系统最明显的差异点也是体现系统完整度的地方。2.4 护理模块服务项目与预约的通用化设计护理模块相对简单核心基础表是服务项目表和服务预约表。服务项目表字段包括项目名称、服务分类洗澡、美容、SPA、修剪等、标准价格、预计耗时、状态。把服务项目做成可配置的好处是运营人员以后调整价格和上架新服务时不需要改代码。护理预约仍然复用通用预约表用预约类型字段区分预约时可以选择多个服务项目并在预约详情或子表中记录项目组合。我建议增加一张“预约服务项明细表”记录预约ID、服务项目ID、项目价格这样既能实现一次性预约多个服务又能准确记录每个项目的消费明细后续做“热门服务排行榜”等报表时直接按这张明细表聚合即可。护理模块的预约冲突与医疗不同重点校验服务人员的时段是否冲突而不是宠物。因为一个宠物主人可能同时给两只不同的宠物约护理但同一个护理师在同一时段只能服务一个客户。所以护理场景下业务校验键是“员工ID 预约日期 时段”。3. 核心业务实现预约、接诊、入住、离场的完整链路这一部分讲代码实现我挑三个最有代表性的场景展开医疗预约防重、寄养入住离场、护理组合结算。3.1 医疗预约接口防重复与号源校验如何落地医疗预约接口的设计核心诉求是“同一宠物同一时段不能重复预约”以及“时段号源不能超限”。前者用唯一索引兜底后者用前置查询加状态判断。支付层或者Service层的实现大致如下Transactional(rollbackFor Exception.class) public Long createMedicalAppointment(CreateAppointmentDTO dto, Long userId) { // 1. 基础校验宠物归属于当前用户 Pet pet petMapper.selectById(dto.getPetId()); if (pet null || !pet.getUserId().equals(userId)) { throw new BizException(宠物档案不存在或无权操作); } // 2. 时段号源校验先判断这个医生/科室当天该时段是否已约满 AppointmentQuery query new AppointmentQuery(); query.setDoctorId(dto.getDoctorId()); query.setAppointDate(dto.getAppointDate()); query.setTimeSlot(dto.getTimeSlot()); query.setType(APPOINTMENT_TYPE_MEDICAL); long bookedCount appointmentMapper.countByCondition(query); if (bookedCount MAX_BOOKING_PER_SLOT) { throw new BizException(该时段号源已满请选择其他时段); } // 3. 插入预约记录 Appointment appointment new Appointment(); appointment.setPetId(dto.getPetId()); appointment.setUserId(userId); appointment.setDoctorId(dto.getDoctorId()); appointment.setAppointDate(dto.getAppointDate()); appointment.setTimeSlot(dto.getTimeSlot()); appointment.setStatus(APPOINTMENT_STATUS_WAIT_CONFIRM); appointmentMapper.insert(appointment); return appointment.getId(); }这里有几个实操要点。第一业务校验和插入操作必须在同一个事务里否则两个请求同时通过校验就会出现超发所以方法上必须加事务注解。第二仅靠代码校验不够稳妥最高可靠性的方案是在预约表上再加唯一索引字段组合为“宠物ID 预约类型 预约日期 时段”数据库层面兜底。第三号源数量我习惯在系统参数表里配置而不是写死在代码里方便后续调整。3.2 寄养入场与离场区间冲突判断与房间占用寄养模块最重要的业务规则是时间区间不能重叠。判断逻辑听起来简单但新手很容易写错。正确思路是已存在的有效订单的“开始日期 新订单的结束日期”且“结束日期 新订单的开始日期”此时两个区间一定有交集。对应的MyBatis SQL如下select count(*) from boarding_order where pet_id #{petId} and status in (1, 2) and (start_date #{endDate} and end_date #{startDate})如果查询结果大于0说明存在时间重叠直接拒绝下单。边界条件这里要特别留意两个订单首尾相接是不冲突的例如一号订单2024-05-01到2024-05-03二号订单2024-05-03到2024-05-05如果采用小于等于判断会误判为重叠。所以边界判断要看业务定义按“寄养日”还是“过夜”来设定。我这个示例里把边界当成闭区间处理实际落地时一定要根据业务口径说清楚。入场办理的代码要看重事务和房间占用更新Transactional(rollbackFor Exception.class) public void checkIn(Long orderId, Long operatorId) { // 1. 查询寄养订单加行锁防止并发 BoardingOrder order boardingOrderMapper.selectByIdForUpdate(orderId); if (order null || order.getStatus() ! BoardingStatus.WAIT_CHECKIN) { throw new BizException(订单状态异常无法办理入场); } // 2. 更新房间已用数量使用乐观锁避免超卖 int updated boardingRoomMapper.increaseUsedCount(order.getRoomId(), 1); if (updated 0) { throw new BizException(房间资源已被占满请重新分配房间); } // 3. 更新订单状态为寄养中记录入场时间 BoardingOrder update new BoardingOrder(); update.setId(orderId); update.setStatus(BoardingStatus.BOARDING); update.setCheckInTime(new Date()); boardingOrderMapper.updateById(update); }increaseUsedCount的SQL对应为update boarding_room set used_count used_count 1, version version 1 where id #{roomId} and version #{version}这里用“乐观锁版本号”确保两个前台同时给同一个房间办理入住时只有一个人能更新成功。离场结算逻辑正好相反先检查订单状态为寄养中再缩小房间使用数、计算费用、生成费用明细、更新订单状态整组操作放在同一个事务里。3.3 护理服务组合结算多项目下单的事务处理护理服务的典型场景是“一次预约多个服务项目”比如洗澡加SPA加指甲修剪。后端接收入参时前端会传一个服务项目ID的数组后端需要在一个事务内完成三件事计算总时长和订单费用、创建预约记录、写预约明细。核心代码逻辑Transactional(rollbackFor Exception.class) public Long createBeautyAppointment(CreateBeautyAppointmentDTO dto, Long userId) { // 1. 批量查询服务项目避免逐个查询导致性能损耗 ListServiceItem items serviceItemMapper.selectBatchIds(dto.getItemIds()); if (items.isEmpty()) { throw new BizException(请选择有效的服务项目); } // 2. 累加总时长和总金额 int totalMinutes items.stream().mapToInt(ServiceItem::getDurationMinutes).sum(); BigDecimal totalAmount items.stream() .map(ServiceItem::getPrice) .reduce(BigDecimal.ZERO, BigDecimal::add); // 3. 校验服务人员时段冲突 boolean conflict appointmentMapper.checkStaffSlotConflict( dto.getStaffId(), dto.getAppointDate(), dto.getTimeSlot()); if (conflict) { throw new BizException(该服务人员在所选时段已有预约); } // 4. 创建预约主单和预约明细多条 Appointment appointment new Appointment(); appointment.setType(APPOINTMENT_TYPE_BEAUTY); // ... 设置宠物、用户、日期、时段、合计金额 appointmentMapper.insert(appointment); for (ServiceItem item : items) { AppointmentItem detail new AppointmentItem(); detail.setAppointmentId(appointment.getId()); detail.setItemId(item.getId()); detail.setItemName(item.getItemName()); detail.setItemPrice(item.getPrice()); appointmentItemMapper.insert(detail); } return appointment.getId(); }这里最容易被忽略的是事务边界。如果创建主单成功但插入明细失败主单应该回滚所以事务必须包住“插入主单批量插入明细”整个过程。另一个经验点是接口入参最好有DTO校验注解比如NotNull、Size(min 1)项目里引入了spring-boot-starter-validation之后Controller层参数校验会整洁很多。4. 三个关键技术点事务、并发、状态流转的实现细节4.1 事务管理为什么你的Transactional偶尔不生效这类项目里事务失效属于Top级问题通常有以下几种原因。第一同Service内部自调用。比如在一个方法里直接调用本类的另一个方法后者即使加了事务注解也不会生效因为Spring事务基于AOP代理自调用没有经过代理对象。解决办法是拆成两个Service互相调用或者在配置里暴露代理目标后使用AopContext.currentProxy()但我不建议为了省事而引入这种奇技淫巧拆Service最清晰。第二方法不是public。Spring事务代理默认只拦截public方法包私有或private方法上的注解会被忽略。而且这种问题编译期不会报错项目跑起来也能正常插入数据只有发生异常时才发现数据没回滚排查过程很耗时间。第三异常被catch吞掉或抛出的是CheckedException。事务回滚默认只处理RuntimeException和Error如果方法里抛出的异常被catch住直接返回事务不会回滚。如果业务上必须抛出受检异常要在注解里指定rollbackFor Exception.class。4.2 并发控制乐观锁与唯一约束双保险预约类和库存类是并发问题的高发地。以寄养房间为例两个用户同时看到某房间还有空位同时提交入住如果只靠前置查询做判断两个请求都会通过校验最后导致房间超卖。解决办法有两种乐观锁更新用version字段做条件更新更新影响行数为0时说明被别人抢先或者用select for update加行锁把并发请求串行化。我在项目里比较推荐乐观锁理由是对数据库压力小、代码可读性高。对于医疗预约防重场景使用数据库唯一索引作为“最终兜底校验”效果比任何应用层判断都可靠。具体做法是在预约表上建唯一索引组合键包含宠物ID、预约类型、预约日期、时段当两条相同预约同时提交时数据库会直接拒绝其中一条并抛出重复键异常代码里捕获异常后转成友好提示。4.3 状态流转与报表统计从订单状态到营收面板状态流转一定要集中管理。我习惯写一个状态常量类把医疗、寄养、护理的状态全部定义好在Service里判断状态时统一引用常量禁止直接写数字。这样代码审查和后期维护省心得多。报表统计是本项目最强的加分项。统一费用明细表设计好之后月度营收统计就变成很简单的事。比如统计某月每天的经营收入select date(biz_date) as stat_date, sum(amount) as total_income from fee_detail where pay_status 1 and biz_date 2024-05-01 and biz_date 2024-06-01 group by date(biz_date) order by stat_date热门服务Top5的统计基于预约明细表计算逻辑为“按服务项目分组、统计预约次数并倒序”。这类SQL执行前一定要在费用明细表的biz_date、pay_status字段以及预约明细表的item_id字段上建好复合索引否则数据量上去后报表接口会非常慢。5. 项目运行与部署本地联调、打包上线的实操记录5.1 环境准备与配置文件那些在启动前就要避开的坑项目环境建议使用JDK 8、Maven 3.6以上、MySQL 5.7或8.0。新建Spring Boot项目时pom.xml里需要引入核心依赖注意mybatis-spring-boot-starter的版本需要与Spring Boot版本匹配。Spring Boot 2.x对应MyBatis starter 2.xSpring Boot 3.x对应3.x混用会在启动阶段抛出各种奇怪的类加载错误。application.yml配置是最容易踩坑的重灾区我提供一个基础可用的配置server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/pet_service?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.pet.entity configuration: map-underscore-to-camel-case: true有几个细节要额外说明。第一JDBC连接必须带serverTimezoneAsia/Shanghai否则本地时间和数据库时间会出现8小时偏差查询出来的日期总感觉慢半天。第二map-underscore-to-camel-case配置打开后数据库的user_name字段就能自动映射到Java实体类的userName属性少写一堆resultMap。第三mapper-locations是MyBatis XML映射文件路径如果漏配会报“Invalid bound statement (not found)”错误最常见的原因就是Mapper接口有方法但XML没被扫描到。5.2 前后端联调与跨域处理如果前端是单独部署的Vue或小程序接口联调时经常会遇到跨域问题。Spring Boot里最简单的处理方法是用配置类统一注册跨域映射而不是在每个接口上加跨域注解Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }实际项目里登录鉴权建议使用JWT配合一个HandlerInterceptor实现。登录和注册接口在拦截器中放行其他接口统一校验请求头里的token解析出用户ID后存入ThreadLocal或直接塞进请求参数。这里有一个小经验拦截器里校验token时不要把用户的所有信息都放进token只放用户ID和角色即可其他信息每次从数据库实时查询避免用户修改手机号或角色后token还带着过期数据。5.3 打包部署与线上小贴士本地开发跑通后部署环节相对简单。先执行打包命令mvn clean package -DskipTests得到jar包后放到服务器上用以下命令前台启动确认日志正常java -jar pet-service-1.0.0.jar确认无异常后再改用后台运行方式例如将输出日志重定向到文件并配合进程管理工具守护。生产环境部署时有几个容易忽略的地方数据库连接不能再用root账号需要单独创建业务账号并只授权当前库密码不要写在application.yml明文里可以用环境变量替换部署路径不要包含中文或空格避免一些底层工具解析异常。6. 高频问题排查与避坑实录最后这部分整理一下我在实际开发中踩过的坑遇到类似问题可以直接对照处理。6.1 事务不回滚、时间差8小时、中文乱码等老生常谈事务不回滚原因前文已经分析过这里补充一个真实案例某次寄养离场功能结算逻辑里先删预约明细、再更新订单状态、最后插入费用明细中途因为房间占用数更新失败抛了异常但数据库里订单状态已经被改掉。排查后发现问题出在Service内部有两个方法互相调用事务注解实际上没生效。改成两个独立Service之后整体事务立刻恢复正常。时间差8小时和中文乱码的根源都属于连接参数问题。数据库连接URL里加上characterEncodingutf8和serverTimezoneAsia/Shanghai建库时统一使用utf8mb4字符集前端传中文乱码的问题通常都能解决。另外要注意MySQL的utf8mb4和utf8是两回事emoji和生僻字必须用utf8mb4如果建库时选了utf8后面存储特殊符号时会报错。6.2 区间冲突SQL与查询报错调试经验区间冲突SQL报错最常见的原因不是语法错误而是业务边界没想清楚。两个订单同一天入住、同一天离场算不算冲突当天入住当天离场又算不算这些必须先定口径再写SQL否则上线后会出现大量边界纠纷。调试SQL时我习惯先手工构造几条边界数据验证比如开始等于结束、一个在另一个区间内部、首尾相接这几种情况都跑一遍确认结果符合业务定义。另一个调试经验是MyBatis XML里写动态查询时如果参数超过一个XML中必须显式写parameterType或使用Param注解给参数命名。新手常见报错是“Parameter xxx not found”原因就是Mapper接口方法有多个参数但没加Param注解SQL里的参数名对应不上。6.3 常见问题速查表问题现象可能原因解决方案启动报Failed to configure a DataSource没配置数据源或配置有误检查application.yml中数据库地址、账号、密码、驱动类访问接口报非法绑定语句mapper-locations没配置或XML路径不对确认Mapper XML在classpath mapper目录下配置扫描路径事务不回滚自调用、非public方法、异常被吞拆Service、方法改public、rollbackFor设置Exception.class时间查询差8小时JDBC连接和Jackson时区不一致URL与配置统一加serverTimezoneAsia/Shanghai上传中文乱码数据库字符集或连接参数问题建库用utf8mb4连接加characterEncodingutf8并发预约超发缺少唯一约束或乐观锁加数据库唯一索引或version字段条件更新报表查询极慢缺少索引或分组字段没优化给日期、状态、业务类型字段建复合索引房间可占用数为负离场重复办理状态机里严格判断已离场订单不能再次办理离场最后再分享一个我在实际项目里的体会。很多同学做这类系统时容易花大量精力去堆功能页面比如做了一个又一个列表、表单却忽略了业务规则和数据关系。其实面试官或者答辩老师真正关心的往往是你对核心业务场景的理解比如预约冲突怎么处理、并发情况下怎么保证不超卖、多个模块之间的数据怎么串联起来统计。把这三件事想明白、实现好比多写十个CRUD页面都有说服力。做宠物服务系统时先围绕“预约、服务、结算”这条线去思考和提问思路理顺了代码自然就好写。