Spring Boot宠物饲养系统设计与实现全解析

做毕设或者练手项目的时候，我经常被问到“宠物饲养系统能做什么，为什么值得做”。今天我就拿“2026精选课题-基于springboot宠物饲养系统的设计与实现”这个题目，完整拆一遍它背后的需求、设计、代码实现和踩坑经验。适合正在选毕设题目的学生、想用Spring Boot练手的初级开发者，以及打算做宠物服务类产品的创业团队参考。这个课题最核心的价值不只是“写一个增删改查”，而是把预约管理、宠物档案、商品购买、消息通知这些真实业务揉进一个体系里，让你完整走一遍从需求分析到部署上线的研发流程。

1. 课题价值分析：这个系统到底解决什么问题

1.1 为什么选Spring Boot而不是其他框架

先说选题逻辑。市面上毕设常见的框架有三种：SSH（Struts2 + Spring + Hibernate）、SSM（Spring + Spring MVC + MyBatis）和Spring Boot。现在再抱着SSH写新项目，基本没人这么干了，配置太繁琐，光搭环境就能劝退一批人。SSM虽然经典，但你要手工处理一堆XML配置、依赖版本对齐，甚至需要你自己去拼装Spring容器。Spring Boot最大的优势是“自动装配”和“约定优于配置”，它把那些重复性的配置工作收敛到了starter里，你引入一个spring-boot-starter-web，内嵌的Tomcat、默认的Spring MVC就都给你准备好了。

用生活里的事打个比方，SSM像你自己买零件组装台式机，机箱、电源、主板、内存都得选兼容的版本，出问题要一个个排查；Spring Boot像买品牌整机，开箱即用，选配件的活儿官方已经帮你干了一部分。对毕设来说，核心时间应该花在业务设计和功能实现上，而不是浪费在“为什么我的配置文件又报错了”这种环境问题上。

Spring Boot还有一个对毕设非常友好的点：生态成熟。需要做权限验证，有Spring Security或Sa-Token；需要做缓存，有Spring Data Redis；需要做定时任务，有内置的@Scheduled；需要做接口文档，有springdoc或Knife4j。这些组件的资料多、案例全，遇到问题基本都能搜到答案。

1.2 宠物饲养系统的用户需求与功能边界

很多同学拿到这个题目，第一反应是“不就是宠物信息管理吗，做一个表，增删改查完事”。说实话，如果这样做，答辩的时候大概率会被老师挑毛病，因为一个完整的饲养系统应该覆盖三种角色：宠物主人、管理员、以及负责日常照顾宠物的饲养员/护理人员。它的核心场景不是“给宠物建个档案看看”，而是“主人把宠物托付给系统，系统安排照料、记录状态、推送消息、产生消费”。

我梳理了一下，一个满足毕设深度的宠物饲养系统，至少要包含以下功能点：

• 宠物主人端：注册登录、添加和管理宠物档案、提交寄养/护理预约、查看喂养与健康记录、在线购买宠物用品、接收订单和预约消息。
• 照顾端/饲养员端：查看待处理预约、填写喂养记录、更新宠物健康状态、处理订单发货。
• 管理后台：审核用户与预约、管理宠物分类和商品、统计订单收入、配置基础信息。

这些功能合在一起，正好能覆盖Java Web开发里常见的各种技术点：用户认证、权限区分、文件上传、关联查询、定时任务、消息推送。写满这些内容，论文的“系统设计”和“功能实现”两章才不会写得干巴巴。

2. 系统架构与整体设计思路

2.1 单体架构还是微服务：毕设别给自己挖坑

我见过不少同学上来就想用Spring Cloud搞微服务，把订单、用户、商品全部拆成独立服务，再用Nacos做注册中心、Gateway做网关。想法是好的，但我不建议在毕设里这么做，原因有三个：一是你要预留大量时间处理分布式环境下的调试问题，二是答辩通常只有十几分钟，微服务的复杂度反而会稀释业务亮点，三是一台普通学生电脑跑三个微服务加中间件，内存可能直接拉满。

宠物饲养系统适合用“模块化单体”的结构，也就是一个Spring Boot应用内部分层，按业务边界分包，而不是物理拆分成多个进程。我建议的分包结构是这样的：

com.example.petcare ├── controller // 接口层，接收请求、返回响应 ├── service // 业务层，处理核心逻辑 ├── mapper // 数据访问层，MyBatis-Plus 的 Mapper ├── entity // 数据库实体类 ├── dto // 接收前端参数的对象 ├── vo // 返回前端数据的对象 ├── config // 配置类，如跨域、拦截器、Knife4j ├── common // 通用返回结果、异常处理、常量 ├── utils // JWT工具、日期工具等 └── task // 定时任务类

这种分层方式是前后端分离项目中比较成熟的做法，controller只负责参数接收和结果包装，不写业务逻辑；service负责事务和业务规则；mapper只做数据操作。好处是答辩时你画分层架构图非常直观，而且真正出问题时定位也快。

2.2 技术选型：Spring Boot + Vue + MySQL + Redis的组合逻辑

后端框架定了Spring Boot之后，其他组件的选择也尽量走“社区主流”路线。我试过的一套稳定组合可以给你参考：

组件	版本建议	用途说明
Spring Boot	2.7.x 或 3.x	2.7.x资料最多，3.x对JDK17更友好
JDK	8 或 17	2.7.x建议JDK8，3.x必须JDK17
MySQL	8.0	存业务数据，用InnoDB引擎
Redis	6.x/7.x	存验证码、热点数据、分布式会话
MyBatis-Plus	3.5.x	简化CRUD，避免大量手写SQL
Vue	3 + Element Plus	管理端和用户端界面
MinIO	8.5.x	宠物图片、商品图的文件存储
Knife4j	4.x	自动生成接口文档，答辩演示神器

这套组合的核心逻辑是“生态兼容、文档齐、部署简单”。MySQL和Redis都有可视化工具，答辩时演示起来方便。MinIO可以用Docker一键启动，也可以直接在本地跑。前端用Vue是因为Spring Boot最常见的搭档就是Vue，前后端分离的部署方式（前端Nginx + 后端Jar包）也好讲清楚。

2.3 角色权限设计：前后端配合怎么做

权限设计是这种系统里老师最喜欢问的点。你不能只说“用户登录后可以访问某些接口”，至少要能讲清楚Token的传递过程和控制逻辑。

我的做法是用JWT生成登录凭证，后端写一个拦截器统一校验Token。流程是这样的：用户登录成功后，后端生成一个包含用户ID、用户名、角色的Token返回给前端；前端通过store把Token存起来，并在每次请求的请求头里带上Authorization: Bearer token；后端拦截器解析Token，如果合法就放行，并把用户信息放入ThreadLocal供业务层取用。

角色区分上，用户端和管理端走的是“同一套登录接口、不同权限注解”。我在自定义的@RequireRole注解里定义角色值，在需要管理员权限的接口上标注@RequireRole("ADMIN")，拦截器解析到用户角色后，判断是否允许访问。这样既不用给前端返两份菜单，又能做到接口级别的权限隔离。这里有个容易踩的坑，前端菜单的显隐只是体验问题，真正的权限控制必须以后端校验为准，否则别人通过接口模拟工具直接调你的管理员接口就突破了权限。

3. 数据库设计与核心表结构

3.1 宠物饲养系统需要哪几张核心表

数据库设计是整个系统的地基，我建议在写代码之前先把表设计出来。宠物饲养系统核心表可以分成四组：用户权限组、宠物业务组、交易组、消息与记录组。

用户权限组我设计了四张表：

• user：用户表，字段包括id、username、password、nickname、phone、avatar、role、status、create_time。role用USER表示普通用户，ADMIN表示管理员，CARETAKER表示饲养员。
• user_address：用户收货地址表，购买商品时需要。
• 权限这块如果要做细，可以拆role和permission，但毕设用角色字段基本够了。

宠物业务组是整个系统的核心，围绕“宠物档案-预约-照养记录”这条链路：

• pet：宠物信息表，字段包括id、user_id、pet_name、pet_type、breed、age、gender、weight、avatar、medical_history、create_time。
• care_order：寄养/护理预约订单表，字段包括id、order_no、user_id、pet_id、caretaker_id、service_type、start_time、end_time、status、total_price、create_time。
• care_record：喂养与健康记录表，记录每天喂食、遛弯、体温、精神状态等。
• health_record：疫苗和驱虫记录表，方便宠物主人随时查看。

交易组对应商城功能：

• product：商品表，字段包括id、name、category_id、price、stock、image、description、status。
• product_category：商品分类表。
• order：订单表，字段包括id、order_no、user_id、total_amount、status、receiver_name、receiver_phone、receiver_address、create_time。
• order_item：订单明细表。

消息与记录组：

• notification：站内消息表，用于给用户推送预约审核、订单发货等通知。
• operation_log：操作日志表，记录管理员的关键操作。

一个比较实用的设计技巧是：所有业务表都加上create_time、update_time、deleted这三个公共字段。前两个用于展示和审计，deleted用于逻辑删除。逻辑删除做毕设真的比物理删除省心，数据误删还能恢复，答辩的时候还可以作为数据安全性的一个亮点来讲。

3.2 关键表关系与SQL建表示例

表关系上，我是这样设计的：一个用户拥有多只宠物，一只宠物可以产生多个预约订单，一个预约订单对应多条照养记录；一个用户可以下多个订单，一个订单包含多个商品项。这些都是典型的一对多关系，用外键不一定非要建在数据库层面，但要在实体类里体现关联关系，MyBatis-Plus查询时通过@TableField和关联查询把它们组合起来。

下面给出一张care_order表的完整SQL，你直接改一改就能用：

CREATE TABLE `care_order` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键', `order_no` VARCHAR(32) NOT NULL COMMENT '订单编号', `user_id` BIGINT NOT NULL COMMENT '下单用户ID', `pet_id` BIGINT NOT NULL COMMENT '宠物ID', `caretaker_id` BIGINT DEFAULT NULL COMMENT '饲养员ID', `service_type` TINYINT NOT NULL COMMENT '服务类型：1寄养 2洗澡 3体检 4遛宠', `start_time` DATETIME NOT NULL COMMENT '开始时间', `end_time` DATETIME NOT NULL COMMENT '结束时间', `status` TINYINT NOT NULL DEFAULT '0' COMMENT '状态：0待支付 1待接单 2照养中 3已完成 4已取消', `total_price` DECIMAL(10,2) NOT NULL COMMENT '订单金额', `remark` VARCHAR(255) DEFAULT NULL COMMENT '备注', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', `deleted` TINYINT NOT NULL DEFAULT '0' COMMENT '逻辑删除：0未删 1已删', PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`), KEY `idx_pet_id` (`pet_id`), KEY `idx_status` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='宠物看护预约订单表';

这里有几个值得注意的细节：order_no建立唯一索引后，可以用order_no做业务查询，而不是只看主键；status字段建立索引是因为列表页最常见的筛选条件就是按状态；金额字段用DECIMAL(10,2)而不是FLOAT，不然会出现0.1加0.2不等于0.3这种问题。

3.3 不留心就会出问题的表设计细节

第一，不要给所有字段都设成NOT NULL。caretaker_id在用户刚下单的时候可能还没指派，你强行设成非空，代码里插入数据就会一直报错。合理的做法是允许为空，等系统分配饲养员后再更新。

第二，字符串类型尽量用utf8mb4字符集。如果还用老旧的utf8，用户昵称里一旦有Emoji表情，写进数据库就会变成乱码甚至报错。

第三，创建订单时要保证订单号唯一。最稳妥的方式是在Java里生成时间戳 + 用户ID + 随机数的组合，或者在数据库里用雪花ID算法。千万不要用UUID直接做主键排序，性能不好还难调试。

4. 功能模块拆解与核心代码实现

4.1 基于JWT的登录认证与ThreadLocal用户上下文

登录接口的完整逻辑不只是“查一下用户名密码对不对”，密码必须加密存储。我用的是BCryptPasswordEncoder，它每次加密结果都不一样，但是校验的时候能判断是否匹配，这样即使数据库泄露，明文密码也不会直接暴露。

核心代码如下：

@Service public class AuthServiceImpl implements AuthService { @Autowired private UserMapper userMapper; @Autowired private StringRedisTemplate stringRedisTemplate; @Override public LoginResponse login(LoginRequest request) { // 1. 校验验证码，Redis中取出，与前端提交的对比 String code = stringRedisTemplate.opsForValue().get("captcha:" + request.getUuid()); if (code == null || !code.equalsIgnoreCase(request.getCaptcha())) { throw new BusinessException("验证码错误或已过期"); } // 2. 查询用户 User user = userMapper.selectOne(new LambdaQueryWrapper<User>() .eq(User::getUsername, request.getUsername())); if (user == null || !passwordEncoder.matches(request.getPassword(), user.getPassword())) { throw new BusinessException("用户名或密码错误"); } if (user.getStatus() != 1) { throw new BusinessException("账号已被禁用"); } // 3. 生成JWT，放入userId和role String token = JwtUtil.createToken(user.getId(), user.getRole()); return new LoginResponse(token, user.getNickname(), user.getRole()); } }

登录成功后，后续请求如何识别用户身份？我写了一个拦截器，统一解析请求头里的Token：

@Component public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (request.getMethod().equals("OPTIONS")) { return true; // 放行预检请求 } String authHeader = request.getHeader("Authorization"); if (authHeader != null && authHeader.startsWith("Bearer ")) { String token = authHeader.substring(7); Claims claims = JwtUtil.parseToken(token); if (claims != null) { UserContext.set(claims.get("userId", Long.class), claims.get("role", String.class)); return true; } } response.setStatus(401); return false; } }

UserContext是基于ThreadLocal封装的一个工具类，请求结束时要记得在afterCompletion里调用UserContext.clear()，否则线程池复用线程时，用户信息会串到下一个请求里去，这是非常隐蔽的一个Bug。

4.2 宠物档案模块：文件上传与对象存储MinIO

宠物档案里最麻烦的是图片上传。很多人第一次做的时候把图片Base64编码塞进数据库，结果一张两兆的照片直接把数据库卡死。正确做法是把图片文件上传到对象存储，数据库里只存图片的URL。

MinIO的集成方式非常简单，先在pom.xml里引入依赖：

<dependency> <groupId>io.minio</groupId> <artifactId>minio</artifactId> <version>8.5.7</version> </dependency>

然后写一个配置类，把MinIO的地址、账号、桶名都放到application.yml里：

minio: endpoint: http://127.0.0.1:9000 access-key: minioadmin secret-key: minioadmin bucket-name: petcare

上传文件的工具类方法：

public String uploadFile(MultipartFile file) { String originalFilename = file.getOriginalFilename(); String suffix = originalFilename.substring(originalFilename.lastIndexOf(".")); String objectName = UUID.randomUUID() + suffix; try { boolean exists = minioClient.bucketExists(BucketExistsArgs.builder() .bucket(bucketName).build()); if (!exists) { minioClient.makeBucket(MakeBucketArgs.builder().bucket(bucketName).build()); } minioClient.putObject(PutObjectArgs.builder() .bucket(bucketName) .object(objectName) .stream(file.getInputStream(), file.getSize(), -1) .contentType(file.getContentType()) .build()); return endpoint + "/" + bucketName + "/" + objectName; } catch (Exception e) { throw new BusinessException("图片上传失败"); } }

上传成功返回的URL就是公网可以访问的图片地址，前端img标签的src直接填它就行。这里有一个必须注意的点：如果你部署在本地，MinIO的endpoint不要写127.0.0.1，不然前端打开的图片地址指向的是用户自己电脑，会直接加载失败。我建议写局域网IP或者服务器IP，前端访问后端时才能用同样的地址把图片获取到。

4.3 预约下单与状态流转：事务与并发控制

预约下单是业务里比较容易出错的场景。用户选择宠物、服务时间、服务类型后提交订单，系统要做的操作至少有三步：生成订单记录、减少相关库存或服务名额、给饲养员发送待接单消息。这三步必须在一个事务里完成，否则只生成了订单但消息没发出去，数据就不完整。

Spring Boot里用@Transactional注解就可以：

@Override @Transactional(rollbackFor = Exception.class) public Long createCareOrder(CareOrderCreateRequest request) { // 1. 生成订单号 String orderNo = generateOrderNo(); CareOrder order = new CareOrder(); order.setOrderNo(orderNo); order.setUserId(UserContext.getUserId()); order.setPetId(request.getPetId()); order.setServiceType(request.getServiceType()); order.setStartTime(request.getStartTime()); order.setEndTime(request.getEndTime()); order.setStatus(0); order.setTotalPrice(calculatePrice(request.getServiceType(), request.getStartTime(), request.getEndTime())); careOrderMapper.insert(order); // 2. 创建待办消息 Notification notification = new Notification(); notification.setUserId(request.getCaretakerId() == null ? DEFAULT_CARETAKER_ID : request.getCaretakerId()); notification.setTitle("新预约待处理"); notification.setContent("您有一个新的" + serviceTypeName(request.getServiceType()) + "预约"); notificationMapper.insert(notification); return order.getId(); }

下单的并发场景也值得提一句。如果你的系统需要预约名额限制，比如一个饲养员一天最多接5单，那在判断“是否还有名额”和“创建订单”之间就可能出现超卖问题。最简单可靠的做法是数据库层面加条件更新：

UPDATE caretaker_schedule SET accepted_count = accepted_count + 1 WHERE id = #{scheduleId} AND accepted_count < 5

返回影响行数为1才说明更新成功，然后再插入订单。这比先查询再判断要安全得多。答辩的时候能讲出这种并发处理思路，会比只说“我加了事务”高一个档次。

4.4 定时任务：自动取消超时未支付订单

宠物饲养系统里一定会遇到这样一个问题：用户下单后一直不支付，订单就卡在“待支付”状态，占用饲养员的时间名额。解决方案是定时扫描超时订单，自动把它们改成“已取消”。

Spring Boot自带的@Scheduled就能完成这个任务，不需要额外引入Quartz：

@Component public class OrderTimeoutTask { @Autowired private CareOrderMapper careOrderMapper; // 每5分钟执行一次 @Scheduled(cron = "0 */5 * * * ?") public void cancelTimeoutOrders() { LocalDateTime deadline = LocalDateTime.now().minusMinutes(15); List<CareOrder> timeoutOrders = careOrderMapper.selectList( new LambdaQueryWrapper<CareOrder>() .eq(CareOrder::getStatus, 0) .lt(CareOrder::getCreateTime, deadline)); for (CareOrder order : timeoutOrders) { order.setStatus(4); careOrderMapper.updateById(order); } } }

注意一个细节：如果你要跑定时任务，主启动类上要加@EnableScheduling注解，否则任务不会生效。另外，定时任务的执行时间并不是精确秒级，它是轮询的，所以“超时15分钟”实际可能是“超时15到20分钟”，这个误差在毕设场景里完全可以接受。如果你想做更精准的延迟关闭，可以引入Redisson的延迟队列，但那就超出毕设需要了。

4.5 消息通知：Redis + WebSocket打通实时推送

前面提到预约下单会给饲养员或用户发站内消息，但这个“消息”存在数据库里，用户如果不刷新页面，永远看不到新通知。要做出实时提醒效果，最轻量的方案是WebSocket。

先引入依赖：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-websocket</artifactId> </dependency>

写一个WebSocket配置类：

@Configuration public class WebSocketConfig { @Bean public ServerEndpointExporter serverEndpointExporter() { return new ServerEndpointExporter(); } }

再写一个消息端点，用@ServerEndpoint标识连接路径，并配合一个Map维护“用户ID到会话”的对应关系。当订单状态变更时，调用NotificationWebSocket.sendMessageToUser(userId, message)，前端在onmessage里弹一个提示，效果就很像真实的APP通知了。

这个功能不算复杂，但展示效果很好。答辩演示时你让用户端下单，饲养员端的浏览器页面实时弹出“您有一个新预约”，老师会认为你考虑了系统的可用性问题，而不是只做了数据存储。

5. 实操过程：从零到可运行项目的完整搭建流程

5.1 快速初始化Spring Boot项目骨架

很多人在IDEA里新建Spring Boot项目时会卡在“初始化失败”，因为默认的初始化服务器在国内访问不稳定。我建议直接去Spring Initializr官网生成项目压缩包，或者用阿里云的镜像地址。

如果你使用的是IDEA，新建Project时选择Spring Initializr，把Server URL改成https://start.aliyun.com，然后按下表选择依赖：

场景	需要的依赖
WEB接口	Spring Web
操作数据库	MyBatis Framework、MySQL Driver
缓存验证码	Spring Data Redis
参数校验	Validation
接口文档	Knife4j（手动加依赖）
热更新	Spring Boot DevTools

生成完项目后，建议先跑一次mvn spring-boot:run，确认空项目能启动，再去写业务代码。避免你写了一大堆代码才发现基础环境有问题，排查起来一锅粥。

5.2 application.yml核心配置解读

Spring Boot最劝退新手的不是Java代码，而是配置文件里的各种坑。这是我实际用下来比较完整的一个配置模板：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql:///petcare?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: root password: 123456 data: redis: host: 127.0.0.1 port: 6379 database: 0 servlet: multipart: max-file-size: 10MB max-request-size: 100MB 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 knife4j: enable: true setting: language: zh_cn

serverTimezone=Asia/Shanghai必须加，不然MySQL连接会报时区错误。allowPublicKeyRetrieval=true是MySQL 8.x连接时常见的坑，不加可能报Public Key Retrieval错误。logic-delete-field: deleted配置好后，MyBatis-Plus的删除操作会自动改成更新deleted字段，查询会自动过滤已删除数据，这个配置能帮你省大量重复代码。

5.3 前端联调：Vue3 + Element Plus的落地细节

单体系统的前端我建议直接用Vue3加Element Plus，管理后台用现成的模板改造，用户端自己写几个页面。工程结构如下：

• api目录：按模块封装请求，比如pet.js、order.js。
• router目录：配置路由和守卫，未登录跳登录页。
• store目录：用Pinia存用户信息和Token。
• views目录：登录页、宠物列表页、订单页、商品页、管理页。

跨域问题是前后端分离最常见的问题。后端开发时可以在Spring Boot里写一个CorsConfig：

@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); } }

但生产环境不建议用*，更合理的做法是前端域名走Nginx反向代理，把/api请求转发到后端8080端口，这样就不会有跨域问题。联调阶段先开CorsConfig图省事，部署时再切换成Nginx代理，这是比较成熟的做法。

5.4 打包部署：从Jar包到服务器运行

Spring Boot项目打包很简单，在项目根目录执行：

mvn clean package -DskipTests

打包后的Jar包在target目录下，在服务器上执行：

nohup java -jar petcare-server.jar --spring.profiles.active=prod > app.log 2>&1 &

nohup和&的作用是让程序在后台运行，日志输出到app.log，这样你关闭SSH连接后程序不会停。前端打包是执行npm run build，生成dist目录，然后把这个目录丢到Nginx的html目录下，同时配置反向代理：

server { listen 80; server_name your-domain.com; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

部署这块我踩过的坑是：前端路由用了history模式，刷新页面直接404，加一行try_files $uri $uri/ /index.html;就解决了。这个问题十个人里有八个人会遇到，放在笔记里回头查一下就能少走弯路。

6. 常见问题与排查技巧实录

6.1 项目启动失败的几类高频原因

我接触过的初学者项目，启动失败基本集中在三类原因：

现象	可能原因	快速排查方法
端口被占用	上一个应用没关闭	换端口，或netstat -ano查占用进程
数据库连接失败	MySQL没启动或密码不对	先用Navicat测试能否连上
报错找不到数据表	没执行SQL脚本	确认url里的库名是否正确

有一次我帮人排查了很久，结果是application.yml里的spring.datasource.url少写了一个/，导致连接的不是预期的数据库，表面看是表不存在，实际上连错库了。这种低级错误用日志里的连接地址就能看出来，别一上来就怀疑代码Bug。

6.2 接口通了但前端拿不到数据

接口调试阶段，最头疼的情况是后端接口用Postman测试正常，但前端一调就报跨域或拿不到数据。这里有一个容易忽略的地方：接口路径的/api前缀。如果你的前端请求路径是/api/pet/list，而后端Controller里的映射是/pet/list，且后端没配置context-path，就会404。

解决思路是：要么后端统一加server.servlet.context-path: /api，要么前端请求时统一拼接前缀。不要两个各搞一半，否则排查起来特别混乱。我的建议是后端不加前缀，前端在axios封装里统一加/api，这样后端接口干净，前端也好统一管理。

6.3 版本兼容：Spring Boot 3.x的几个变化

如果你用的是Spring Boot 3.x，和网上大量2.x教程会有几个差异点，需要特别留意：

• javax.servlet包换成了jakarta.servlet，所有导入的包名都要改。
• spring.factories自动配置机制改为AutoConfiguration.imports，自定义starter方式变了。
• Redis相关配置从spring.redis改成了spring.data.redis。
• 最低要求JDK17，老项目用JDK8会直接启动失败。

如果你只是做毕设，我建议优先选Spring Boot 2.7.x，因为网上的资料和老师手上的参考实现大多基于这个版本，遇到问题好搜。3.x的新特性可以在论文的“技术选型”里提一句，说明你了解演化方向，但没必要拿它冒险。

6.4 答辩准备：怎么把系统打造成亮点

代码写完了，答辩也是很重要的一环。我发现很多人的代码写得还可以，但讲的时候只会守着PPT念需求，完全没有把系统的技术含量表达出来。这里给你几个可以提前准备的“讲解角度”：

• 事务一致性：以“下单预约”为例，讲清楚为什么@Transactional能保证订单、库存、消息三者要么一起成功要么一起失败。
• 缓存与验证码：登录验证码存Redis，说明你懂得用缓存解决无状态认证问题。
• 文件处理：宠物图片走MinIO对象存储，数据库只存URL，解决数据库膨胀和访问性能问题。
• 定时任务：自动取消超时订单，体现系统的自动化运维能力。

花半天时间把代码里的核心逻辑按照“背景-问题-方案-效果”的结构整理成讲稿，比临场翻代码要稳得多。老师问到你不会的，也不用慌张，如实说“这部分我了解过，还没有深入实践”，但要注意别在自己的薄弱环节强行编造技术细节。

7. 扩展方向：从毕设到可落地产品的演进思路

如果你做完基础版本后还有余力，或者想把系统做得更有竞争力，可以往下面几个方向扩展：对接微信小程序端，让宠物主人在手机上就能查看实时照养照片和视频；引入流媒体服务，做宠物监控摄像头关联；把健康记录接入物联网设备，自动同步宠物体重、运动量等数据。这些方向在论文“展望”章节里写两三页完全没问题。

我个人做这个课题最大的体会是，毕设不要贪多，要贪“深”。与其堆五六个零零散散的功能，不如把一个预约流程从用户下单、饲养员接单、照养记录、消息通知到订单完结完整打通，让老师看到你对业务闭环的思考。把事务、权限、缓存、文件存储这些工程问题想明白，哪怕系统界面朴素一点，答辩依然能拿高分。

最后再分享一个小技巧：开发期把MyBatis-Plus的SQL日志打开，就是配置里那段log-impl。新手写代码经常出问题但不报错，这时候打开SQL日志，一眼就能看出数据到底有没有查出来、条件有没有拼对。等熟悉了这套链路之后再关掉日志，你会发现排查问题的效率高一大截。