大雄行为锻炼做了一个学期的毕设辅导，我手里过的学生项目没有一百也有八十，发现一个很有意思的现象：SpringBoot + Vue 的题目年年都是热门的王炸组合，而宠物商城又是这批选题里最有“眼缘”的一类。原因很简单，这个组合的技术栈主流、业务链路完整，而且视觉效果好——宠物图片本身就有天然的吸引力，页面一撑起来就很好看，答辩演示的时候也容易出效果。如果你正打算拿“SpringBoot + Vue 宠物商城网站管理平台”来做毕设、课设，或者只是单纯想学一下前后端分离项目的完整开发流程，这篇博文应该能帮你省下大量瞎折腾的时间。
我会从项目的整体设计思路说起，再拆到数据库表结构、后端接口、前端页面，最后把联调和部署阶段最容易被绊倒的几个坑也一并交代清楚。内容尽量按“为什么这么做”来讲，而不只是告诉你“这么做”，毕竟答辩的时候老师最爱问的就是这几个为什么。
1. 项目整体定位与模块划分
1.1 为什么宠物商城适合做毕设/课设
先说个很多人没有意识到的点：毕设选题最忌讳的不是“太简单”，而是“业务闭环不完整”。如果你只做一个图书列表增删改查，技术再好也很难撑起一篇论文的叙事；但如果去做电商那种超大平台，一个月的时间光是在订单状态机里转圈就能把你转晕。宠物商城正好卡在中间——它有商品展示、购物车、订单、支付（可选）、后台管理这些电商核心链路，但没有复杂的秒杀、高并发部署、分布式事务这类硬骨头。
这个项目对学生的技术覆盖也非常全：前台消费者能看到商品展示、分类浏览、搜索、加入购物车、下单；后台管理员要维护商品上架下架、库存修改、订单处理、会员管理。你把这些走一遍，等于把前端交互、后端API、数据库设计、状态管理全都串起来了。而且宠物商品的品类天然丰富，猫、狗、水族、爬宠、用品、口粮，随便一拆就是五六个分类，页面层级和筛选逻辑有了真实的复杂度，而不是人为编造的需求。
1.2 双端功能模块拆分
整个项目按照“前台用户端 + 后台管理端”两条线来拆，用户端服务于普通消费者，管理端服务于管理员。
用户端的核心模块我建议做成这几块：
- 注册登录：邮箱/用户名 + 密码，密码用MD5加盐或者BCrypt加密，别明文存。
- 宠物商品浏览：按分类展示商品卡片、搜索关键字、商品详情页看图片与库存。
- 购物车管理：加入、修改数量、删除、批量结算。
- 订单管理：确认订单、选择收货地址、生成订单、查看订单状态（待付款、待发货、待收货、已完成）。
- 个人中心：个人信息修改、我的订单列表。
管理端的核心模块：
- 管理员登录：与用户表共用一张表，用role字段区分，或者单独建一张admin表。
- 商品管理：添加宠物商品、编辑信息、上传图片、上下架、库存调整。
- 订单管理：按状态筛选订单、发货操作、查看订单详情。
- 分类管理：维护宠物品类，分类树不用做得太深，两级就够。
- 轮播图管理：首页轮播图的后台配置。
- 数据概览：简单统计商品数量、订单数量、用户数量，给首页仪表盘用。
这个功能量对课设来说是标准配置，对毕设来说也完全够用。如果你想让论文更有深度，可以挑其中一个模块往细做，比如把订单模块拆出“购物车合并下单 + 库存锁定 + 订单超时取消”的完整事务流程，这就很有东西可写了。
1.3 技术栈选择的底层逻辑
SpringBoot + Vue 这个组合之所以成为主流，有一个常被忽视的原因：它对不同层次的学习者都很友好。
SpringBoot 帮你把 Spring 那套复杂的 XML 配置简化掉了，你只需要遵循“约定优于配置”，写一个启动类，配合注解就能把 Controller、Service、Mapper 串起来。Java 学生学了两年 JavaSE 和数据库基础之后，上手 SpringBoot 是最平滑的路径，而且国内企业招聘对 Java 后端的岗位需求依然很大，学这个不亏。
Vue 则是目前国内最容易找到资料、上手门槛最低的前端框架。Vue 的响应式数据绑定、组件化开发、Vue Router 路由管理、Vuex（或 Pinia）状态管理，这些概念的学习曲线比 React 要缓和很多。学生只要花一周左右把视频过一遍，就可以开始写项目了。
MySQL 不用多说，免费、通用、资料多。毕设阶段没有分布式数据需求，单机数据库完全够用。唯一要注意的就是安装版本和连接驱动的兼容性问题，这个我在后面章节会详细说。
很多人纠结要不要用 Redis、要不要用 ElasticSearch、要不要用微服务。我建议不要，除非你的论文有专门的章节去论证这些技术的引入。否则只会增加系统复杂度和答辩时被追问的风险。把单体架构做扎实，把业务逻辑写清楚，比堆技术名词要可靠得多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据库设计与表结构要点
2.1 核心业务表梳理
数据库设计是整篇论文的地基，答辩时如果老师问“为什么这样设计表结构”，答不上来就会很尴尬。宠物商城的核心表，我建议控制在六到八张左右，不要贪多。
- user表：用户表，存用户ID、用户名、密码、昵称、手机号、头像、角色（0普通用户、1管理员）、创建时间。
- pet_category表：宠物分类表，存分类ID、分类名称、分类图片、排序号。
- pet_info表：宠物商品表，存商品ID、分类ID、商品名称、商品描述、图片URL、价格、库存、销量、上架状态、创建时间。
- cart表：购物车表，存购物车ID、用户ID、商品ID、商品数量、加入时间。
- orders表：订单表，存订单ID、订单编号、用户ID、商品总价、收货人姓名、电话、地址、订单状态、下单时间。
- order_item表：订单明细表，存明细ID、订单ID、商品ID、商品名称快照、单价、数量。这里一个订单对应多个商品明细，所以要拆出来。
另外还可以加一张 comment 表做宠物商品的评价功能，加一张 address 表做收货地址管理。这两张表不是必备的，但如果你论文想要多一个数据维度，它们都很容易做。
2.2 关键字段设计与常见反模式
先讲几个我在带学生时反复强调的字段设计要点。
价格字段一定要用 decimal(10,2)，不要用 float 和 double。这不是洁癖问题，是钱不能出精度误差。float 在累加和比较的时候会产生不可预料的偏差点，这在电商项目里面是不能接受的。学生做毕设时间紧，你可能觉得用什么都无所谓，但是一旦订单总金额对不上，排查起来会非常痛苦。
图片字段永远不要存 base64 编码。我见过有学生把图片转成 base64 字符串直接塞进 MySQL 的 text 字段里，几兆的图片能撑爆数据库连接和传输带宽，页面加载慢到怀疑人生。正确做法是把图片文件传到本地磁盘或者云存储，数据库只存文件的相对路径，页面直接用 URL 去访问。
订单状态用 tinyint 存数字状态码（0待付款、1待发货、2待收货、3已完成、4已取消），在前后端分别用枚举或常量映射成中文显示。不要直接在数据库里存“待付款”这种汉字字符串，后续状态统计和筛选查询会非常别扭。
角色字段建议直接放到 user 表里面，用 is_admin 或 role 标记。很多学生习惯单开一张 admin 表，把普通用户和管理员完全拆开。这个设计在小项目中会让代码多一层判断，但也不是不行。我的个人建议是：共用一个用户表，用 role 区分，这样以后想扩展“店长”“运营”等角色也方便。
2.3 几段核心建表SQL分析
这里我摘两段经常被学生模仿的建表语句来讲，重点不在这段 SQL 本身，而在于它里面积累了几次改表之后的修改痕迹。
sql复制CREATE TABLE `pet_info` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '商品ID',
`category_id` int(11) DEFAULT NULL COMMENT '分类ID',
`name` varchar(100) NOT NULL COMMENT '商品名称',
`subtitle` varchar(200) DEFAULT NULL COMMENT '商品副标题/卖点',
`main_image` varchar(255) DEFAULT NULL COMMENT '主图路径',
`sub_images` text COMME