企业官网建设流程全解析

"这套系统真的能跑起来吗？"——这是我拿到一个号称"SpringBoot2+Vue3+MyBatis-Plus+MySQL8.0"的宠物店项目源码时，脑子里冒出的第一个念头。说实话，网上标着"全栈""含文档"的毕业设计源码一抓一大把，但不少是半成品：前端路由乱挂、后端没有事务、数据库脚本根本导入不进去。但这个宠物店系统我断断续续弄了两周，从环境搭建到二次开发，算是对这套技术栈做了一次完整的体检。这篇就唠唠这个系统到底怎么做出来的、每层技术选型的理由、以及我踩过的那些坑，给正准备拿这类项目做毕设或练手的朋友一个参考。

这类网上宠物店系统，本质上是一个典型的"电商+内容管理"双端项目，用户端要能看商品、加购物车、下单支付（模拟）、管理收货地址，管理端要能管宠物分类、上架商品、处理订单、发布公告。无论是做毕业设计还是想拿来做前后端分离的练手项目，它覆盖的知识点都挺全：权限控制、文件上传、订单状态机、CRUD封装、跨域处理，一样不缺。适合谁呢？适合已经掌握Java基础和Vue基础、想用一套完整项目串起全栈技能的人；也适合想快速交出一份"能演示、能答辩、能扩展"毕设的同学。

1. 项目概述与技术选型思路

1.1 这套系统到底做了什么

先把这个宠物店系统的功能边界说清楚。前端拆成两个部分：用户端是面向普通买家的商城页面，包括首页轮播、宠物商品列表、商品详情、购物车、订单确认、模拟支付、订单列表、个人中心；后台管理端面向管理员，包含登录鉴权、商品分类管理、宠物商品CRUD、订单管理（发货/取消/退款）、用户管理、轮播图配置、公告发布。

后端则是标准的分层结构：Controller层负责接收请求和返回统一结果，Service层写业务逻辑，Mapper层通过MyBatis-Plus做数据库操作，实体类与数据库表一一对应。整个项目不是一个简单的"增删改查工具箱"，而是把用户从"浏览商品"到"下单支付"的完整链路走通，再把管理员从"上架商品"到"处理订单"的角色闭环走完。这种"双端+完整交易链路"的设定，正好覆盖了面试官或答辩老师最喜欢问的"你说说订单流程是怎么设计的""权限怎么做的"这类问题。

1.2 为什么是这套技术栈

很多朋友拿到源码第一件事就想换技术栈，我劝你先别急着动。SpringBoot2、Vue3、MyBatis-Plus、MySQL8.0这个组合之所以是当前Java Web毕设和中小型项目的"标准答案"，有几层实际考量。

SpringBoot2自不必说，它对新手最友好的地方是"约定优于配置"。你不用像写Spring MVC老项目那样配置一堆XML，一个启动类加几个注解，内嵌Tomcat直接跑起来。相比SpringBoot3，2.x版本对JDK8的支持最稳定，而大多数学校教学环境还停留在JDK8，这是选2.x而非3.x的最现实理由。

Vue3配合Vite和Element Plus，开发体验和打包速度确实比Vue2的webpack方案舒服。Vue3的组合式API（Composition API）让逻辑复用变得干净，比如购物车状态、用户登录状态都可以通过ref、reactive和computed组织得明明白白，而不是像Vue2那样把一堆逻辑塞进data和methods里。

MyBatis-Plus的价值一句话概括：单表CRUD基本不用写SQL。它内置的BaseMapper帮你把insert、selectById、updateById、deleteById这些操作全部实现好了，你只需要让Mapper接口继承它。对于宠物、商品这类单表操作占据大头、联查只有订单明细等少数场景的项目，用MyBatis-Plus能省掉起码三分之一的工作量。它的分页插件也比手写LIMIT语句方便得多，传一个Page对象进去，返回结果里直接带出总记录数。

MySQL8.0则是数据库的长期选择。8.0的默认字符集utf8mb4对emoji和中文字符支持好，窗口函数、CTE（公共表表达式）这些特性虽然这个项目用不到，但以后扩展报表分析功能时不用换库。

提示：如果你用的IDE是IDEA，JDK版本务必装8或11，SpringBoot2.7.x对JDK17也兼容，但很多依赖细节在JDK8下最不容易出错。别一上来就用JDK21，某些老版本依赖会直接启动失败。

2. 数据库设计与核心表结构

2.1 六大核心表的字段规划

数据库是整个系统的地基。这个宠物店系统的表设计思路，跟一般的电商系统没有本质区别，核心围绕"用户—商品—订单"三条主线展开。我拆开看了一遍建表脚本，一共六张主表，表结构设计得很规矩。

用户表user：主键id自增，username唯一索引，password存的是MD5加密后的密文，另外还有nickname、avatar、phone、address、role字段。这里有个细节我要点出来：role字段用0表示普通用户、1表示管理员，虽然简单直接，但答辩时老师可能会追问"如果以后有多个角色怎么办"，你可以回答后续引入角色表做多对多关联。

宠物分类表category：字段包括id、name、description，跟商品形成一对多关系。分类表看似简单，但它决定了前台页面的导航栏怎么渲染，也决定了后台管理商品时下拉选项的数据来源。

宠物商品表pet：这是整个系统信息量最大的表。字段包括id、category_id（关联分类）、name、breed（品种）、price、stock、image、description、sales（销量）、status（上架/下架）、create_time、update_time。设计上有个值得学习的地方：图片存的是URL路径字符串，不是二进制数据，这样既减轻数据库压力，也方便前端直接用<img>标签渲染。

订单表orders：字段有id、order_no（唯一订单编号）、user_id、total_price、status、address、phone、receiver_name、create_time、pay_time、deliver_time。order_no建议用时间戳加随机数生成，保证并发下不重复。

订单明细表order_item：字段有id、order_id、pet_id、pet_name、price、quantity、subtotal。注意这里冗余存储了pet_name和price，而不是下单后再去查商品表。这是电商系统的经典做法，目的是防止商品改名或改价后，历史订单显示错乱。

购物车表cart：字段有id、user_id、pet_id、quantity。虽然购物车也可以用userId和petId联合唯一索引，但独立表方便以后扩展"选中状态""失效标记"等字段。

除了这六张表，我还建议你补一张banner轮播图表（id、image_url、link_url、sort）和notice公告表（id、content、create_time），这不是画蛇添足。轮播图放动态表里，意味着后台可以随时换图，不用改前端代码；公告表则让首页的公告栏有了数据来源，这两张表插入成本极低，但对系统演示效果提升非常明显。

2.2 订单状态流转与数据一致性的设计细节

订单状态是这个系统里最需要动脑子的一张表。网上很多宠物店系统的通病是把订单状态存成中文描述，比如"待付款""已付款""已发货""已签收""已取消"，前端直接显示这个值，这样不是不行，但扩展性很差。更规范的做法是存数字状态码：0待付款、1已付款、2已发货、3已完成、4已取消，然后在后端定义一个常量类或枚举类统一管理，前端拿到数字后通过映射转为中文。

我建议在这个系统的订单表上额外加一个status字段的注释，把每个数字的含义、允许流转到哪些状态都写清楚。比如"待付款可以取消，已付款可以发货，已发货可以完成或退款"。这块设计好在答辩时会非常加分，因为订单状态机是电商系统的高频考点。

再强调一个数据一致性细节：下单扣库存。用户提交订单时，后端不能只插入一条订单记录就完事，必须把商品库存也扣掉。这套系统的下单逻辑应该是：先校验商品是否上架、库存是否充足 → 扣减库存 → 计算总价 → 生成订单和明细 → 清空购物车对应项。这四步操作要放在同一个事务里，任何一步失败都要回滚。SpringBoot里用@Transactional注解就能解决，但有个坑：@Transactional默认只在RuntimeException下回滚，如果方法里catch了异常不往外抛，事务就不会回滚，极易踩雷。

注意：千万不要把扣库存写成"前端传商品数量，后端直接减"。正确做法是后端从数据库重新读取当前库存，判断足够后再执行UPDATE pet SET stock = stock - #{quantity} WHERE id = #{petId} AND stock >= #{quantity}，这种乐观锁写法在高并发下能防止超卖。虽然毕设项目并发量不高，但这个意识一定要有。

3. 后端核心模块实现与关键配置

3.1 项目结构与基础配置文件

拿到源码第一步，建议先看清楚项目包结构。这套系统的后端采用经典的分层包名：controller、service、mapper、entity、config、common、utils。common包里放统一返回结果类Result和状态码枚举，config放MyBatis-Plus分页插件和跨域配置，utils放JWT工具类。

先看最关键的pom.xml依赖。SpringBoot2.7.x项目的核心依赖是：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.14</version> </parent>

除了Web、MyBatis-Plus、MySQL驱动，还要注意JWT依赖。市面上用来做登录令牌的库主要是jjwt（Java JWT），0.9.1版本的API比较简洁：

<dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency>

application.yml配置文件里，数据库连接是关键。这里有一个最常见的错误：很多人拿到的源码数据库密码是别人的，不改直接用必报Access denied。MySQL8.0的驱动类名和连接URL跟5.x不一样，要注意：

spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/pet_shop?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: root password: 你的密码

serverTimezone=Asia/Shanghai必须加，不加这个参数，MySQL8.0会报时区相关的异常。allowPublicKeyRetrieval=true是给MySQL8.0的caching_sha2_password认证方式用的，少了它可能在连接时报Public Key Retrieval is not allowed。这两个参数是MySQL8.0特有的，也是排查连接问题时要先检查的地方。

3.2 MyBatis-Plus的配置与增强写法

MyBatis-Plus在SpringBoot里的引入很简单，但有几个配置值得注意。分页插件是必配的，不配分页功能会失效：

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

实体类上的注解也很重要。MyBatis-Plus默认把驼峰属性映射为下划线字段，所以createTime会自动映射到create_time。但主键策略必须显式声明：

@TableName("pet") public class Pet { @TableId(type = IdType.AUTO) private Long id; private String name; private Double price; private Integer stock; private Integer status; }

@TableId(type = IdType.AUTO)表示数据库自增主键，如果漏写，MyBatis-Plus默认使用雪花算法生成ID，插入后你会看到主键变成一长串数字。虽然不影响功能，但对这种简单项目来说，AUTO策略更直观。

Service层的写法上，MyBatis-Plus提供了IService接口和ServiceImpl基类。这套系统的宠物Service可以直接继承：

public interface PetService extends IService<Pet> { Page<Pet> getPetPage(int pageNum, int pageSize, Long categoryId, String keyword, Integer status); } @Service public class PetServiceImpl extends ServiceImpl<PetMapper, Pet> implements PetService { @Override public Page<Pet> getPetPage(int pageNum, int pageSize, Long categoryId, String keyword, Integer status) { LambdaQueryWrapper<Pet> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(categoryId != null, Pet::getCategoryId, categoryId) .like(StringUtils.hasText(keyword), Pet::getName, keyword) .eq(status != null, Pet::getStatus, status) .orderByDesc(Pet::getCreateTime); return this.page(new Page<>(pageNum, pageSize), wrapper); } }

这里用LambdaQueryWrapper比字符串写法的QueryWrapper更安全，字段名是类型安全的，编译期就能发现拼写错误，重构字段名时也会自动同步。带条件的eq和like只要第一个参数为false就会忽略这个条件，这种动态SQL能力是MyBatis-Plus相对原始MyBatis的一大优势。

3.3 登录鉴权与JWT Token的实现

登录模块是答辩老师提问的高频区。宠物店系统的权限方案不算复杂：用户登录成功后后端签发一个JWT令牌，前端把令牌存进localStorage，每次请求在Authorization请求头里带上，后端通过拦截器解析令牌中携带的用户ID。

JWT工具类的核心方法就是三个：createToken（生成）、parseToken（解析）、isTokenValid（校验）。生成逻辑：

public String createToken(Long userId, String username, String role) { return Jwts.builder() .setSubject(username) .claim("userId", userId) .claim("role", role) .setExpiration(new Date(System.currentTimeMillis() + 7 * 24 * 3600 * 1000L)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }

注意setExpiration我设置了7天有效期，过期后前端需要重新登录。有的项目做半小时过期，做演示时会频繁掉线，很不友好。7天对于毕设和练手项目刚好。

拦截器方面，系统里的核心逻辑是：定义一个JwtInterceptor实现HandlerInterceptor，在preHandle方法里获取请求头的Authorization，解析Token，把用户信息放入ThreadLocal或request属性中。然后注册拦截器时排除登录接口和商品浏览接口：

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

这样设计的好处是：游客可以看商品、搜分类、看公告，但要加购物车、下单、管理后台，必须有有效令牌。管理端的接口再通过判断role是1来拦截，两行代码就能区分用户权限。

4. 前端Vue3页面搭建与请求封装

4.1 Vue3项目结构与请求层设计

前端这块，如果拿到的是Vite搭建的Vue3项目，目录结构一般长这样：src/api放接口请求，src/views放页面组件，src/router放路由配置，src/store放Pinia状态管理，src/components放通用组件（如商品卡片、分页条）。

我最想重点说的是axios封装。几乎每个从零开始做Vue3项目的人都会踩同样的坑：直接在组件里写axios.get(...)，然后每个页面重复写loading处理、错误处理、Token携带逻辑。这套系统的封装方式值得学习，核心思路是在请求拦截器里统一带Token，在响应拦截器里统一处理业务错误：

import axios from 'axios' import { ElMessage } from 'element-plus' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = token } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } ElMessage.error(error.message || '网络错误') return Promise.reject(error) } ) export default request

这套封装解决了三个问题：Token自动附带、通用错误弹窗、登录过期自动跳转。以后你无论做多少个Vue3项目，这套拦截器逻辑都能直接搬过去用。

4.2 商品列表与购物车流程的实现

用户端的宠物商品列表页是前台的核心。数据流是：onMounted里调用api.getPetList({ pageNum, pageSize, categoryId, keyword })，拿到分页数据后用数组渲染商品卡片。筛选逻辑不需要后端单独写接口，把分类ID和关键字作为查询参数传给后端，后端动态拼SQL。

购物车的实现有两条路：纯前端存储（localStorage）和后端存储（数据库表）。这套系统走的是后端存储路线，因为购物车内容需要跟用户绑定，换设备登录也能看到。购物车接口需要设计的操作有：加入购物车、修改数量、删除单条、清空已选。前端在点击"加入购物车"时，POST请求体里带petId和quantity，后端需要做一次去重逻辑：如果同一个用户的购物车里已存在同一商品，数量累加而不是新增一条记录。用MyBatis-Plus的selectOne查询已有记录，存在则更新数量，不存在则插入，逻辑清晰。

订单确认页有一个值得留意的交互点：展示的商品信息不能直接从购物车列表渲染，而应该请求后端拿到最新的商品单价——因为商品可能已经改价了。这里后端接口返回的数据要包括商品名称、单价、库存、图片，再根据数量算出总价。前端只管展示后端算好的totalPrice，不要在浏览器里做金额计算。

4.3 后台管理页面与Vue Router权限控制

后台管理端的实现，建议用Vue Router的守卫来控制访问权限。宠物店系统的管理界面有商品管理、分类管理、订单管理、用户管理四个大模块。路由配置可以这样写：

{ path: '/admin', component: () => import('@/views/admin/Layout.vue'), meta: { requiresAuth: true, role: 'admin' }, children: [ { path: 'pet', component: () => import('@/views/admin/PetManage.vue') }, { path: 'category', component: () => import('@/views/admin/CategoryManage.vue') }, { path: 'order', component: () => import('@/views/admin/OrderManage.vue') } ] }

前端路由守卫：

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

后台商品管理用Element Plus的el-table展示列表，配合el-dialog做新增和编辑，el-upload组件做图片上传。这里有个很实在的建议：图片上传如果后端没做独立的文件上传接口，最简单方案是存"图片URL"字段，前端用el-upload配合action="/api/upload"调用后端上传接口，后端把图片保存到服务器的static/upload目录，然后返回可访问的URL。

5. 环境搭建与前后端联调实录

5.1 MySQL8.0安装与初始化数据

很多朋友拿到源码第一步就卡在数据库连不上。MySQL8.0的安装虽然比5.7多了几步认证相关配置，但整体不复杂。如果你本机已经装了8.0，只需要创建一个名为pet_shop的数据库，然后执行项目里附带的pet_shop.sql脚本即可：

CREATE DATABASE IF NOT EXISTS pet_shop DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE pet_shop; SOURCE /your/path/pet_shop.sql;

如果你像我一样喜欢在Docker里跑数据库（方便一键启动、随时清理），可以用一条命令搞定：

docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=123456 \ -e MYSQL_DATABASE=pet_shop \ -v /data/mysql:/var/lib/mysql \ mysql:8.0 \ --character-set-server=utf8mb4 \ --collation-server=utf8mb4_general_ci

这里-e MYSQL_DATABASE=pet_shop会在容器首次启动时自动创建数据库，--character-set-server=utf8mb4保证中文不乱码。注意容器端口映射，如果本机3306端口已经被其他MySQL占用，把-p 3306:3306改成-p 3307:3306，同时项目配置里的URL改成jdbc:mysql://localhost:3307/pet_shop。

脚本导入完成后，检查三张关键表有没有数据：pet表商品数据、category表分类数据、user表管理员账号。很多项目文档里会写死一个管理员账号，比如admin/admin123，密码字段是MD5加密的。如果你导入后登录失败，多半是脚本里密码是别人重新加密过的，你需要把自己密码的MD5值更新进去：

UPDATE user SET password = MD5('你自己的密码') WHERE username = 'admin';

5.2 前后端联调与跨域处理

前后端分离项目最容易出的问题就是跨域。前端跑在http://localhost:5173，后端跑在http://localhost:8080，端口不同必然触发跨域。

我在这个项目里推荐两种方案选其一。方案一：前端Vite配置开发代理，在vite.config.js里：

export default defineConfig({ server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } })

这种方案的好处是：前端代码里写的请求URL不用带完整域名，/api/pet/list会被代理转发到后端，浏览器看到的始终是同源的请求，不会报跨域。而且发布上线时，只要后端也支持转发/api路径，代码就不用改。

方案二：后端开启全局CORS配置。SpringBoot中可以在@Configuration类里注册CorsFilter：

@Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); }

两种方案选一个就行，我实际调试时优先用方案一，因为生产环境部署Nginx后还可以继续沿用同一套代理配置。

5.3 前后端启动顺序与验证清单

联调时先启动哪个有讲究。我的习惯是：先启动后端SpringBoot应用，确认控制台没有红色报错，再启动前端Vite服务。前端启动很快，但后端如果端口被占用或数据库连不上，启动再多次也只是加载编译失败。

后端启动成功的标志是看到"Started Application in x.xxx seconds"，前端启动成功的标志是Vite终端出现Local: http://localhost:5173/。打开浏览器访问前端地址，先验证登录功能，再验证商品列表能否渲染，最后走一遍"加入购物车→去结算→模拟支付→后台订单管理"全流程。这样一个完整的验证清单跑通，系统就算真正能用了。

6. 常见问题与排查技巧实录

6.1 从报错到解决的排查实录

我把这两周实际操作里遇到的高频问题整理成了一张排查表，基本涵盖了新手拿到这套系统最可能卡壳的地方：

这里我特别想展开说一下"登录后刷新又跳回登录页"这个问题。它的根源是前端路由守卫里的判断逻辑。很多人登录成功后把user信息存到localStorage，但是刷新后Vuex/Pinia的状态会清空，路由守卫读store.state.user拿到的是null，自然就跳回登录页。正确做法是在路由守卫中优先从localStorage读数据，或者刷新时重新请求/api/user/info接口拉取个人信息。

另一个值得注意的问题是MySQL时区。如果数据库中create_time字段的值跟本地时间差了8个小时，检查两点：MySQL连接URL是否带了serverTimezone=Asia/Shanghai；MySQL服务本身的时区是否为SYSTEM且系统时间是准确的。实战中我遇到过数据库容器时区默认是UTC的情况，最后在Docker run命令里加了-e TZ=Asia/Shanghai解决。

6.2 性能优化与代码规范心得

虽然这套系统定位是学习和毕设用，但代码质量和基础性能优化还是要有的，这决定了你答辩时能不能把"优化意识"讲出来。

第一，数据库查询尽量走MyBatis-Plus的select系列方法，避免在Java内存里做循环过滤。比如商品列表的筛选，条件全部传给LambdaQueryWrapper，让数据库执行过滤，而不是查出全部数据后内存过滤，否则数据量一上来，接口响应时间会急剧恶化。

第二，图片资源不要传原图。el-upload上传的宠物图片如果直接保存，可能一张就是几兆，一个列表页加载十几张图会很卡。实际项目里可以引入thumbnailator这类缩略图工具，在上传时生成压缩图。不过考虑到这是毕设系统，这一步属于加分项，不做不影响核心功能。

第三，统一封装的Result返回类，所有后端接口必须走这个格式：{ code: 200, message: "success", data: ... }。这样前端拦截器才能统一解析。有的源码里一部分接口返回Map、一部分返回String，会让前端极其痛苦，所以拿到项目先检查返回格式的一致性。

第四，代码分层要干净。Controller里只接收参数和返回结果，业务逻辑一律下沉到Service。有些同学在网上找的源码喜欢在Controller里写大段业务，看着能跑，但答辩时老师一问"你的Service层做什么的"就露馅了。

写在最后的一点个人体会

这套宠物店系统源码我前后改了两版，第一版是照葫芦画瓢跑通流程，第二版才真正读懂了为什么每个组件要这样封装、每张表要这样设计、每个拦截器要这样挂。说实话，网上类似的网上宠物店项目源码不少，但代码风格、表设计质量、文档完整程度参差不齐。我挑项目源码的经验是三个字："看交互"——光看标题说"含文档"没用，要看它用户端到管理端的链路是不是闭环，订单状态能不能走通，支付环节是不是真能模拟完成。如果这些核心链路都是通的，后续扩展一个评论功能、收藏功能、统计报表，基本就是在这个骨架上加瓦片的事。希望这篇拆解能帮你少走点弯路。