SpringBoot2+Vue3前后端分离宠物店系统：架构设计与实战解析

搞Java后端的同学应该都有这种体验：项目源码网上能找到不少，但能完整跑通的不多，带文档的更少，带文档还能做到前后端分离、技术栈不过时的就少之又少了。这套网上宠物店系统属于少数能让我本地几分钟内就启动起来的项目。SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0，四个关键词直接命中当前主流的Java Web开发组合。整套源码整理得很规整，附带SQL脚本、接口文档、设计说明，不管是拿来当毕设参考、自己练手，还是想二次开发做点小生意，都有文章可做。这篇文章我不做源码逐行讲解，而是把整个项目拆开揉碎，从架构设计、数据库建模、后端核心实现、前端要点、部署排错到扩展方向，完整地过一遍。

1. 项目定位与整体架构拆解

1.1 这套系统到底包含哪些功能

宠物店系统听起来简单，实际拆开来看，涉及到的业务模块并不少。这套系统从前台用户视角和后台管理员视角分别设计了两套界面。

用户端核心功能：

• 注册登录，基于JWT做无状态认证，退出登录前端清除token即可
• 商品浏览，按宠物类别分类展示，支持关键词搜索
• 商品详情，包含轮播图、价格、库存、描述信息
• 购物车管理，加购、改数量、删除、批量结算
• 订单提交与查询，我的订单列表、订单状态流转
• 个人中心，收货地址管理、个人信息修改

后台管理端核心功能：

• 管理员登录与权限拦截
• 宠物商品管理，商品的增删改查，上下架操作
• 类目管理，对宠物分类进行维护
• 轮播图管理，配置首页展示的Banner
• 订单管理，查看所有订单，修改订单状态
• 用户管理，查看注册用户信息

整体看下来，这是一套标准的电商系统教学实战项目。业务完整度比单纯增删改查Demo高出一个级别，又没有大型电商系统那些复杂的分销、优惠券、秒杀逻辑，作为学习模板刚好合适。

1.2 前后端分离架构速览

项目整体是典型的前后端分离结构，端口也做了区分。后端SpringBoot默认跑在8080端口，前端Vue3开发环境下通过Vite代理到后端接口，避免跨域问题。

交互链路大致是这样：

• 前端Vue页面通过axios发起HTTP请求
• 请求先经过后端拦截器，校验JWT是否有效
• 通过后进入Controller层，再向下调用Service层处理业务逻辑
• Service层通过MyBatis-Plus操作MySQL数据
• 处理结果封装成统一的JSON结构返回给前端
• 前端根据响应状态码做对应处理，渲染页面

我比较欣赏的是它没有把后端代码全堆在Controller里。很多新手项目习惯把业务逻辑直接写在Controller方法里，这套项目至少分出了Controller、Service、Mapper三层，代码结构上具备可读性，也方便后面做扩展。

前端目录结构和后端对应，按页面维度拆分了views目录，公共组件放在components里，接口请求统一放在api目录。我在实际翻阅源码时最大的感受是：命名规范统一，驼峰、语义化都做得不错，不需要花太多时间就能定位到某个功能对应的代码位置。

2. 技术选型背后的取舍逻辑

2.1 后端：SpringBoot2并非越新越好

很多人在选型时会纠结用SpringBoot2还是3.x。这套项目选择SpringBoot2.x是经过考量的。SpringBoot3要求JDK17起步，而不少高校实验室和生产环境的机器还停留在JDK8。SpringBoot2.x配合JDK8是当前存量最大的组合，资料多、踩坑记录多、出了问题好搜解答。从学习到工作的平滑过渡角度看，SpringBoot2其实是更稳妥的选择。

配合的MyBatis-Plus也有讲究。相比原生MyBatis需要手写大量XML，MyBatis-Plus提供了BaseMapper通用方法，单表CRUD几乎不用写SQL。宠物店这种业务量级的系统，大部分操作都是单表查询，多表关联场景很有限，用MyBatis-Plus能把开发效率提上来。而且它的分页插件、条件构造器对新手非常友好，代码写起来直观。

2.2 前端：Vue3组合式API带来的开发体验

前端选择了Vue3，这已经是当前前端框架的主流方向。项目里采用的是组合式API风格，用setup语法糖写组件。相比Vue2选项式API，组合式API在逻辑复用上明显更灵活。

管理后台的表格、表单、弹窗等组件，基本都是研读Element Plus的官方文档后封装出来的。我对这套技术组合的评价是：没有引入全家桶式的重量级框架，也没有追求CSS框架的花哨效果，组件化程度作为学习型项目完全够用，且代码简单好懂，适合新手去读。

2.3 数据库：MySQL8.0的默认选择

MySQL8.0在性能和功能上都比5.7强，窗口函数、公共表表达式这些特性在复杂统计查询里很好用。现在新安装的MySQL基本都是8.0版本，项目直接使用8.0避免了很多旧版本兼容问题。值得一提的是，8.0的默认身份认证插件是caching_sha2_password，JDBC驱动需要匹配，后面部署环节我会专门说这个坑。

在本地开发时，一般建议装Navicat或者DataGrip来管理数据库。直接导入项目提供的SQL脚本就能建库建表，非常省事。记得提前确认字符集，建库时用utf8mb4，别用utf8，否则存emoji或者生僻字容易出乱码。

3. 数据库设计：七张核心表如何支撑一个电商闭环

3.1 用户表和购物车的拆分思路

用户表users设计得比较收敛，字段基本是id、username、password、phone、email、avatar这类常规信息。密码存储没有明文保存，走的是MD5加盐的思路，安全性上比纯明文好很多。

这里有一个设计细节我特意看了：购物车单独建了cart表，字段包含用户id、商品id、数量、选中状态。为什么不直接把购物车商品放到订单里？因为购物车是用户的临时挂单区，它不产生业务数据变化，用户很久没下单，购物车内容还在；订单则是交易凭证，包含的是商品快照。两者拆开，后续做订单统计和商品销量分析时，数据边界清晰很多。

3.2 商品表与类目表的关联设计

商品表pet在命名上做得比较讨巧，直接用业务词汇做表名。字段设计包括商品名称、原价、现价、库存、图片、所属类目、销量、描述、上架状态。类目表category单独拆出来，跟商品表通过category_id关联。

这种设计的好处是类目可以灵活增删，比如新增一个"小宠用品"类目，不需要改动商品表结构。从代码层面看，列表页请求接口时，前端传入categoryId，后端用MyBatis-Plus的QueryWrapper做条件查询，一行条件构造就完成过滤，性能和写法都很轻量。

商品图片字段存的是URL路径，实际使用中图片资源可以放在本地静态目录，也可以接入对象存储。这种设计天然兼容了不同规模的部署方式。

3.3 订单相关表的状态流转设计

订单模块是整个系统的核心，涉及order（订单主表）和order_items（订单明细表）。订单主表存订单编号、用户id、总金额、收货人信息、订单状态、创建时间；明细表存商品名、商品图片、购买数量、购买单价。为什么要拆主表和明细表？一个订单可能包含多种宠物用品，主表存订单维度信息，明细表存商品维度信息，这样无论按订单查总金额，还是按商品统计销量，都不需要跨表扫数据。

订单状态用数字类型存储，含义通过代码注释说明。我建议拿到源码后先全局搜一下订单状态对应的常量映射，把0待付款、1已付款待发货、2已发货、3已完成、4已取消这些数字含义标在笔记里，后面调试时能省不少时间。

4. 后端核心代码实现复盘

4.1 统一响应结构与全局异常的实战处理

这可能是整套代码里最值得学习的一部分。项目封装了统一的响应体结构，大概长这样：

{ "code": 200, "message": "操作成功", "data": { ... } }

Controller层不需要手动拼装返回结果，业务方法只负责返回数据，统一由Result工具类包装。这么做最大的好处是前端处理逻辑统一：axios拦截器里判断code字段是否为200，是就取data渲染，否则弹出message提示。如果每个接口返回结构都不一样，前端每个请求都要单独写处理逻辑，维护成本成倍上涨。

全局异常处理也值得说。项目里用@RestControllerAdvice统一捕获业务异常和未预期异常，而不是在每个Controller里try-catch。这样代码干净得多，即使遇到空指针这类意外错误，用户端也只会收到一个友好提示，不会把异常堆栈暴露给前端。

4.2 JWT登录认证与前端token联动

登录流程很常规但很完整。用户提交用户名密码后，后端校验通过，生成JWT令牌返回前端。前端拿到token后存储在本地，通常是localStorage，之后每个请求在请求拦截器中把token塞进请求头。

后端侧需要重点理解的是拦截器配置：

@Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(jwtInterceptor) .addPathPatterns("/api/**") .excludePathPatterns("/api/user/login", "/api/user/register", "/api/commodity/**"); }

拦截器要从请求头中解析token，校验合法性，然后把用户信息放入请求上下文。这里有个实战细节：拦截器只拦截需要登录的接口，像商品列表、商品详情这种公开接口要注意排除在外，否则用户没登录连商品都看不了。我自己写项目时经常在这个配置上踩坑。

4.3 MyBatis-Plus的三个高频写法

项目里MyBatis-Plus的用法非常典型，掌握了这三处就相当于掌握了它八成用法。

第一个是IService和ServiceImpl的配合。业务Service继承IService接口，实现类继承ServiceImpl，所有通用方法直接继承下来，比如查询列表的list()、按id查询的getById()、分页的page()。

第二个是QueryWrapper条件构造器。例如商品分页查询：

QueryWrapper<Pet> wrapper = new QueryWrapper<>(); wrapper.like(StringUtils.isNotBlank(name), "name", name) .eq(categoryId != null, "category_id", categoryId) .eq("status", 1); Page<Pet> page = petMapper.selectPage(new Page<>(current, size), wrapper);

这个写法有几个好处。第一个参数传入布尔值控制条件是否生效，前端没传搜索关键词时，like条件自动跳过，避免拼出空条件的查询；同时静态方法调用很安全，不会出现字符串拼接的SQL注入问题。

第三个是分页插件的配置。MyBatis-Plus的分页依赖PaginationInnerInterceptor插件，需要在配置类中注册：

@Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }

忘记配这个插件，分页方法会查出全量数据，这是新手最容易踩的坑。项目里已经配好了，但我建议你自己动手删掉再跑一遍分页，观察现象，理解原理远比背配置重要。

4.4 订单提交的事务处理

提交订单这个操作涉及多张表的数据变更：生成订单主记录、写入订单明细、扣减商品库存、清空购物车中对应商品。这一系列操作要么全部成功，要么全部失败，必须开启事务。

项目在Service方法上加了@Transactional注解来保证原子性。它的原理我简单说下：Spring默认对RuntimeException回滚，对受检异常不回滚，所以如果有业务点在子方法里抛出Exception类型，记得在@Transactional上声明rollbackFor = Exception.class，否则会出现订单生成了但库存没扣这种脏数据。这个是经典的隐藏Bug，项目里没有这个问题，但你二次开发时一定要有这个意识。

库存扣减这里还涉及到并发问题。虽然宠物店体量不大，但如果上线后几十个人同时下单抢最后一件商品，不加锁就可能超卖。我看了源码，它没有做库存乐观锁校验，这个可以作为你扩展练习的方向，用version字段实现乐观锁，是MyBatis-Plus非常经典的实战案例。

5. 前端Vue3落地实现要点

5.1 路由配置和登录守卫

前端路由用createRouter创建，配合createWebHistory模式。管理端和用户端的路由通过meta信息区分权限。登录守卫的写法是关键：

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

这段代码的逻辑是检查目标路由是否标记了需要登录，如果没登录统一跳转到登录页。理解这个机制后，你新增页面时只需要在路由配置里加上requiresAuth字段，页面立刻受到登录保护，扩展起来很舒服。

5.2 Axios封装里的拦截器设计

前端对请求的统一处理是axios封装。项目里封装了request工具类，设置baseURL、超时时间，并在请求拦截器和响应拦截器里做token注入和错误处理。

请求拦截器：

service.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = token; } return config; });

响应拦截器里判断code，完成后端业务状态的统一处理。一个值得留意的点：当后端返回401或其他鉴权失败的状态时，响应拦截器里最好清除本地token并跳转登录页，避免用户一直停留在失效页面里操作然后反复弹错。

5.3 商品列表和购物车交互的响应式处理

商品列表页通过ref定义数据源，onMounted生命周期里调接口拉数据，用v-for渲染卡片。搜索和筛选通过绑定事件重新拉取数据，实现思路是"数据驱动视图"。

购物车页面有一点值得学习：它没有每次操作都请求后端重新拉全量购物车数据，而是本地维护一个购物车数组，增删改先改本地数据，再同步调后端接口。这样页面响应快，不闪烁；接口失败时回滚本地状态并提示用户。这种乐观更新策略在真实项目里很常用。

前端和后端交互时还有一个细节：时间格式。后端返回的日期格式默认是带T的ISO格式，前端直接显示会很难看。项目里在JSON序列化配置里做了格式化，或者前端用dayjs格式化后再渲染。无论用哪种方式，统一处理时间格式都是电商类前端页面必须考虑的问题。

6. 部署运行与高频报错排查

6.1 本地环境准备与启动步骤

我把从拿到源码到页面跑通的完整过程列出来，照着走基本不会出问题：

1. 安装JDK8以上版本，配置JAVA_HOME环境变量
2. 安装MySQL8.0，启动服务后在命令行执行项目提供的SQL脚本，创建数据库和表结构
3. 修改后端application.yml里的数据库用户名、密码和URL，确认数据库名一致
4. 用Idea导入后端项目，等待Maven依赖下载完成，启动SpringBoot主类
5. 前端项目用VSCode或WebStorm打开，执行npm install安装依赖，再执行npm run dev启动开发服务器
6. 浏览器访问前端地址，按文档里的管理员账号登录后台

整个过程最容易卡住的环节是Maven依赖下载慢。国内环境下建议在maven的settings.xml中配置阿里云镜像源，不然SpringBoot那一堆依赖能下载半小时。同样，npm install在默认源下也慢，把registry切换成国内镜像，体验会好很多。

6.2 常见报错速查表

我把自己跑项目过程中以及辅导别人跑项目时收集到的高频问题整理成了一张表：

除了这些，还有一个容易忽略的问题：端口占用。如果本地的8080端口被其他服务占了，后端会启动失败。这时可以直接改application.yml里的server.port配置，换成8081、8888这些端口，前端代理也需要同步调整，前端和后端的端口不一致是新手最容易漏掉的地方。

6.3 实测过程中的性能观察

我把项目在本地跑起来后简单做了下观察，接口响应速度基本都在几十毫秒以内，日常学习使用完全不存在性能瓶颈。商品列表查询走了MySQL索引，返回数据量不大，前端渲染也没有明显卡顿。

不过如果真要考虑上线，有几个点需要注意：当前商品图片是静态资源形式存本地，单机部署没问题，但后续上了云服务器需要把图片目录挂到持久化磁盘或者迁到OSS对象存储；后端默认没有配置Redis缓存，商品详情这类读多写少的接口可以考虑加一层缓存，能显著降低数据库压力。

7. 项目学习路径与二次开发方向

7.1 拿到源码后的推荐阅读顺序

拿到项目后不建议从头到尾按顺序读代码，那样容易在细枝末节上迷失。我建议按下面这条路走：

第一步，看数据库脚本，搞清楚表结构和表间关系。这一步决定了你对整个业务模型的理解深度。

第二步，看后端的配置类和拦截器，理解项目启动时装配了什么组件、拦截了哪些接口。这一步帮你建立对请求链路的整体认知。

第三步，挑一条完整业务链路读，比如"用户浏览商品→加购物车→提交订单"，从Controller入口往下追到Service和Mapper。跟着一条线走通，比零散地看代码更有效。

第四步，打开前端页面，跟着页面操作打断点观察前后端的数据交互。这一步你会把前端组件、API文件和后端接口映射起来，整个项目才算真正吃透。

第五步，找一个功能做微改造。我推荐改造点可以是给商品加一个"是否推荐"的标记字段，连带数据库、后端接口、前端页面全部跑通，这个流程走完，你基本具备了独立开发类似小系统的能力。

7.2 可以扩展的方向建议

这套系统的可扩展性不错，后续想升级可以从以下几个方向入手：

• 接入Redis，把首页轮播图和商品分类缓存化，体验一下缓存穿透和缓存击穿问题的实际处理方式
• 引入支付回调模拟，在订单模块中对接一个支付流程，加深对回调、异步通知、订单状态机这些概念的理解
• 增加库存扣减的并发控制，用乐观锁解决超卖问题，正好补齐当前代码的短板
• 给后台增加数据统计报表，基于订单表做月度销量统计，这里用上MySQL8.0的窗口函数正好合适
• 部署上云，把项目打包部署到一台云服务器上，前端用Nginx托管，后端以jar包方式运行，经历一次完整的线上环境搭建

每个方向的工作量都不算大，但都能让你对当前这个系统有更深的理解。尤其是并发控制和缓存这两个点，面试时被问到的概率非常高，自己动手实践一遍，比背十篇面经都管用。

我个人在实际操作中的体会是：这种完整度适中的项目，最忌讳的就是把它们当"成品代码"跑一遍就完事。跑通只是起点，真正值钱的是跑通之后你对架构的拆解能力。把数据库表关系画一遍、把请求链路追一遍、把某个功能改造一遍，这三件事做完，市面上大多数类似的Java Web项目你都能看得懂、改得动。后面再练一个新的前后端分离项目，速度会快很多。

如果你后续想拿这个项目做二次开发，记住一个原则：先从改配置和加字段开始，不要一上来就动核心的订单逻辑。订单状态流转涉及前端页面、后端接口、数据库状态三端联动，改一处忘了另外两处的同步，排查起来会非常痛苦。先做加法，再做重构，风险会可控得多。