1. 项目选题与整体设计思路1.1 选题背景与核心需求拆解每年毕业季Java方向的毕设题目翻来覆去就那么几类商城、管理系统、论坛、预约平台。宠物咖啡馆这个题目算是把“商城预约内容展示”揉在了一起既有电商属性又有线下店面的业务逻辑最关键的是它自带一种“很生活化”的展示优势答辩的时候讲起来不枯燥评委也容易理解业务背景。我当时给一位学弟指导这个题目的时候第一反应就是这本质上是一个“带宠物元素的零售餐饮预约系统”不要被“咖啡馆”三个字带偏了它的核心是会员、宠物、商品、订单、预约、寄养这几条业务线。拆解一下需求所谓宠物咖啡馆平台往细了说至少有这些功能用户端能看到宠物列表、店铺介绍、商品咖啡甜点猫狗零食、服务项目宠物寄养、宠物美容、领养申请然后用户可以注册登录、下单购买商品、预约到店座位、预约寄养服务管理端要能够管理宠物信息、商品上下架、处理订单、审核预约、管理会员以及查看一些基础统计。如果是毕业论文还需要写“系统管理”这类常规模块比如管理员登录、权限管理。很多同学一上来就想做得非常花哨什么AI识别宠物、实时视频监控这显然超出了毕设的合理范围。我的建议是老老实实把“信息管理 交易闭环 预约闭环”做扎实创新点可以在“宠物档案SaaS式商铺配置”或者“预约排座算法”上做一点简单的扩展既能控制开发量又能在论文里写出像样的“研究意义”。1.2 技术选型解析为什么是 Spring Boot MyBatis Plus MySQL技术选型是整个项目的地基选错了后面全是坑。Spring Boot 是毫无疑问的主框架它把 SSM 时代大量繁琐的 XML 配置省掉了内置 Tomcat打包成 jar 直接跑非常适合毕设这种需要快速出成果的场景。版本上我建议使用 Spring Boot 2.7.x而不是 3.x主要原因是3.x 基于 Jakarta EE很多老教程里的 javax 包名要换且部分第三方兼容性还不稳定2.7.x 是 2.x 的最终版本资料最多、踩坑最容易找到解决方案。这一点在正文后面会专门拿出来说。持久层我会选择 MyBatis Plus而不是原生 MyBatis也不是 JPA。原因很简单MyBatis Plus 提供了内置的 BaseMapper单表 CRUD 完全不用写 SQL分页插件也是现成的对于毕设这种以“单表操作 少量自定义多表查询”为主的场景效率能提升一倍。当然涉及到订单与订单详情、宠物与领养申请的关联查询时还是要自己写 SQLMyBatis Plus 的 LambdaQueryWrapper 只能解决“单表条件查询”这种 80% 的情况。数据库用 MySQL 8.0这个没有悬念。Redis 我个人建议可加可不加如果只是为了毕设演示可以不用引入 Redis但如果你想让论文里多一些技术亮点可以把“首页宠物热度排行”“验证码存储”这些场景用 Redis 实现代码量不大却是个很好的加分项。前端方面如果是自己一个人全栈用 Vue 2 Element UI或者直接使用 Thymeleaf 服务端渲染都行更省事的是找一个现成的后台管理模板如若依之类但若依体系太重改起来反而不透明我建议用 Vue 3 Element Plus Axios自己手写一套轻量的登录和路由权限对毕设来说足够清晰。1.3 系统角色与功能模块划分角色设计不宜过多否则会产生大量的权限判断逻辑。我最终只设计了三种角色访客未登录用户、会员注册用户、管理员店铺运营者。访客可以浏览宠物、商品、门店信息但不能下单和预约会员除了浏览外可以下单支付模拟支付、预约座位、申请宠物领养、寄存宠物管理员则通过一个独立的后台界面可以放在同一个前端项目里用路由权限隔离管理全部业务。功能模块按照业务域划分成六个大模块用户中心登录注册、个人信息、我的订单、我的预约、宠物模块宠物展示、宠物详情、领养申请、寄养登记、商品模块商品分类、商品列表、购物车、订单支付、预约模块门店座位预约、寄养预约、后台管理宠物管理、商品管理、订单管理、预约管理、会员管理、统计报表、系统管理管理员账号、菜单权限、操作日志。每个模块内部都是标准的 CRUD关键是模块之间的数据关系要理清楚比如“订单”会引用“用户”和“商品”“预约”会引用“用户”和“宠物”别把外键搞成一团乱麻。2. 数据库设计与核心表结构2.1 核心表关系梳理数据库表的设计决定了后续编码是“顺畅”还是“拧巴”。我见过太多同学一开始就把表设计得过分复杂比如把咖啡、宠物、寄养订单全都塞进一张表加一堆空字段又或者为了讲“规范化”硬拆成七八张关联表每次查询都要 join 一大串。合理的做法是围绕“业务主链路”来建表。我这边建立了大概十张表这里给你梳理出最关键的关系链路。首先是“用户—订单—商品”这条电商链路user 表保存账号密码及会员等级product 表保存商品基本信息orders 表保存订单主信息消费总额、状态、下单时间order_item 表保存订单明细一个订单对应多个商品。然后是“用户—宠物—领养/寄养”这条特色链路pet 表保存可展示的宠物包括猫狗的品种、年龄、性格、是否可领养adoption_apply 表保存用户的领养申请boarding_order 表保存宠物寄养预约信息。还有一条“用户—座位预约”链路reservation 表保存预约到店的日期时间段和人数。这三条链路之间有一个公共的核心表就是 user 表所以我们通常在 user 表上做冗余统计字段比如用户积分、累计消费金额主要用于后台的会员排行展示避免每次查询都去聚合订单表。每张表都可以留一个deleted字段逻辑删除和create_time/update_time字段这是 MyBatis Plus 的标准配置后面做数据恢复和排查问题都会方便很多。2.2 宠物信息表、商品表、订单表的关键字段设计下面我把三张最核心表的字段设计拿出来逐条分析这些都是实际开发中踩过坑之后总结出来的。宠物信息表 petid 主键自增pet_name宠物名字species物种猫/狗/其他breed品种age年龄用整数存月份比如 6 表示六个月大这样查询“青年宠、幼宠”时可以做范围筛选gender性别avatar头像 URLdescription性格描述用 text 类型status状态0-在店展示1-已被领养2-寄养中3-下架adoptable是否开放领养布尔值shop_id归属于哪家门店如果你做的是单店这个字段可以先留着未来扩展多店。商品表 productidcategory_id商品分类咖啡、甜品、宠物零食、宠物玩具product_nameprice用 decimal(10,2)记住不要用 float金额类的精度必须用定点数stock库存imagestatus上下架状态sales销量用于热门排序。订单表 ordersid可以设计成雪花ID或者字符串订单号不建议用自增整数直接给用户看因为很容易被遍历order_no业务订单号建议用“日期随机数”生成例如20240601103056001user_idtotal_amountstatus这里我建议用整数枚举而不是字符串0-待支付1-已支付2-已取消3-已发货/已完成4-退款中5-已退款pay_type支付方式模拟支付pay_timecreate_time、update_time。一张好表的核心标准不是“字段多”而是“每个字段都有明确用途且查询条件都有对应索引”。比如商品表的 status category_id 组合索引订单表的 user_id status 组合索引这在后续做列表查询时基本不会出现慢查询。2.3 用索引和状态字段避免常见坑数据库层面最常见的坑有两个第一个是模糊查询没用索引第二个是状态字段用字符串存导致统计 SQL 写得非常痛苦。我在设计宠物列表接口时需要支持按照“品种”和“状态”筛选这时候如果只给 breed 加普通索引查询效率也可以接受但在大数据量下还是建议用联合索引(species, status)来覆盖“某物种下的可领养宠物列表”这个高频查询。再有一个很关键的状态管理技巧无论是宠物状态还是订单状态不要散落在代码里写死数字而是在 Java 项目里定义一个常量类或者枚举比如PetStatusEnum、OrderStatusEnum代码里只引用常量名。这样写的好处是后来改状态含义的时候只用改一处也避免了团队成员之间因为“状态 1 到底代表什么”扯皮。我见过不少项目把状态值直接写在 SQL 里where status 1过几天再去读代码时完全不知道 1 的含义。3. 核心模块实现与实操要点3.1 用户登录与权限校验JWT 拦截器用户认证这部分我建议不要用 Shiro 或 Spring Security对毕设来说太重了自己手写 JWT 拦截器完全够用而且能在论文中清楚讲解“Token 无状态认证”的原理答辩时也容易表现。具体做法是登录接口接收用户名密码校验通过后生成一个 JWT把用户 ID 和角色封装进 token设置 24 小时有效前端把 token 存到 localStorage请求时在 Axios 拦截器里加Authorization: Bearer xxx。后端新建一个拦截器继承 Spring 的HandlerInterceptor在preHandle里从 header 取 token用jjwt解析如果解析失败就返回 401。注意要放行登录接口、注册接口和宠物浏览接口其他接口都走拦截器。对于管理员接口可以在拦截器里再判断claims.get(role)是否等于ADMIN。这里有个我实测的坑跨域预检请求OPTIONS不会携带自定义 header所以拦截器里必须直接放行 OPTIONS 请求否则前后端联调时会发现所有带 token 的请求都挂了。JWT 的依赖我用的是io.jsonwebtoken:jjwt-api:0.11.5 io.jsonwebtoken:jjwt-impl:0.11.5 io.jsonwebtoken:jjwt-jackson:0.11.5注意如果只引入 api 而不引入 impl运行时就会报Unable to discover any JWT implementation这个错我见太多人问过了。3.2 宠物领养/寄养模块状态流转的完整实现宠物领养是整个平台相对有特色的流程。用户看到一只可领养的宠物点击“申请领养”系统检查该宠物状态是否为“可领养”是则创建一条领养申请并把宠物状态改为“领养中”管理员审核申请审核通过后宠物状态改为“已领养”同时给用户发送一条站内消息可以简单地用 message 表实现审核不通过则宠物状态回滚为“可领养”。这个流程的重点在于状态流转要有一个“状态机”思想不要用一堆 if 到处改状态。我在代码中用一个 service 方法专门负责状态变更例如public boolean applyAdoption(Long petId, Long userId) { Pet pet petMapper.selectById(petId); if (pet null || !PetStatusEnum.ADOPTABLE.getCode().equals(pet.getStatus())) { throw new BusinessException(当前宠物不可申请领养); } // 同一用户同一宠物只能申请一次 Long count adoptionApplyMapper.selectCount( new LambdaQueryWrapperAdoptionApply() .eq(AdoptionApply::getPetId, petId) .eq(AdoptionApply::getUserId, userId) ); if (count 0) { throw new BusinessException(您已申请过该宠物的领养请勿重复申请); } // 创建申请记录 AdoptionApply apply new AdoptionApply(); apply.setPetId(petId); apply.setUserId(userId); apply.setStatus(ApplyStatusEnum.PENDING.getCode()); adoptionApplyMapper.insert(apply); // 变更宠物状态 pet.setStatus(PetStatusEnum.ADOPTING.getCode()); petMapper.updateById(pet); return true; }这个示例里有两个细节值得注意一是“重复申请”校验虽然表结构里可以加联合唯一索引但业务层也要执行一遍因为用户前一次申请如果被拒绝他可能还想再次申请直接加唯一索引会把这条路堵死二是宠物状态的变更必须和创建申请放在同一个事务里否则申请成功但宠物状态未更新就会出现两个用户同时看到“可领养”的脏数据。3.3 订单与预约模块状态机设计与并发防重订单模块算是整个项目中最容易出错的环节。先明确一下订单状态流待支付 - 已支付 - 已完成待支付也可以变成已取消。后端接口要做两件重要的事第一创建订单时要锁定库存不能把库存减成负数第二支付回调时要做幂等处理防止前端重复点击导致同一笔订单被支付两次。库存锁定的代码建议这样写int rows productMapper.deductStock(productId, quantity); if (rows 0) { throw new BusinessException(库存不足); }这里deductStock的核心 SQL 是update product set stock stock - #{quantity} where id #{productId} and stock #{quantity}依靠数据库行锁和条件更新来保证并发安全。很多同学喜欢先查询库存再判断然后再更新这个做法在单线程演示时没问题但并发测试一压就崩而且答辩时评委如果问“两个用户同时下单怎么办”就答不上来。支付环节如果是模拟支付直接写一个接口把订单状态从待支付改成已支付即可但要在 Controller 里加一个“防重”判断只有当订单状态是待支付时才能执行更新否则抛出异常。这样即使前端连点两次第二次更新返回 0 行业务不会重复触发。预约模块和订单模块不同它不只是状态问题更关键的是“时间段库存”。座位预约表再设计一张 reserve_config 表存每个时间段的可预约座位数预约时同样用条件更新set remaining remaining - 1 where time_slot ? and remaining 0来实现并发控制。这个方案简单有效不用引入分布式锁足够应付毕设场景。3.4 后台管理接口的实现细节后台管理端主要就是各种列表查询和状态管理。我建议所有管理端查询都做成“分页 条件筛选 时间范围”三件套不要直接把整表数据返回给前端因为一旦数据量稍微上来前端渲染就会卡顿而且答辩时用大列表展示也不好看。用 MyBatis Plus 的分页插件只需要配置一个MybatisPlusInterceptor添加PaginationInnerInterceptor然后在 Service 里用page(new Page(current, size), wrapper)即可。这里有个小的实操心得管理端的列表接口如果你想把订单详情也展示出来不要在循环里逐个查商品表要先用订单 ID 集合一次性查出所有订单项再在内存中组装。这个优化很基础但很多新手容易忽略导致一个只有 20 条订单的页面请求几百次 SQL接口变慢还容易被评委挑战“性能方面考虑不足”。后端统一返回格式也很重要我设计了一个ResultT类包含code、message、data三个字段配合全局异常处理器RestControllerAdvice把异常统一包装成Result。这样前端处理响应时就只需判断code 200简洁且规范。4. 部署与联调常见问题排查4.1 本地环境与数据库连接问题很多同学项目明明写好了但启动就报错八成是环境和配置问题。最常见的配置坑有三个第一是application.yml里的时区写错导致数据库时间比实际少了 8 个小时。建议直接写serverTimezoneAsia/Shanghai并且连接字符串里带上useUnicodetruecharacterEncodingutf8避免中文乱码。第二是 MySQL 8.0 的驱动类名是com.mysql.cj.jdbc.Driver不是旧的com.mysql.jdbc.Driver如果你用的是 MySQL 8 驱动却写旧类名启动必报ClassNotFoundException。第三是本地数据库安装后默认端口可能是 3306如果你的机器上还跑了别的服务占用了端口连接就会失败开发时可以用sudo lsof -i:3306看看端口被谁占用。如果项目启动时报Failed to configure a DataSource不要急着怀疑数据库先检查依赖里是不是漏了spring-boot-starter-jdbc或者mybatis-plus-boot-starter版本与 Spring Boot 版本不兼容。这里我推荐一个组合Spring Boot 2.7.18 mybatis-plus-boot-starter 3.5.3.2 mysql-connector-j 8.0.33这个组合我实测下来非常稳没有遇到诡异的依赖冲突。4.2 Spring Boot 版本兼容性坑点刚才提到了版本这里展开讲讲。现在网上找教程很容易搜到基于 Spring Boot 3 的但很多老项目用的还是 2.x两者的 API 有些不同。比如WebMvcConfigurer的位置Spring Boot 3 是在jakarta.servlet包下而 2.x 在javax.servlet包下再比如spring.factories自动配置机制在 3.x 里被废弃改为AutoConfiguration.imports文件。如果你照着 3.x 的教程写 2.x 的项目可能在编译阶段就报一堆包不存在。还有一个容易忽略的坑Spring Boot 2.3.x 之后的版本对spring.mvc.pathmatch.matching-strategy的处理不太一样。如果你做的是管理后台类项目又引入了 knife4j 或 springfox 做接口文档可能会遇到Failed to start bean documentationPluginsBootstrapper的报错。解决方法是全局配置里加一行spring: mvc: pathmatch: matching-strategy: ant_path_matcher这个配置在 Spring Boot 2.6 以上版本非常常见是兼容 Swagger 的经典操作。我建议不要在毕设中为了接口文档去引入过多的 Swagger 依赖自己写接口时用GetMapping的路径命名规范一些就好答辩时打开 Postman 现场请求几个接口比看 Swagger 截图更有说服力。4.3 前端联调跨域与参数传递问题前后端分离的项目联调时最大的障碍就是跨域。前端跑在 8081 端口后端跑在 8080 端口浏览器默认会拦截这种跨域请求。解决办法是后端添加一个全局 CORS 配置类代码大概是这样的Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }注意allowedOriginPatterns(*)和allowCredentials(true)必须一起使用否则 Spring 会报错误。还有前面提到的拦截器必须放行OPTIONS请求不然预检请求被拦下前端请求根本进不来。参数传递容易犯的错主要在日期格式上。前端传给后端的日期如果是个字符串比如2024-06-01 10:00:00后端如果用Date类型接收需要在接收字段上加上DateTimeFormat(pattern yyyy-MM-dd HH:mm:ss)否则会报解析失败。返回给前端时建议统一用字符串格式化好的String类型的返回时间避免出现Timestamp的复杂格式让前端处理起来麻烦。4.4 性能优化与安全加固建议虽然毕设不会要求你做极高的并发优化但适当做一些安全加固和性能优化能让项目显得更完整。我建议至少做到这几件事密码存储不要用明文至少用 MD5 加盐或者 BCrypt 加密。用 Spring 自带的BCryptPasswordEncoder很方便代码里一个 Bean 即可。管理员操作的关键接口如删除宠物、修改订单状态做一下简单的日志记录可以用 AOP 记录操作人、操作时间、操作内容不只是为了答辩演示也是真实项目的基本要求。接口层做统一的参数校验用Validated加NotNull、Length这类注解避免非法的空值一路传到数据库再抛异常。列表查询接口一律分页不要提供“查询全部”的接口防止前端误操作拉走全量数据。说到性能优化如果你的宠物列表有图片建议前端做懒加载后端压缩图片不要把原图直接传到服务器。另外可以在宠物详情接口加一个简单的 Redis 热点缓存如果没用 Redis可以用一个本地Caffeine缓存把热点数据缓存起来缓存五分钟流量高峰期效果很明显。这个点可以在论文里单独写一小节标题就叫“基于 Spring Cache 的缓存策略”写起来非常顺手。最后再说两句这个项目我前前后后带过几个学生做从需求分析到答辩演示最深的体会是毕设项目的成功并不在于技术多花哨而在于每个环节都能讲出道理。你用什么技术为什么用这个技术数据表为什么要这样设计状态流转为什么用条件更新而不是单纯查询判断这些都是答辩时老师最爱问的也是真正区分“背代码”和“做项目”的地方。如果你准备做这个题目我建议你按这个顺序推进先花三天把数据库表和实体类全部建好再写后端的公共部分统一返回、异常处理、登录拦截然后按“宠物模块 - 商品订单模块 - 预约模块 - 后台管理”的顺序一个个完成业务闭环最后一天统一处理前端页面。千万不要一上来就纠结某个页面好不好看业务逻辑跑通了页面再丑都不影响项目通过。有一个小技巧把项目跑起来之后提前录制一段一分钟的操作视频涵盖用户注册、登录、下单、管理员发货这个完整流程上传到网盘或者存到答辩的 U 盘里。防止答辩现场网络出问题现场演示不成功的话视频可以兜底。这个经验是我踩过坑才总结出来的关键时刻能救你一命。
