SpringBoot宠物店管理系统实战：从JWT鉴权到数据库设计的完整开发指南

宠物店管理系统这种项目，可以说是JavaWeb方向里面最经典的“入门即实战”选题之一了。数据量和业务逻辑不像电商平台那么复杂，但又能把CRUD、权限、关联查询、文件上传这些后端基本功全部串起来。不管是拿来做毕业设计、课程设计，还是纯粹想找一个能完整体验SpringBoot开发流程的项目练手，它都非常合适。

这个项目我前前后后做过两遍，第一遍是给一个线下宠物店做内部管理工具，第二遍是帮学生改造成毕业设计版本，走了不少弯路，也攒了一些比较实用的经验。接下来我就按一个真实项目的推进顺序，把从需求拆解、技术选型到表结构设计、后端接口实现，再到最后的部署上线整个链路讲清楚。老规矩，全程只讲实操和思路，不写空话。

1. 项目要解决的核心问题：先把宠物店的日常盘明白

1.1 一家宠物店到底在管什么

选这个题目之前，我建议你先搞清楚一件事：宠物店的日常运营和普通零售店很不一样。普通店卖完东西就结束了，宠物店的核心是“宠物本体的档案和健康状态”，商品货架只是配角。

我做需求调研的时候，跟店主聊了很久，最后盘出来宠物店实际面对的核心诉求其实就这几条：

• 会员和宠物档案要绑定。狗粮、疫苗、洗澡、美容、寄养全都围绕一只具体的宠物展开，而宠物属于某个会员。系统里没有独立的“宠物表”连接“会员表”，整个逻辑就没法落地。
• 活体销售要有完整的状态流转。宠物从入库、展示、预定、售出到离店，得有一个状态机跟踪，不能一删了之。
• 服务预约是刚需。洗澡、美容、驱虫、疫苗提醒都有时间属性，店员需要看得到未来几天的预约排班。
• 库存预警和销售统计要走通。宠物零食、猫砂这类消耗品，卖完了如果没人提醒补货，影响很直接。

当然，毕设版本不需要做到门店ERP那种恐怖颗粒度，但核心主线必须完整。我在设计时给这个项目规划了三个核心角色：管理员（老板视角）、员工（店长/美容师）、会员（进店客户）。

围绕这三个角色，功能落点就很清晰了：

1.2 功能模块别贪多，但每个模块必须闭环

很多同学一上来就想做几十张表，最后把自己累死，答辩时还讲不清模块关系。我个人的建议是，以“一个业务主语走到底”的思路来切：客户带着宠物来，买商品或做服务，产生订单和预约记录。

实操时我把系统切成六个能自圆其说的功能域：

• 系统登录与权限控制：Spring Security手动写一遍，或者用JWT+拦截器做。毕设建议自己写JWT过滤器，能讲清楚原理。
• 会员与宠物档案管理：会员手机号唯一登录，一个会员可以绑定多个宠物。宠物有品种、体重、疫苗时间、过敏史等字段。
• 宠物商品与库存管理：商品分宠物食品/用品/药品等大类，支持图片上传，库存低于警戒线给出提醒。
• 美容服务与预约管理：服务项、服务时长、价格、可预约时段，会员和员工都能发起预约。
• 订单与收银管理：支持购物车结算，支持服务订单转化，订单状态可跟踪。
• 数据报表模块：按月统计收入和服务分类销量，用简单SQL聚合，配合图表框架展示。

这样划分，每个模块之间都有业务因果，而不是一张张独立的“字典表”。比如“预约”和“宠物档案”是强关联的，宠物档案改动会影响后续服务记录；“商品”和“订单”是强事务的，涉及库存扣减。

2. 技术选型：为什么是这个组合，以及怎么避坑

2.1 SpringBoot版本的选择：这个比你想的重要

SpringBoot几乎成了Java后端项目的默认起点，原因是它把Spring那套繁琐的XML配置全部收编成了“约定优于配置”，内嵌Tomcat让部署也简单了。但实际操作时碰到的第一个坑就是版本。

先说结论：毕设和中小型管理系统，我建议用SpringBoot 2.7.x系列，搭配JDK 1.8或JDK 11。 我知道现在SpringBoot 3.x已经出了很久，但这里有个很现实的兼容性问题。SpringBoot 3.0是基于JDK 17的，很多老教程的Maven依赖、第三方框架（尤其是一些生成代码的工具或小众库）都是基于旧版本设计的。如果你照着一个2.x的项目抄，但自己建的是3.x工程，很容易碰到一堆莫名其妙的编译错误。

SpringBoot 2.7.18是2.x的终极版本，相当稳定，网上资料最多，面试被问到的概率也大。等把这个项目吃透了，再迁移到3.x去理解JDK 17的新特性，是更平滑的路径。

这一步要同时确认三个东西——JDK版本、Maven版本、SpringBoot版本，三者需要彼此兼容，不然大概率会在启动阶段就翻车。

2.2 ORM框架选择：MyBatis还是MyBatis-Plus

在真正的开发社区里，“MyBatis还是JPA”的争论一直存在，但针对宠物店这种管理后台，我更推荐使用MyBatis-Plus。原因特别朴素：这里没有超高并发、没有分库分表，核心诉求是开发效率。

MyBatis-Plus帮我把单表CRUD的样板代码消灭了一大半，内置的Wrapper构造器写条件查询非常顺手。举个例子，查询“所有打过疫苗且体重超过5kg的猫”：

java复制LambdaQueryWrapper<Pet> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(Pet::getType, "猫")
       .eq(Pet::getIsVaccinated, 1)
       .gt(Pet::getWeight, 5);
List<Pet> pets = petMapper.selectList(wrapper);

这种链式调用，十秒钟就能写出一个原本要写一大堆SQL标签的查询。对宠物店的模糊搜索、多条件筛选这种场景，体验简直不要太舒服。当然，多表关联复杂统计的时候，我自己更倾向直接写注解SQL或XML，并不迷信MP的每件事都能干。

2.3 前端方案：Vue+ElementUI还是服务端渲染

因为项目是“前后端分离”的调性更抓眼球，大部分毕设会选择Vue+ElementUI。我个人建议分两种情况考虑。

如果你的时间紧，比如你离提交只剩两三周，建议直接选服务端渲染。用Thymeleaf模板引擎配合Bootstrap或Layui做后台界面，后端一个SpringBoot进程全搞定，不需要额外搭一套Node环境，也不用被跨域问题折磨。缺点是交互体验相对“古老”，但目前看不出明确的答辩论据劣势。

如果时间比较充裕，比如你有四到六周，我强烈建议做前后端分离。Vue3+Vite+ElementPlus作为前端框架，后端只负责提供JSON接口，整个架构更接近目前企业的开发习惯。面试或者答辩时你就可以多说一句：“前端通过Axios调用后端RESTful接口，利用JWT做无状态认证，前端资源可以独立部署到Nginx，实现动静分离。”这句话的含金量在面试场景中比项目本身还值钱。

我这次最终用的是Vue3+ElementPlus方案，项目结构分成了pet-admin（前端）和pet-server（后端）两个目录，看代码的层次感好很多。

3. 数据库设计：一张好表能省一万行判断逻辑

3.1 核心表结构梳理

我先明确一点，数据库设计不是一次到位的，关系再复杂也别指望一步画出终极ER图。我的习惯是先把“主业务线”的表建扎实，然后边写接口边补索引，边补字段。

宠物店的核心表我按业务主线给排了一遍：

3.2 状态字典字段：别小看状态机

我踩过一个比较深的坑，是订单表和预约表的“状态字段”设计得过于随意。一开始只用一个String字段，存“待付款”“进行中”“已完成”，前台判断时用大量if...else把字符串匹配写死。某天改了一个状态名字，整个前端页面全乱了。

后来我在表里为各状态预设一个tinyint类型，并固定了一套状态流转逻辑：

• 预约状态：0=待确认，1=已确认，2=已完成，3=已取消
• 订单状态：0=待支付，1=已支付/待服务，2=服务中/发货中，3=已完成，4=已取消

这样设计的好处是，前端拿到数字状态，用一个数组映射就能展示对应文本，后端要批量统计时也只需要做范围查询，比如统计当月有效订单就是status in (1,2,3)，不需要关心中文名称如何匹配。

这里建议你在application.yml统一加一个状态映射的前端枚举常量类，别在Java代码里裸写if("已完成".equals(status))。

3.3 时间字段的隐藏规则

宠物表里的“疫苗时间”和“下次疫苗提醒时间”一定要用Date类型存，不要只存String。因为后续要写一个定时任务，查询“今天有哪些宠物需要打疫苗”，Date类型可以直接用SQL日期函数处理。

同时所有表都建议加上create_time和update_time两个审计字段。MyBatis-Plus提供了MetaObjectHandler接口可以自动填充，少写了很多重复的赋值代码。

4. 后端核心模块实操：从零到能跑通业务

4.1 项目骨架和公共结构

后端工程我建议按以下包结构划分，清晰度直接影响你后续写代码的心情：

code复制com.petstore
├── config          // 配置类（跨域、MyBatis-Plus分页、静态资源映射）
├── controller      // 控制层
├── service         // 业务层（接口+实现）
├── mapper          // 数据访问层
├── entity          // 实体类
├── dto             // 前端入参对象（区别entity）
├── vo              // 视图返回对象（可以灵活组合数据）
├── common          // 统一返回值、异常处理、常量
└── utils           // JWT工具类等

这里要提一下，很多初学者容易把entity直接塞给前端当返回值，这在简单CRUD里没问题，但一旦牵涉到“查询订单详情时需要附带会员昵称和宠物名”，就会因为实体类字段不足而手足无措。此时正确的做法是构建一个OrderDetailVO类，字段按前端展示需求定义，在Service层组装好再返回。

4.2 登录认证与权限拦截：用JWT实现无状态认证

自己写Spring Security对于初次接触的人会有点难理解，所以我更倾向于直接手写JWT+拦截器方案，逻辑更直白，代码量也完全可控，答辩时能讲得更清楚。

流程是这样的：用户输入手机号/用户名和密码登录，后端校验通过后生成一个包含用户id和角色的token串返回给前端，前端把token存储在localStorage中，每次请求在请求头里带上Authorization: token，后端写一个拦截器校验该token是否有效。

生成JWT这里的代码是核心：

java复制public String generateToken(Integer userId, String role) {
    Map<String, Object> claims = new HashMap<>();
    claims.put("userId", userId);
    claims.put("role", role);
    return Jwts.builder()
        .setClaims(claims)
        .setSubject(String.valueOf(userId))
        .setIssuedAt(new Date())
        .setExpiration(new Date(System.currentTimeMillis() + 7L * 24 * 3600 * 1000))
        .signWith(SignatureAlgorithm.HS256, SECRET_KEY)
        .compact();
}

拦截器里要做的事情就是：放行登录接口，拦截其他接口校验token。如果校验失败，返回统一的401状态和JSON。因为员工端和会员端的数据视角不同，我干脆在token里加了角色字段，后续管理员接口加一个@RequireAdmin之类的自定义注解，通过拦截器用反射检查controller方法上有没有这个注解来完成权限校验。这样做比引入完整Spring Security轻量得多，而且逻辑也能讲明白。

4.3 宠物档案管理：表单校验和文件上传

宠物档案的新增与编辑是这个系统里最需要细心的一块，因为字段多、类型杂。前端Vue表单绑定一个petForm对象，提交数据后，后端用@Validated注解来做参数校验能省很多事。

比如新增宠物时，体重不能为负数、生日不能晚于今天，这些校验规则写在DTO上，用@DecimalMin、@Past这类注解标一下就行。真正麻烦的反而是宠物照片上传。

图片上传有两个比较常见的坑。

第一个是静态资源映射。当图片上传到本地磁盘的D:/pet-store-images/目录后，需要让SpringBoot把URL路径映射到该目录才能访问到图片：

java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/upload/**")
                .addResourceHandler("file:D:/pet-store-images/");
    }
}

不配置这一步，数据库存的图片路径在浏览器里就是一串404。

第二个是文件类型校验和后缀伪造。哪怕前端已经限制只能传jpg/png，后端也要再做一次校验，防止恶意上传jsp/php文件。最简单可靠的做法是检查文件的Content-Type和Magic Number，至少也要把后缀白名单卡死，避免把可执行文件带到服务器上。

4.4 商品订单与库存扣减：事务边界很关键

商品购买的下单流程可以很好地考察一个开发者对事务的理解。我先先把代码跑通，然后反问自己一个问题：如果扣库存成功了，但生成订单失败了，会怎样？答案是——系统里某个商品的库存变少了，但订单表里查不到这笔记录，后台对账时永远差一笔。

要解决这个问题，就要在Service方法上加上@Transactional注解，让扣库存和生成订单在一个数据库事务中执行：

java复制@Transactional(rollbackFor = Exception.class)
public Order createOrder(OrderCreateDTO dto) {
    // 1. 校验商品库存
    // 2. 扣减库存（UPDATE product SET stock = stock - #{num} WHERE id = ? AND stock >= #{num}）
    // 3. 生成订单主记录
    // 4. 批量插入订单明细
    return order;
}

这里我用的是原子性的“乐观扣库存”写法：UPDATE ... WHERE stock >= num，而不是先select出来判断再update。在单机应用且并发量不高的场景下，这个方案已经足够可靠，还能避免超卖。

同样地，预约成功后对应的服务时段不能重复被占。设计上我给预约表加了唯一索引(service_item_id, appointment_time, employee_id)，这一行索引就挡掉了同一个美容师在同一时间段被重复预约的情况。这个不起眼的小细节，做过的项目中可以记到经验总结里。

4.5 数据报表：聚合查询这样写不难

管理端的仪表盘会展示“近7日订单数”“当月销售额”“宠物类型占比”这些图表数据。后端给前端提供统计接口时，不需要在Java里做内存循环累加，直接把SQL聚合逻辑写好就完了。

比如统计每月销售额：

java复制SELECT DATE_FORMAT(create_time, '%Y-%m') AS month,
       SUM(total_amount) AS amount
FROM orders
WHERE status IN (1, 2, 3)
GROUP BY month
ORDER BY month DESC;

前端拿到这个List，直接把month和amount交给ECharts的折线图即可。

这里有一个提示：前端图表展示的字段命名最好用驼峰或符合JSON习惯的短字段名。后端如果用MyBatis-Plus的selectMaps查询，返回的Map里key是数据库列名（如month、amount），如果数据库列名是下划线风格（如total_amount），就需要用别名把字段名转成前端可识别的形式。前两年我用ECharts时经常检查半天发现不是数据错了而是字段名不对。

5. 前端页面与交互设计经验

5.1 前端项目结构组织

Vue3项目中我按模块来组织页面目录，而非按组件类型堆叠。宠物店的管理后台页面主要包括：登录页、工作台/仪表盘、宠物列表、宠物详情、商品列表、订单列表、预约日历、会员列表。我推荐以下结构：

code复制src
├── api          // 按模块存放接口请求
├── assets
├── components   // 公共组件
├── router       // 路由与守卫
├── store        // Pinia状态管理
├── views
│   ├── dashboard
│   ├── pet
│   ├── product
│   ├── order
│   ├── appointment
│   └── member
└── utils

5.2 路由守卫与权限控制

因为后端已经做了接口权限，前端的路由守卫更多是做页面跳转控制。用户在未登录状态下访问/admin路径要强制跳转登录页，登录后根据角色动态渲染菜单。

代码实现用Vue Router的全局前置守卫最方便：

javascript复制router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token')
  if (to.path === '/login' && token) {
    next('/dashboard')
  } else if (to.meta.requiresAuth && !token) {
    next('/login')
  } else {
    next()
  }
})

但需要注意，前端权限只是优化体验用的，真正安全的控制一定在后端接口层完成，不能只做一个菜单隐藏就当权限做好了。

5.3 写一个复用程度高的“弹窗表单”

这个系统涉及大量新增、编辑弹窗。一个高效的做法是封装一个基于ElementPlus的通用弹窗组件，里面放一个动态表单配置对象。表单展示哪些字段、校验规则如何、提交地址是什么，全由父组件传一个对象决定。这样新增宠物和新增商品虽然表单项不同，但弹窗交互逻辑可以共用。

当然，如果为了赶进度不想过度设计，直接把表单写在各页面里也完全可以，但至少要做到弹窗打开时清空旧数据，否则会碰到“编辑一条数据未保存，再点新增，弹窗里还是旧数据”的尴尬情况。

6. 部署与上线的各种姿势

6.1 在本地一键Run起来

本地运行时步骤比较简单：启动MySQL服务和Redis服务（如果不需要Redis可以完全去掉），创建数据库并执行sql脚本，通过IDEA运行SpringBoot主类，前端在项目根目录执行npm install && npm run dev，然后浏览器访问Vue默认地址。唯一需要保证的是后端接口地址和前端代理配置一致。

在项目配置中我会为本地开发设置一份application-dev.yml，它使用本地数据库账号、后端端口8080、图片上传到项目本地临时目录。application-prod.yml则指向云服务器MySQL或Docker容器。这种做法清晰又整洁，不要一个配置文件一把梭。

6.2 使用Docker部署的花式操作

把SpringBoot应用打成一个镜像，再搭配docker-compose把MySQL和后端服务一并管理起来，是目前很主流的部署方式。

Maven中配置好spring-boot-maven-plugin后，打包：

bash复制mvn clean package -DskipTests

执行后target目录中会生成pet-server.jar，然后写一个轻量的Dockerfile：

dockerfile复制FROM openjdk:8-jre-alpine
COPY pet-server.jar /app/app.jar
WORKDIR /app
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar", "--spring.profiles.active=prod"]

MySQL容器直接使用官方镜像，再挂载数据卷避免容器删除后数据丢失。使用docker-compose服务编排后，来回敲十几条Docker命令，一个docker-compose up -d就全启动了，效率提高很多。

6.3 Nginx托管前端并转发API

前端项目打包会生成dist目录，里面是纯静态文件。将该目录部署到Nginx的html路径下，并配置反向代理转发API请求：

nginx复制server {
    listen 80;
    server_name pet.example.com;

    location / {
        root /usr/share/nginx/html;
        index index.html;
        try_files $uri $uri/ /index.html;
    }

    location /api/ {
        proxy_pass http://backend:8080/api/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

核心原因是前端路由是history模式，刷新某个子页面时如果Nginx没有配置“找不到文件就回退到index.html”，就会出现404。很多同学本地跑得好好的，一放到服务器就白屏，八成是这里的问题。

7. 常见问题与排错速查表

结合我做这个项目时掉过的坑和给同学排查时遇到的高频问题，我整理了一份速查表，希望帮助你直接定位问题。

7.1 排查问题的基础方法论

上面这张表的背后其实有一套通行的排查方法论。我每次碰到接口返回不对，基本会按这个顺序来处理，而不是一上来就翻业务代码：

1. 打开浏览器F12 Network面板，确认请求到底发出没有、请求头对不对、返回的HTTP状态码和响应体是什么。
2. 看后端控制台日志。启动时有没有报错，接口请求时有没有打印异常堆栈。如果没日志，先确认日志级别是否开到了DEBUG。
3. 在Service方法和Mapper方法上打断点，逐步确认是入参问题、SQL拼接问题还是返回组装问题。
4. 把MyBatis-Plus执行的SQL打印出来，确认实际执行的SQL语句跟预期是否一致。改一条错误SQL比改一段错误Java代码要容易得多。

这些基本功会在项目里反复用到，等你做完这个系统，你回头看自己排错的速度会变快很多。

8. 代码之外的额外加分项

有几个不会写进常规代码，但能在答辩、面试或实际使用中凸显细节的增强点，我这次也做了出来。

8.1 疫苗提醒定时任务

既然系统里存了每只宠物的疫苗时间，为什么不用定时任务主动提醒？我用SpringBoot自带的@Scheduled写了一个轻量定时任务，每天早晨跑一次，扫描宠物表里疫苗时间在未来7天内的记录，然后推送给对应的会员。

在启动类或者配置类上加上@EnableScheduling开启调度，在Service方法上写：

java复制@Scheduled(cron = "0 0 8 * * ?") // 每天上午8点执行
public void remindVaccine() {
    List<Pet> pets = petMapper.selectNeedVaccine(LocalDate.now(), LocalDate.now().plusDays(7));
    // 这里可以把提醒记录写入提醒表
    // 也可以对接短信或微信模板消息，但毕设阶段做到站内信即可
}

这个功能虽然不大，但它是宠物店系统的“粘性功能”，老板会真心觉得系统不只是个记录本。BGM：这算是这次相比普通CRUD管理系统的加分项。

8.2 预约日历视图

管理端的预约管理用传统的列表展示确实差点意思，考虑到实际业务中“今天哪些时段被约了”是老板最关心的，我把预约列表做成一个按天维度展示的时间线视图，前端使用Vue日历组件或者FullCalendar接入。后端只需要提供按日期查询预约的接口，前端自行渲染。

8.3 数据导出功能

管理端把订单导出Excel是一个高频需求。前端可以直接用SheetJS在前端把接口返回的JSON渲染成Excel，后端也可以集成EasyExcel导出更灵活的格式。

我这次采用后端EasyExcel的方式，原因是导出的订单数据往往包含会员信息和宠物信息，后端从数据库取数更方便，前端处理的话遇到分页就会受限制。后端导出的代码大概是：

java复制@GetMapping("/export")
public void export(HttpServletResponse response) throws IOException {
    List<OrderExportVO> list = orderService.listForExport();
    EasyExcel.write(response.getOutputStream(), OrderExportVO.class)
             .sheet("订单数据")
             .doWrite(list);
}

只需要在OrderExportVO的字段上加上@ExcelProperty("订单号")这样的注解，就能生成一个带表头的Excel文件，特别好用。

好，这个项目的核心实现思路和踩坑经验就分享到这里。我再顺手提一个给后面学习者的建议：这个项目不必追求大而全的界面和高深的技术，但要做到“业务闭环、代码结构清晰、关键点能讲透”。如果你能把这套流程走一遍，JWT认证、事务处理、多表联查、接口数据组装、前端联调这些技能基本就练扎实了，面试官问起项目，你也有足够的实战细节可以讲。遇到任何不确定的地方，建议多动手试几次，项目是调试出来的，不是看出来的。