CarrieYung1. 项目全貌：这套宠物店系统到底做了什么
做后端开发的这几年，我发现一个挺有意思的现象：很多初学者看完教程就手痒，想找个完整的项目来练手，但网上所谓的“宠物店系统”“商城系统”源码，要么是老掉牙的JSP，要么前后端代码混成一团，根本没法拿来学习前后端分离的思想。
这套基于SpringBoot+Vue+MyBatis+MySQL的网上宠物店系统，正是针对这个痛点来的。它是一个典型的前后端分离商城项目，核心业务覆盖了用户注册登录、宠物商品展示、购物车管理、订单创建与支付模拟、后台管理等功能模块。简单说，用户端能逛店挑宠物、加购下单，管理员端能管理宠物上架、处理订单，一套完整的电商闭环麻雀虽小五脏俱全。
项目适合三类人去研究：
一是正在学SpringBoot但苦于没有完整实战项目的学生，这套代码能帮你把MyBatis的Mapper写法、Service层事务、统一返回体这些知识点串起来。二是准备做毕业设计或课程设计的同学，宠物店主题在答辩时挺好讲，且前后端分离结构本身就是一个加分项。三是从未接触过前后端分离部署的开发者，通过部署这套系统，你能搞明白前端打包后如何与后端配合，跨域问题又是怎么回事。
从我的实际体验来说，这套系统最大的价值不在于代码量有多大，而在于它的业务边界清晰、技术栈主流、可以跑通全流程。拆开源码你会发现，用户端、管理端、后端接口是三个独立的模块，这种划分方式本身就是学习前后端分离的最佳范本。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心业务与技术栈选型：为什么这么搭
2.1 业务需求拆解：用户端、管理端到底各管什么
拿到一个项目源码，先别急着跑起来，第一步应该是读代码结构，理清业务边界。这套系统的业务可以拆成两条主线：
用户端（前台）：游客可以浏览宠物列表、查看宠物详情；注册登录后可以加入购物车、修改购物车数量、提交订单。订单支持模拟支付流程，支付完成后能在个人中心看到订单状态流转。
管理端（后台）：管理员登录之后有独立的控制台，支持宠物类目管理（新增、编辑、下架）、宠物信息管理（库存、价格、图片、描述）、订单管理（查看订单详情、修改订单状态），还可以处理用户的收货地址信息。
这两条线共用同一套后端接口，但通过不同的前端页面和权限控制来区分角色。理解了这个双端结构，你在看代码时就不会迷路——前端两个目录分别对应两端页面，后端通过拦截器校验令牌区分访问身份。
2.2 技术栈选型：SpringBoot+MyBatis+Vue为什么是黄金组合
这套系统选择SpringBoot而不是SpringMVC或SSM这种半自动化框架，理由其实很直接：SpringBoot解决了Spring配置地狱的问题，内嵌Tomcat让项目能一键启动，这对新手极其友好。你不需要手动装Tomcat、配置一堆XML，一个main方法就能把后端跑起来。
MyBatis相比JPA，最大的优势是SQL由自己掌控，对于宠物商城这种需要多表关联查询（比如订单详情要联查宠物表、用户表、地址表）的场景，手写SQL更直观。而且国内很多企业的技术栈就是SpringBoot+MyBatis，学了这套东西能直接复用。
前端选择Vue方案而不是传统JQuery多页应用，是因为Vue的组件化开发能很好地把宠物列表、购物车、订单卡片这些元素抽成独立组件，代码复用率高。搭配Vue Router做前端路由，跳转不需要刷新页面，用户体验比传统多页强很多，这也是前后端分离最直观的体验优势。
MySQL自不必多说，轻量、免费、社区活跃，配合MyBatis的逆向工程或通用Mapper，建表后能快速生成基础CRUD代码，开发效率翻倍。整套选型是当前中小型Web应用最主流的标配，没有之一。
3. 数据库设计与建模：先看懂表，后面所有代码都好理解
3.1 核心表结构：宠物、用户、购物车、订单怎么串起来
数据库是整套系统的地基。拆开SQL文件看到表设计时，建议大家不要急着往下看代码，先把表之间的关联关系画出来。这套系统的核心表大概是这几张：
用户表（user）：存储账号、密码（加密后）、昵称、手机号、地址等基础信息。注意密码字段是加密存储的，不能明文存在数据库里。
宠物/商品表（pet或product）：字段包括宠物名称、类目ID、价格、库存、图片URL、上下架状态、描述信息、销量等。这里的图片URL存的是相对路径或绝对路径，前端通过拼接域名来展示图片。
购物车表（cart）：关联用户ID和宠物ID，还有数量字段，联合唯一索引避免同一用户同一商品重复加购。
订单表（orders）：订单编号、用户ID、总金额、订单状态（待支付、已支付、已发货、已完成/已取消）、创建时间等。
订单详情表（order_item）：关联订单ID和宠物ID，记录下单时刻的商品快照（价格、数量、名称）。
这几张表通过外键逻辑关联（一般是逻辑外键，代码层维护），形成了一条完整的电商数据链：用户创建订单，从购物车或直接购买生成订单主表和详情，然后清空购物车，最后在个人中心查看物流状态。
3.2 容易踩坑的表设计细节：状态字段、时间字段与软删除
很多初学者建表时最容易忽略几点，这套系统的表结构里恰好给了参考：
状态字段要预留扩展性。订单状态不要用布尔值（0/1），而是用tinyint存多种状态（比如0待付款、1已付款、2已发货、3已完成、4已取消），后续加状态不需要改表结构。宠物上下架状态也是同理。
时间字段要统一格式。创建时间用datetime且默认值设为CURRENT_TIMESTAMP，更新时间用ON UPDATE CURRENT_TIMESTAMP，这样代码里少写很多时间赋值逻辑。
软删除是个好习惯。商品表通常会加一个is_deleted或status字段来标记是否逻辑删除，而不是物理DELETE。这样即使宠物被下架，历史订单的关联查询也还能有据可查。
关于图片字段，我的经验是：只存一个URL路径，不建议把图片二进制塞进数据库。大量商品图片走文件存储或对象存储，数据库里维护路径即可，否则数据库会非常臃肿，备份和迁移都很痛苦。
3.3 初始化数据的技巧：类型数据、轮播图、管理员账号怎么处理
看这套系统的SQL文件你会发现，除了建表语句，还会附带一些INSERT INTO语句，用于初始化数据。这些初始数据对项目跑通至关重要。
类目数据一般固定写死（比如猫、狗、水族、小宠），通过代码或SQL预置，不用做成后台可动态增删，减少开发量。轮播图配置可以放在数据库里，也可以放在前端配置文件中，这套系统如果图省时间，直接把轮播图写在前端静态文件里也完全OK，不过如果需要后台动态管理，建一张banner表也可以。
管理员账号一般由SQL直接初始化，账号密码用MD5或BCrypt加密后写入。项目初期不需要开放注册管理员的入口，直接在库里跑一条InsertSQL就行。这也是很多源码项目的惯例做法，对一个学习型项目来说，效率优先。
4. 后端开发实录：SpringBoot+MyBatis的接口实现细节
4.1 统一返回体与异常处理：前端不抱怨的基石
打开后端代码，你可能先看到Result或ResponseResult这样一个类，它包装了接口返回的结构，所有Controller方法的返回值基本都长这样：
json复制{
"code": 200,
"message": "操作成功",
"data": { }
}
这个类就是统一返回体，把状态码、提示信息和业务数据打包返回给前端。为什么要这么设计？因为如果没有统一结构，每个接口返回的JSON格式五花八门，前端Axios封装就很难做统一的拦截和错误提示。
配套的还有全局异常处理器（@RestControllerAdvice），用于捕获业务异常、参数校验异常、未知异常，统一封装成上面的结构再返回。这样前端只需要在Axios的响应拦截器里判断code字段即可，不用每个接口单独做错误处理。
我当时跟着源码学习时，特别注意到了Controller层的薄与Service层的厚。Controller里不应该写业务逻辑，它只负责接收参数、调用Service、返回结果。比如订单提交接口，Controller只干三件事：拿到当前登录用户ID、接收订单数据、调用orderService.submitOrder()。真正复杂的库存扣减、金额计算都在Service层。
4.2 登录鉴权与JWT：令牌从发放到校验的全程跟踪
这套系统的用户登录设计采用的是JWT令牌方案，整体流程是：
登录成功后后端生成一个包含用户信息的JWT字符串返回给前端，前端把它存到localStorage或Vuex里。之后每次请求在Axios请求拦截器中，从本地取出令牌，放到Authorization请求头里。后端有个拦截器（HandlerInterceptor），拦截需要登录的接口路径，从请求头取令牌，校验合法性并解析出用户ID，存入ThreadLocal供后续Controller直接使用。
为什么用拦截器而不是在每个Controller方法里手写校验？因为拦截器可以统一处理横切逻辑，比如某些路径放行（/user/login、/pet/list），某些路径需要登录（/cart/**、/order/**），某些路径需要管理员权限（/admin/**）。路径规则的配置，通常就在interceptor.addPathPatterns(...)中一目了然。
有一个细节容易踩坑：前端在请求头里加的是Authentication还是Authorization，字段拼写一定要和后端取值保持一致。我在自己的实践里就吃过亏，前端写成了Authoriztion，后端的request.getHeader("Authorization")取到null，排查了半天才发现是拼写问题。
关于密码加密，这套系统如果用的是MD5，我建议你了解一下BCrypt再做后续优化。MD5虽然简单但容易被彩虹表破解，BCrypt自动加盐、每次加密结果都不同，安全性上高一个档次。对于毕业设计或简历项目，提到BCrypt是一个加分项。
4.3 商品模块：分页查询与条件过滤的实现思路
商品列表页是用户浏览的第一步，后端对应一个宠物分页查询接口。参数通常包括当前页码、每页条数、类目ID、关键字搜索词、排序字段等。MyBatis分页用的是PageHelper或手动LIMIT，具体看源码里用的哪种。
这里有一个重要的SQL优化点：分页查询不应该把符合条件的全部数据加载到内存再截断，而是直接在SQL里通过LIMIT offset, size限制返回条数。同时，为了提升性能，列表查询不要使用SELECT *，只查需要的字段（id、名称、封面图、价格、库存），详情接口再查完整信息。
条件过滤的实现方式是把可选条件动态拼接到SQL里，MyBatis的<if>标签或注解@Select里的<script>都能做。这种动态SQL实现方式虽然简单，但字段多的时候可读性就会下降，所以建议把查询条件封装成一个PetQuery对象，统一传递。
4.4 购物车与订单模块：事务与状态机的关键逻辑
购物车模块的常规操作是加购、修改数量、勾选结算、删除。加购时先查购物车表里有没有相同用户+相同宠物的记录，有则数量加一，没有则新增记录。这里要注意并发场景下可能产生重复数据，通常可以给(user_id, pet_id)加唯一索引，然后使用INSERT ... ON DUPLICATE KEY UPDATE或先查后写的策略，代码逻辑更安全。
订单模块是整个后端的核心，也是事务用得最频繁的地方。创建订单时要处理几件事：
- 根据用户提交的商品ID和数量，查询宠物最新价格。
- 计算总金额（注意运费逻辑是否包含）。
- 扣减库存。
- 新增订单主记录和详情记录。
- 清空购物车对应商品。
这五件事必须在一个数据库事务里完成。SpringBoot的做法就是给Service层方法加上@Transactional注解，一旦任何一步抛出异常，整个事务回滚，不会出现订单建了库存没扣的问题。
对于库存扣减，更优的写法是使用乐观锁或悲观锁来防止超卖，比如执行更新时带上WHERE stock >= #{count}作为条件。这个细节可以当作亮点写在简历项目描述里，面试官一般都会追问。
订单状态字段对应的是一个状态机：待支付不能直接变成已完成，必须先支付、再发货、再完成。这部分逻辑虽然不复杂，但要注意后端接口要限制状态流转的跳跃，不能只依赖前端按钮来控制。
5. 前端开发实录：Vue项目工程化与页面拆解
5.1 前端项目结构：页面、组件、路由怎么划分
这套系统的前端是标准的Vue工程，目录划分大致是：views目录放页面级组件（首页、列表、详情、购物车、结算、个人中心、后台管理），components目录放可复用小组件（宠物卡片、分页器、弹窗、导航栏），router目录配置路由和路由守卫，store目录做全局状态管理，api目录封装针对后端接口的请求方法，utils目录放Axios实例和工具类。
这种分层方式的核心思想就是职责分离。页面负责组装组件、管理页面局部状态；组件接受父级传入的props，通过事件与外界通信；API模块统一管理接口地址，后端地址变更时只改一处即可。
路由守卫实现登录拦截是前端必备技能。全局前置守卫里检查用户是否已登录，如果去的是需要鉴权的页面（比如购物车、结算页）而本地没有令牌，跳转回登录页并携带跳转前地址。登录完成后回跳，体验很流畅。
5.2 Axios封装与跨域：开发环境和生产环境的两种玩法
Axios在项目里通常以插件方式封装，先创建一个实例，设置基础URL（baseURL），开发环境指向http://localhost:8080/api，生产环境指向后端域名或通过Nginx代理。
请求拦截器统一把令牌放头部，响应拦截器统一解析错误码。比如后端返回401（令牌过期）时，前端拦截器自动清除本地登录信息并跳转登录页，不用每个页面写重复逻辑。
跨域问题（CORS）是前后端分离项目必踩的坑。开发环境用Vite或Vue CLI的代理功能解决，在vite.config.js里配置server.proxy，把前端的/api请求代理到后端地址。生产环境则通过Nginx反向代理，配置/api开头的请求转发到后端服务。这样浏览器看到的请求是同源的，不会触发跨域拦截。
关于跨域响应头，后端如果使用了CORS全局配置（@CrossOrigin或CorsFilter），开发时前端代理也要注意避免重复加跨域头导致的冲突，两边配一种方案即可。
5.3 购物车与订单结算的前端状态管理
购物车页面的经典交互问题是：修改数量、勾选某一项、全选、计算总价、结算，这些操作涉及多个数据联动，单靠组件内局部状态会越写越乱，这时用Vuex（或Pinia）统一管理购物车列表和选中状态，体验会好很多。
实际操作中，我在修改数量时会先把本地状态更新，再调用后端接口同步数据库。如果接口失败，回滚本地状态并提示错误。这种“先本地乐观更新，失败再回滚”的手法很适合购物车这类高交互场景。
结算页则相对简单，展示订单信息和用户默认收货地址，点击提交时调用后端创建订单接口。前端在提交按钮上做一个“防止重复提交”的处理，比如提交时把按钮置灰并显示“正在提交”，防止用户多次点击生成多个订单。
5.4 管理后台的实现细节：表格、分页、弹窗三步曲
后台管理页面的核心操作基本围绕CRUD展开，通常由三部分构成：搜索表单区、数据表格区、弹窗编辑区。
搜索表单绑定的查询条件字段，在提交时通过路由query或状态管理传给列表页，触发列表数据的重新请求。表格数据从后端分页接口获得，底部的分页组件改变页码或页大小，重新拉数据。弹窗内打开编辑表单时，如果是新增则表单置空，如果是编辑则回填当前行数据。提交时走新增或更新接口，成功后再刷新表格。
这块虽然不复杂，但需要注意“编辑数据回填”和“重置表单校验”这两个细节。很多新手弹窗关闭后没有重置表单初始值，下次打开时残留上次输入，很影响体验。另外，删除操作要加一个二次确认弹窗，这个细节是后台系统的标配。
6. 从零部署到跑通：本地启动与上线指南
6.1 本地环境准备：JDK、Maven、Node、MySQL的版本选择
部署这套系统前，先把环境准备好。我推荐的版本组合是：JDK 1.8或11（取决于源码pom.xml里的配置）、Maven 3.6以上、Node 16以上、MySQL 5.7或8.0。
源码拿到手，第一步是看application.yml，里面配置了端口、数据库连接、MyBatis日志、上传路径等信息。把数据库密码改成自己本地的密码，URL里的数据库名改成导入时建的库名。
数据库初始化方法是用Navicat或命令行执行SQL脚本，按顺序建库、建表、导初始数据。注意：如果SQL脚本里已经含有CREATE DATABASE语句，直接执行即可；如果只建表不建库，需要手动先建好库再执行。
后端启动方式二选一：用IDEA打开pom.xml导入Maven项目，等待依赖下载完成后运行main方法；或命令行进入项目根目录执行mvn spring-boot:run。启动成功后，在浏览器访问http://localhost:8080，如果配置了Swagger，还可以通过http://localhost:8080/swagger-ui.html查看接口文档。
前端启动类似，进入前端目录执行npm install安装依赖（这一步可能较慢，可以配置镜像源），然后npm run dev启动开发服务器。默认端口一般是5173或8081，浏览器访问前端地址即可看到完整页面。
注意：如果后端端口是8080，前端也是8080会导致冲突，通常前端跑在另一个端口，通过代理访问后端。具体端口查看前端配置文件里的
server.port或vite.config.js设置。
6.2 生产部署的两种方案：传统部署与容器化部署
本地跑通后，生产部署思路主要有两种。
传统方式是后端打Jar包运行：
bash复制mvn clean package -DskipTests
java -jar target/pet-shop.jar --spring.profiles.active=prod
前端执行npm run build，产物在dist目录，把这堆静态文件放到Nginx的html目录，再配置Nginx（nginx.conf）监听80端口，将静态请求直接返回dist目录文件，/api开头的动态请求转发到后端服务的8080端口。
容器化部署则用Docker Compose编排三个容器：MySQL、后端服务、Nginx前端容器。后端镜像基于openjdk:8-jdk-alpine构建，前端镜像基于nginx:alpine构建，MySQL使用官方镜像并挂载数据卷防止数据丢失。这种方式的好处是环境隔离、扩展方便，适合简历里写“使用Docker完成项目容器化部署”。
6.3 上线前必须检查的几件事
部署上线之前，有几件经常被忽略的事：
- 检查后端配置文件是否使用了生产环境的数据库连接，密码是否通过环境变量注入，而不是硬编码在配置文件里。
- 确认JWT密钥在生产环境至少要改成32位以上的随机字符串。
- 检查文件上传路径是否持久化存储，重启服务后上传的图片是否丢失。
- 前端打包时
baseURL是否已指向正式域名或后端网关地址。 - 确认Nginx的
client_max_body_size设置足够大，否则上传宠物图片会报413错误。
7. 常见问题速查与避坑实录
7.1 分类排查：从后端日志到前端Network面板
实际操作中遇到问题，不要瞎猜，按照下面的流程排查：
后端接口报错时，首先看控制台日志堆栈。常见的如数据库连接失败（检查用户名密码）、端口被占用（netstat -ano查看占用进程）、Mapper绑定异常（检查Mapper接口与XML的namespace是否对应）等。MyBatis报Invalid bound statement基本就是接口方法和XML里的ID没对上。
前端页面发请求后报404或500时，打开F12开发者工具切到Network面板，看请求URL、请求方法、请求头和响应体。404的常见原因是后端接口路径与前端不一致（统一加前缀/api的坑）；500的常见原因是后端异常，观察响应体里的异常信息再向后排查。
跨域报错CORS时，看浏览器Console下方的具体错误提示是No 'Access-Control-Allow-Origin' header is present。开发环境建议优先让前端代理解决，生产环境由Nginx解决，后端不要随意开放全局跨域。
7.2 高频问题速查表
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| 前端页面白屏/空白 | 路由配置错误，或打包路径未用相对路径 | 检查Vue Router的base配置，vite.config.js的base设为./ |
| 登录后刷新页面就掉线 | 令牌没有持久化存到localStorage | 登录成功时同时存到localStorage，不要只放内存/状态仓库中 |
| 图片加载不出来 | 图片路径是绝对路径，但域名不对 | 检查上传时存储的URL和前端拼接的域名是否一致 |
| 下单超时或库存不扣 | 事务未生效或SQL条件缺失 | 确认Service方法加了@Transactional，且库存扣减带库存判断 |
| 后端接口能通但前端数据不显示 | 字段名大小写不一致，或日期格式解析失败 | 对比JSON返回字段和前端props绑定字段，统一使用@JsonFormat处理时间 |
| 分页数据错乱 | 参数没传，或SQL里的offset计算错误 | 确认页码和每页大小都传了，计算offset = (pageNum - 1) * pageSize |
7.3 几条独家经验
看完这套源码，你能跑通流程，就已经超过大多数人。但我还是想分享几条自己的心得：
一定亲手敲一遍建表脚本。看代码千遍不如自己写一遍SQL，尤其是在设计订单表和购物车表时，字段约束、索引这些细节只有自己踩过一遍才记得住。
改代码前，记录原始行为。比如调购物车数量前，先看后端SQL的执行日志，再对比修改后的结果。MyBatis开启SQL日志功能很方便（mybatis.configuration.log-impl），这能帮你快速定位SQL拼接错误。
Autowire顺序也能暴露问题。Controller、Service、Mapper三层之间的依赖关系，如果IDEA不报错了也不要大意，实际运行时报NoSuchBeanDefinitionException，多半是ServiceImpl类没加@Service注解，或者Mapper没加@Mapper注解。
学习时我建议你按这个顺序读源码：先读数据库SQL脚本，再读后端Controller层了解有哪些接口，跟着Service层走一遍核心业务，然后回到前端api目录对照接口，最后看页面组件怎么拼装。这个顺序是从数据到接口再到界面的自然路径，比从头到尾逐行读代码高效得多。
8. 写在最后：这套系统让你的技能长在实处
我个人在实际操作中最大的体会是：完整跑通一套前后端分离项目，比刷一百道面试题都更有底气。你可能会在部署过程中遇到Jar包冲突、前端跨域、数据库编码、端口占用等各种问题，但解决这些问题的过程，正是中间件经验、网络基础、系统配置能力的积累过程。
如果你拿到这套源码，最终目标不要只停在“能跑起来”，而是试着去改一改、加一加。比如给系统加一个模糊搜索功能、做一个订单导出Excel、或者把管理后台的图表统计做出来。改动过程中遇到的新问题，远比复现现有代码更锻炼人。
最后再分享一个小技巧：部署后调试时，别急着一上来就改代码。先用curl命令直接测后端接口，确认后端无问题了再处理前端。否则很容易在两端之间来回纠结，浪费大量时间。祝你把这套系统吃透，早日写出自己的完整项目。