做前后端分离项目，很多人卡在第一步：网上找的源码要么缺数据库脚本，要么跑起来一堆环境问题，要么前后端联调直接懵圈。这套网上宠物店系统是我最近完整整理过的，SpringBoot+Vue+MyBatis+MySQL四件套，从零到部署的全流程源码都在，我直接把踩过的坑和经验写出来，照着做就能在自己电脑上跑起来。
这套系统适合什么人？正在做毕业设计的在校学生、想练手前后端分离项目的初级开发、以及想快速搭一套电商类模板接业务需求的开发者。宠物店这个业务域很典型——商品展示、购物车、订单、用户管理，一套做完，你对SpringBoot后端接口设计、Vue组件化开发、MyBatis数据持久化、MySQL表结构设计这四个核心技能点基本就全覆盖了。
1. 项目整体设计与技术选型
1.1 为什么是这套技术栈
先说说选型逻辑。网上宠物店系统这个题目，核心诉求是"完整、能跑、看得懂"。SpringBoot负责后端接口，Vue负责前端页面，MyBatis封装数据库操作，MySQL存数据——这是目前国内中小型项目最主流的一套组合，没有之一。
SpringBoot的优势在于约定大于配置，你不需要像传统SSH一样堆一堆XML配置。一个spring-boot-starter-web依赖拉进来，内嵌Tomcat直接跑，这对新手极其友好。Vue的响应式数据绑定让前端页面状态管理变得直观，购物车数量变化、登录态切换这些交互，不用手动操作DOM，v-model一把梭。MyBatis则把SQL和Java方法做映射，复杂查询你能完全控制SQL语句，比JPA那种自动生成的查询在黑盒里调试舒服得多。
有个容易忽略的点：这套组合的岗位需求量在国内依然巨大。技术选型不只看性能上限，更要看学习成本、社区资料丰富度和就业市场匹配度。你搜"Java后端招聘"，十个有八个要求SpringBoot+MyBatis，这本身就是选它的理由。
1.2 前后端分离架构怎么理解
前后端分离的核心，就是前端和后端各跑各的服务，通过HTTP接口通信。前端开发用Vue的devServer，端口8080，后端SpringBoot跑在8081，两边互不干扰。浏览器访问前端页面，前端通过axios发请求到后端接口，后端处理完返回JSON，前端拿到数据渲染页面。
这样做的直接好处有三个。第一，团队可以并行开发，前端调Mock数据，后端用Postman测接口，互不阻塞。第二，后端接口可以给多个端复用，将来要出小程序、App，同一套接口直接对接。第三，部署上前后端可以分开扩容，前端扔Nginx，后端做集群，伸缩性灵活。
但这个架构有个必须处理的痛点——跨域。浏览器的同源策略规定，页面所在域名和请求的接口域名不一致就拦截。所以后端必须配置CorsConfig，允许前端的来源访问。这个我在第五节会详细讲，很多人系统跑不起来，八成是这块没配好。
1.3 项目功能模块拆解
宠物店系统从业务上看，拆成五个核心模块就够了：
- 用户模块：注册、登录、个人信息管理，密码用MD5加盐存储。
- 商品模块：宠物商品的分类展示、搜索、详情查看，分页查询。
- 购物车模块：加入购物车、修改数量、删除商品、合计金额。
- 订单模块：提交订单、订单列表、订单详情、订单状态流转。
- 后台管理模块：管理员登录、商品上下架、订单状态修改。
每个模块都是标准的增删改查加上业务逻辑，但组合起来就是一个完整的电商闭环。做这个项目的过程中，你会自然理解VO（视图对象）、DTO（数据传输对象）的分层设计——前端需要的数据结构和数据库表结构往往不一致，不能直接把Entity丢给前端，需要一个转换层。
2. 数据库设计与核心表结构
2.1 数据库表设计思路
数据库是整系统的地基，表设计好了，后面的代码写起来行云流水；表设计乱了，Service层全是补丁代码。宠物店系统我设计了六张表：
user：用户表，存用户ID、用户名、密码、手机号、头像地址、创建时间。category：商品分类表，比如狗狗、猫咪、水族、宠物用品。pet：宠物商品表，存名称、分类ID、价格、库存、图片URL、描述、上下架状态。cart：购物车表，关联用户ID和宠物ID，加一个数量字段。orders：订单表，存订单号、用户ID、总金额、订单状态、收货信息、创建时间。order_item：订单明细表，一个订单对应多个商品，记录每个商品的快照信息。
核心设计原则是关联外键和状态字段。外键体现数据关系，比如pet表的category_id关联category表；状态字段则用整数表示业务状态，比如订单状态0待付款、1已付款、2已发货、3已完成、4已取消，比用字符串更省空间、查询更快。
一个容易踩的坑：订单明细表必须把商品名称、价格、图片这些信息冗余存储，不能只存商品ID。因为商品可能下架、改价，但历史订单里的快照信息不能跟着变。这是电商系统的通用做法——用空间换历史数据的一致性。
2.2 MySQL 5.7安装与初始化
如果你电脑上还没有MySQL，推荐装5.7版本，别追最新版。为什么？5.7是经过千万级项目验证的稳定版本，网上资料多，遇到问题一搜就有答案。MySQL 8.0虽然性能更好，但密码加密方式变了（caching_sha2_password），老版本的客户端和驱动连不上，新手容易在这里卡半天。
安装步骤大致三步。第一步，去官网下载mysql-5.7.44-winx64.zip解压版，解压到D:\mysql目录。第二步，在目录下新建my.ini配置文件，设置端口3306、字符集utf8mb4、数据目录。第三步，管理员命令行执行mysqld --initialize-insecure初始化，再执行mysqld --install注册系统服务，net start mysql启动。
这里有个细节：--initialize-insecure会生成一个不需要密码的root用户，方便首次登录。登录后立刻执行ALTER USER 'root'@'localhost' IDENTIFIED BY '你的密码';把密码设置好。如果你直接用了--initialize（带安全模式），会自动生成随机密码在日志文件里，找起来麻烦，不如insecure方式省心。
数据库创建用CREATE DATABASE pet_shop DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;，字符集用utf8mb4，因为要存表情符号和特殊文字，utf8mb4才是完整的UTF-8。然后用source命令导入我提供的pet_shop.sql脚本，六张表和数据一次到位。
2.3 MyBatis映射文件编写要点
MyBatis的核心是Mapper接口加XML文件。接口定义方法，XML写SQL语句，两者通过namespace和方法的全限定名绑定。比如PetMapper接口里有List<Pet> selectPage(@Param("offset") int offset, @Param("limit") int limit)，对应的XML里就有：
<select id="selectPage" resultType="com.petshop.entity.Pet"> SELECT * FROM pet WHERE status = 1 ORDER BY create_time DESC LIMIT #{offset}, #{limit} </select>写XML的时候注意三件事。第一，resultType写实体类的全限定名，MyBatis会自动把数据库列名转成驼峰命名的Java属性，前提是配置文件里开了map-underscore-to-camel-case: true。比如数据库的create_time自动映射到Java的createTime，不用写一堆resultMap。第二，动态SQL用<where>、<if>标签做条件拼接，比如搜索功能传了关键词才加WHERE name LIKE条件，不传就查全部，避免字符串拼接SQL的注入风险。第三，批量插入用<foreach>标签，购物车结算时多条明细一次插入，性能比循环单条插入高一个量级。
3. 后端SpringBoot核心代码实现
3.1 项目结构规范与分层思想
后端包结构我按职责分层，标准的三层架构。controller层接收请求参数、调用service、返回结果；service层写业务逻辑、事务控制；mapper层只做数据库操作。另外加entity（实体类）、dto（请求参数封装）、vo（返回视图对象）、config（配置类）、common（通用工具和返回结果封装）。
一个典型请求的流转是这样的：前端GET /api/pet/list?page=1&size=8，先到PetController的list方法，参数绑定到PageQuery对象，然后调用PetService.pageQuery(...)方法。Service层判断分类、计算分页偏移量，调用PetMapper的查询方法，拿到数据后把Pet实体转成PetVO（比如隐藏库存这种敏感字段），包上统一返回对象Result.success(data)返回前端。
统一返回对象是我特别推荐的一个设计。所有接口无论成功失败，返回格式都是{"code": 200, "message": "success", "data": {...}}，前端axios拦截器统一判断code，不用每个接口单独处理错误，代码量直接减少三分之一。格式统一了，前后端联调时沟通成本也低，对着接口文档就知道返回结构长什么样。
3.2 分页查询与条件搜索的实现
宠物列表页必须做分页，不然几十条数据一次全查出来，前端渲染卡顿，接口响应也慢。我这里用的是手写分页，不引入PageHelper插件。为什么？PageHelper虽然方便，但它通过拦截器改写SQL，有时候会和你自己写的复杂SQL冲突，出问题排错成本高。自己写分页就两行SQL的事：一条SELECT COUNT(*)查总数，一条LIMIT查当前页数据，逻辑全在掌控中。
Service层分页方法的逻辑是先算总页数，再查当前页数据，最后把分页信息和数据列表一起封装到PageVO里返回。搜索功能加了一个keyword参数，在Mapper的XML里用<if test="keyword != null and keyword != ''">动态拼接AND pet.name LIKE CONCAT('%', #{keyword}, '%')。用CONCAT而不是直接在SQL里写%#{keyword}%，是因为#{}预编译占位符不接受字符串拼接，%和%写在占位符里面会报错或查不出结果——这是新手最常见的坑。
3.3 购物车与订单的事务处理
购物车和订单是业务逻辑最重的部分，核心难点在事务。用户点击"结算"，后端要同时做三件事：把购物车数据复制到订单明细表、生成订单主表记录、清空购物车。这三步任何一步失败，数据就乱了——比如订单生成了但购物车没清空，用户重复提交订单。所以Service方法上必须加@Transactional注解，让Spring管理事务，任何一个异常都整体回滚。
具体逻辑是：接收一个OrderCreateDTO，里面包含用户ID和购物车ID列表。Service层先根据购物车ID查出所有商品和数量，计算总金额，生成订单号（用时间戳加随机数保证唯一），插入orders表拿到自增ID，再把每个商品快照插入order_item表，最后删除对应的购物车记录。这个过程中还要校验库存——库存不足直接抛异常让事务回滚，前端提示用户库存不够。
订单号生成有个小细节：不要用数据库自增ID当订单号，那样会泄露订单量，而且看起来不专业。我用的方案是yyyyMMddHHmmss加六位随机数，或者直接用UUID去掉横线，30位以内，唯一性有保障。
4. 前端Vue核心页面与前后端联调
4.1 Vue环境搭建与项目初始化
前端用Vue 2加Vue CLI作为基础环境搭建。为什么选Vue 2而不是Vue 3？如果你面向的是大部分网上的教程和毕设要求，Vue 2的生态最稳，Element UI组件库成熟，遇到问题搜一圈全有答案。Vue 3的Composition API更现代，但配套的Element Plus还在持续更新，部分第三方库兼容性不如Vue 2。当然，如果你已经有Vue 3基础，选Vue 3也没有问题，下面的思路完全一样。
环境搭建三个必备工具：Node.js（推荐14.x LTS版本）、npm（Node自带）、Vue CLI脚手架。npm install -g @vue/cli全局安装脚手架后，执行vue create pet-shop-frontend创建项目。创建过程中会让你选配置，我选的是Manually select features，勾选Babel、Router、Vuex，用2.x版本，包管理器用npm。
项目创建后在src目录下，核心是views（页面组件）、components（公共组件）、router（路由配置）、api（接口请求封装）、store（Vuex状态管理）这几个文件夹。组件化开发的关键是让每个页面由多个组件拼装而成，比如商品列表页由SearchBar、PetCard、Pagination三个组件组成，这样每个组件职责单一，后面维护改一个组件不影响其他页面。
有个安装依赖时的坑：npm install经常因为网络问题卡住或报错，建议把npm镜像源切换成国内镜像源，执行npm config set registry https://registry.npmmirror.com，下载速度能快十倍，node-sass这种需要编译的包也不会动不动就下载失败。
4.2 前端路由与页面架构设计
Vue Router管理页面跳转。我配置了以下几个页面路由：/首页跳转到/pet/list（宠物列表页）、/pet/detail/:id（详情页）、/cart（购物车）、/login（登录）、/register（注册）、/order/list（订单列表）、/admin（后台管理）。
路由守卫是前端权限控制的关键。在router/index.js里配置beforeEach全局前置守卫，判断访问的页面是否需要登录。比如访问/cart时，检查localStorage.getItem('token')是否存在，没有token就next('/login')跳登录页，有token就放行。这个逻辑很简单，但它是前端用户感知到的第一道权限关卡。
接口请求统一封装在src/api/request.js里。用axios创建实例，配置基础URL为http://localhost:8081/api，这个地址指向后端服务。再通过axios拦截器统一处理token——请求拦截器把token加到请求头Authorization字段，响应拦截器判断HTTP状态码和业务code码，code为401表示登录过期，跳转登录页并提示用户。
4.3 商品列表页与购物车交互实现
商品列表页是整个系统的门面。页面加载时调用getPetList({ page: 1, size: 8 })接口，拿到数据后渲染成卡片网格。每张卡片显示宠物图片、名称、价格、库存状态，点击"加入购物车"按钮调用addToCart接口。这里有个体验优化的细节：加入成功后用this.$message.success('已加入购物车')给用户即时反馈，避免用户以为按钮没反应反复点击。
购物车页面的核心是响应式数据绑定。数量加减用v-model绑定当前行数据，数量变化时调用后端接口更新数据库。合计金额用Vue的计算属性computed，遍历购物车列表累加每行的price * quantity，任何数据变化时自动重新计算，不需要手动触发更新——这是Vue最有魅力的地方。
前端调接口的坑集中在两个地方。第一，跨域问题，后端没配CORS时浏览器报No 'Access-Control-Allow-Origin' header is present，我在后端加了全局配置类解决。第二，接口参数格式不匹配，比如后端是@RequestParam接收单个参数，前端却在body里传JSON，就会报参数绑定异常。这两个问题应当在联调第一天就解决掉，不然每个页面都报同样的错，心态直接崩。
5. 项目部署与常见问题排查
5.1 前端打包与Nginx部署
开发完成后的前端需要打包部署，npm run build会生成dist目录，里面是压缩优化后的静态文件——HTML、JS、CSS。这里要改一个关键配置：vue.config.js中publicPath从'/'改成'./'，否则打包后JS和CSS的引用路径是绝对路径，部署到服务器子目录时全部404。
生产环境我用Nginx托管静态文件。在nginx.conf里配置一个server块，listen 80，root /usr/share/nginx/html/pet-shop-frontend指向dist目录，index index.html。核心配置是location /api/ { proxy_pass http://127.0.0.1:8081/api/; }——把前端发起的/api请求反向代理到后端的8081端口，这样浏览器的访问都在同一个域名下，跨域问题在部署环境直接消解，不需要后端再配CORS。
还有一个前端路由的Nginx配置：location / { try_files $uri $uri/ /index.html; }。这句配置的作用是当用户直接访问/pet/detail/3这种前端路由地址时，Nginx找不到对应文件，就回退到index.html交给Vue Router处理。不加这行配置，你刷新页面就直接404，这是前后端分离部署最经典的坑。
5.2 SpringBoot后端打包与启动
后端打包用Maven。在pom.xml里配置好spring-boot-maven-plugin，执行mvn clean package -DskipTests，生成可执行jar包。因为这个项目拆了前后端目录，后端在pet-shop-backend目录执行打包命令即可。
启动方式我推荐用脚本而不是直接java -jar。写一个start.sh脚本：
#!/bin/bash nohup java -jar pet-shop-backend.jar \ --server.port=8081 \ --spring.datasource.url="jdbc:mysql://127.0.0.1:3306/pet_shop?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai" \ --spring.datasource.username=root \ --spring.datasource.password=你的密码 \ > logs/pet-shop.log 2>&1 & echo "PetShop started, pid: $!"这里有几个必须注意的点。数据库URL里useSSL=false不能少，本地开发环境MySQL没有配SSL证书，加了这个参数避免连接时SSL握手报错。serverTimezone=Asia/Shanghai指定时区，不然MySQL连接会报时区错误或者时间差八小时。nohup和&的组合让jar包在后台运行，终端关闭也不影响进程。日志重定向到文件，出了问题直接tail -f logs/pet-shop.log看日志排查。
启动成功验证方式：curl http://localhost:8081/api/pet/list?page=1&size=1，返回JSON数据说明后端正常。再访问前端域名，能看到页面且能拉到数据，整个系统就跑通了。
5.3 高频报错与解决方案速查
把我在部署和运行过程中实际踩过的高频问题整理成了一张速查表，都是血泪经验。
端口被占用：启动报Port 8081 was already in use。解决方案是netstat -ano | findstr 8081查PID，taskkill /PID 进程号 /F杀掉，或者改配置文件端口。这个问题在多次启动测试时特别常见，之前的java进程没有完全退出。
数据库连接失败：报Access denied for user 'root'@'localhost'或Communications link failure。前者是密码错误或用户权限问题，重新确认数据库账号密码；后者是MySQL服务没启动或端口不是3306，先net start mysql再检查连接串。
MyBatis绑定异常：报Invalid bound statement (not found)。原因是Mapper接口和XML文件没有正确关联，检查三个地方：接口所在包路径和XML的namespace是否一致、XML文件名是否和接口名相同、application.yml里mapper-locations配置是否指向classpath:mapper/*.xml。
前端白屏：页面空白且控制台无报错。通常是publicPath配置问题或路由模式问题。publicPath改成'./'，Router用hash模式（createWebHashHistory），这两个配置组合在生产环境最稳，不用依赖服务器配置路径转发。
跨域请求被拦截：浏览器控制台报CORS policy错误。开发环境用后端CorsConfig配置allowedOrigins("http://localhost:8080")；生产环境用Nginx反向代理消除跨域。两条路选一条走就行，别两个都开着，偶尔会有冲突。
5.4 两个必须养成的调试习惯
最后分享两个对我来说帮助极大的调试习惯。第一个是打印SQL日志。在application.yml里配置：
mybatis: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl这样每次MyBatis执行SQL，控制台都会打印完整的预处理语句和参数值。前端反馈"数据查不出来"的时候，我第一件事就是看后端日志里SQL到底执行了什么、参数传对了没有。很多问题根本不用断点调试，看SQL日志一眼就定位——比如WHERE id = ?的参数是null，那不是SQL的问题，是前端压根没把ID传过来。
第二个是把接口测试前置。联调之前，先用Postman或Apifox把所有接口跑一遍，确认每个接口的入参出参符合预期。我见过太多项目联调时互相甩锅——前端说后端接口有问题，后端说前端参数传错了。用接口文档工具把契约定死，测试通过再让前端对接，能省掉两个通宵的联调时间。
6. 这套系统的可扩展方向
做完这套宠物店系统，你手里的东西不只是"能跑的项目"，更是一个可以不断加功能的电商骨架。我建议按这三个方向扩展，难度递增但每个都很有价值。
方向一是支付模块。接入微信支付或支付宝沙箱环境，把订单状态流转从"待付款"到"已付款"这段补上。这需要你理解支付回调机制、订单状态机的幂等处理，是电商系统最核心的难点，简历上写这个含金量直接拉满。
方向二是管理后台的权限控制。现在管理员和普通用户共用一套接口，只是靠前端路由隐藏入口。你可以引入Spring Security或Shiro，做基于角色的接口鉴权，区分管理员接口和用户接口，这能让你的系统达到生产级安全标准。
方向三是商品搜索升级。现在用的是MySQL的LIKE模糊查询，数据量上来以后性能会明显下降。可以引入Elasticsearch做商品搜索，用IK分词器支持中文分词搜索，同时把搜索历史、热门搜索这些功能一起做了，就是一套完整的搜索解决方案。
我在实际带人做这类项目时有几个体会。和网上那些完整度参差不齐的教程相比，一个能从数据库脚本一路跑到Nginx部署的项目，价值远高于零散的代码片段。它让你把所有环节走通一遍，之后你在工作中遇到任何一个环节的问题，脑子里都会有一条完整的链路图，这是刷多少道面试题都换不来的。如果你正在跑这套系统，卡在哪个环节了，无论是环境配置、代码报错还是部署问题，把错误日志贴出来，我看到了会抽时间帮你排查。
