SpringBoot宠物商城系统开发实战：从登录鉴权到订单事务

1. 项目定位：为什么宠物商城是毕设选题的“安全牌”

如果你正在纠结计算机毕设选题，又恰好有点Java基础，我强烈建议你把目光放到这类“宠物用品商城”项目上。原因很简单：它踩中了毕设评审最看重的几个点——业务完整度、技术覆盖面、可演示性和答辩话题性。

先说业务完整度。一个宠物商城系统，表面上看起来就是“商品展示加购物车加下单”，但如果往细了做，它天然包含用户注册登录、商品分类检索、库存管理、购物车合并、订单状态流转、支付对接、后台数据统计等一系列功能。这意味着你的需求分析、数据库设计、前后端联调都有充足的素材可写，论文和答辩PPT不会空洞。

再说技术覆盖面。Java方向的毕设，核心要求就是用SpringBoot把Web开发的全链路走一遍。宠物商城这个题材特别适合展示SpringBoot的核心能力：

• SpringMVC处理RESTful接口
• Spring Data JPA或MyBatis操作数据库
• Spring Security或JWT做登录鉴权
• Redis做缓存和验证码存储
• 事务机制保证下单流程的数据一致性

这些点随便挑两个拿出来深挖，答辩时都能聊上几分钟。

而且，宠物用品商城有个比“图书管理系统”“学生选课系统”更明显的优势：演示效果好。电商类项目无论从页面展示、交互流程还是数据可视化上看，都更容易做出“像样”的感觉。你可以在首页放宠物商品的轮播图、分类瀑布流、购物车角标动画，再在后台放柱状图展示销售额趋势。评委打开系统时看到这些东西，第一印象就赢了。

最后说适配度。这类项目几乎适配所有层次的毕设要求：课程设计、本科毕设、甚至是专科层的项目实训。你可以把它做成单机版的SpringBoot加模板引擎，也可以升级成SpringBoot加Vue的前后端分离架构。工作量完全由你自己掌控，这比那些“必须引入分布式、必须上微服务”的题目灵活太多了。

所以，当你看到“爱宠”“萌宠在线”“宠乐购”这类题目时，本质上是同一个底层逻辑：围绕宠物垂直领域做一套标准电商系统。今天这篇文章，我就把这类项目从技术选型到代码实现、从数据库设计到部署上线的全流程拆给你看，包含我帮学生改过几十套类似项目后的实操经验和踩坑记录，你照着走能省很多时间。

2. 技术选型与整体架构：别一上来就微服务

技术选型直接决定了你后面写代码是顺畅还是处处碰壁。我见过太多学生一开题就说要上SpringCloud、要搞分布式、要前后端分离加Nginx负载均衡。结果是写了三周代码，中间件没配明白，项目差点烂尾。

对于宠物商城这个体量，最合理的方案是：单体SpringBoot应用加一个前端页面方案，数据存储用MySQL，缓存用Redis，鉴权用JWT，文件存储用本地磁盘或MinIO。这套组合足够覆盖毕设评审关心的技术点，又不会把时间耗在无意义的基建上。

2.1 核心依赖清单与理由

我习惯用的SpringBoot版本是2.7.x，原因是稳定、资料多、兼容性强。3.x虽然新，但部分旧教程的配置方式已经失效，毕设阶段没必要和自己过不去。

依赖方面，最基础也最核心的几个是：

有个容易被忽略的点：用MyBatis-Plus而不是原生MyBatis。原因是这类项目里大量接口是单表CRUD，MyBatis-Plus的BaseMapper能帮你把insert、update、selectById这些方法全部内置，一两百个方法你手写是浪费时间。它还带乐观锁插件和分页插件，订单库存更新这种场景正好用得上。

Redis在这类项目里的定位也要想清楚。它主要做三件事：缓存首页热门商品和分类信息、存储图形验证码和短信验证码、辅助购物车缓存。很多人毕设里只把Redis用来存登录状态，其他功能全走数据库，这等于白白浪费了一个答辩加分点。

2.2 单体架构下的模块划分

虽然叫“单体应用”，但代码结构一定不能“一锅炖”。我建议按业务模块分包，而不是按技术层分包。具体来说：

com.petmall ├── controller // 接口层，只做参数接收和结果封装 ├── service // 业务层，核心逻辑都在这里 ├── mapper // 数据访问层，MyBatis-Plus的Mapper接口 ├── entity // 实体类，对应数据库表 ├── dto // 前后端交互的数据传输对象 ├── vo // 视图展示对象 ├── config // 配置类，比如RedisConfig、WebMvcConfig ├── common // 通用类：统一返回结果、异常处理、常量 └── utils // 工具类：JWT工具、文件上传工具等

为什么controller和service要分开？因为你要上事务。订单创建涉及商品表、订单表、订单明细表三张表同时更新，只有把事务边界放在service层，用@Transactional注解才能保证一致性。controller层如果直接操作数据库，事务根本控制不住。

我见过不少学生的项目，Service层就是“把mapper的方法再包一层”，逻辑全写在Controller里。这种代码能跑，但答辩时老师一问你订单流程的数据一致性怎么保证，你就很难自圆其说。模块之间各司其职，才能支撑你在答辩时条理清晰地讲“Controller管接收、Service管业务、Mapper管数据”。

2.3 前端方案：模板引擎还是前后端分离

前端方案有两种路线，各有利弊。

路线一是用Thymeleaf模板引擎，后端渲染页面。适合时间紧、前端基础薄、不想处理跨域的学生。SpringBoot对Thymeleaf支持极好，Controller返回视图名，模板页面内用th:each循环商品列表，效果很直观。缺点是页面跳转是整页刷新，体验不如SPA流畅，而且前后端代码混在一起，答辩时讲“前后端分离”会比较尴尬。

路线二是主流的选择：Vue加ElementUI做单页应用，后端只提供JSON接口。开发时Vue项目占用8080端口，后端占用8081，通过Axios请求接口，用代理解决跨域。这种方案页面美观度高很多，而且你可以在答辩时说“前端使用Vue框架，通过RESTful API与后端交互”——这句话在一半以上的毕设答辩里都是加分项。

我个人的建议是：如果你有一周以上的时间投入，直接选路线二。Vue2加ElementUI的资源最多，遇到问题基本都能搜到答案。Vue3虽然新，但ElementPlus的组件用法有些变化，毕设时间有限，没必要给自己增加变量。

前后端分离还有个隐藏好处：你可以把后端项目单独打包成jar，部署到服务器上，前端用Nginx托管静态资源。这一套流程做下来，你就顺带掌握了项目部署和运维的基本功，答辩时聊“你项目怎么部署的”也能对答如流。

3. 数据库设计：这张表设计好了，项目就成功了一半

数据库表设计是这个项目的灵魂。我拆过很多失败案例，大部分问题都出在表设计上——要么字段冗余，要么表缺关联，要么状态字段没有规划。宠物商城哪怕功能再花哨，核心表也就那几张，但要把关系理清楚。

3.1 核心表结构规划

按模块划分，最少需要6张核心表：

用户表（user）

密码千万不要明文存。用Spring Security自带的BCryptPasswordEncoder加密，长度留够100个字符。这是答辩时必问的安全点，提前准备好答案。

商品表（product）

价格字段用decimal千万不要用float。float有精度丢失，小数点后两位的金额会算出0.009之类的离谱结果。这是最基础的常识，但年年都有学生踩坑。

分类表（category）：id、name、pid、sort。pid是父级分类ID，支持两级分类，比如“宠物食品”下面可以挂“狗粮”“猫粮”“零食”。

购物车表（cart_item）：id、user_id、product_id、quantity、checked。注意cart_item是按用户维度存储的，每个用户看的购物车是他自己的。用Redis实现的话就按user_id做key，但一版设计里存数据库更直观，也方便做购物车持久化。

订单表（orders）：外层的订单主表。

订单状态字段建议用整数枚举，用常量类或者枚举类型管理：0待支付、1待发货、2待收货、3已完成、4已取消、5退款中。这个状态设计要提前想好，后面业务代码全靠它判断流转。

订单明细表（order_item）：id、order_id、product_id、product_name、product_image、price、quantity。为什么要把商品名称和图片冗余到明细表里？因为商品表可能被删或改，但订单的历史快照不能变。用户查看历史订单时，展示的应该是下单那一刻的商品信息。

3.2 订单号生成策略与状态流转

订单号生成是必考的技术点。直接用数据库自增ID做订单号是绝对不行的——单号会被猜到，别人能通过改参数查到你的订单。我的做法是：时间戳加随机数，或者用“yyyyMMddHHmmss加6位流水号”拼。同时要在订单号上建唯一索引，用唯一索引规避并发下的重复提交。

订单状态流转建议画清楚再写代码：待支付可以转待发货，也可以转已取消；已发货只能转已完成。绝对不能出现“待发货直接变成已完成”这种不合法跳转。Service层做状态变更前，先查一次当前状态，合法才允许更新。这也是事务边界和并发控制的体现。

3.3 数据库设计中容易忽略的细节

第一，所有表都建议带上create_time和update_time。这两个字段在排查数据问题时至关重要，也能让表结构显得专业。MyBatis-Plus可以开启自动填充，不需要每次插入都手动set。

第二，请记住外键的度。理论上订单明细表应该和订单表、商品表建立外键关系，但我做过的实际项目一般不加物理外键。原因有三：物理外键在删除数据时容易产生约束冲突；高并发写入时外键检查有性能损耗；毕设场景下逻辑关联已经足够。你在设计文档里可以明确写“应用层维护数据关联”，答辩时这就是你思考过后的取舍。

第三，商品表的detail字段用text，不要用varchar。宠物食品的详情页往往有长图介绍和成分说明，几百字都算短的，varchar(255)根本不够用。

4. 核心业务与接口实现：从登录到下单的完整链路

数据库建好了，接下来就是业务代码。这里我不写全量代码，因为代码量太大，我只把几个最容易出问题、也最值得在答辩中讲的环节拆开说。

4.1 登录注册与JWT鉴权

注册流程的核心是：参数校验、用户名唯一性检查、密码加密、插入用户表。和很多学生项目不同的是，我会加上图形验证码校验——用Redis存储验证码，key是uuid，value是验证码内容，过期时间5分钟。注册时前端提交uuid和验证码，后端取出Redis里的值和用户输入比对，比对成功才继续。

登录接口返回的不只是用户信息，还有一个JWT令牌。JWT的生成逻辑是：用户ID、用户名、过期时间（建议24小时），用秘钥签名。后续所有需要登录的接口，前端都在请求头里带上Authorization: Bearer token，后端通过拦截器解析token，解析通过就把用户信息放入请求上下文。

拦截器配置里有个坑：放行路径要写全。静态资源、登录接口、注册接口、商品查询接口都要排除在拦截范围外。我见过学生把拦截器写到所有路径，结果用户没登录连商品列表都看不了，页面白屏一片，排查半天才发现是拦截器的问题。

4.2 商品查询与首页展示

商品模块的核心接口是三个：分类树查询、分页条件查询、商品详情查询。用MyBatis-Plus的分页插件，连Mapper接口里写个Page 参数，返回IPage ，配合条件构造器QueryWrapper，按分类ID、价格区间、销量排序组合查询，几十行代码就能完成。

首页展示这里很多人忽略了一个点：首页的数据（热门分类、推荐商品、轮播图信息）是读多写少的，每次都查数据库浪费性能。正确做法是启动时加载到Redis缓存，或者首次访问时查库并写入Redis，后续访问直接走缓存。答辩时可以顺带讲一下缓存穿透和缓存雪崩的应对——缓存穿透用空值缓存，缓存雪崩给不同key设置不同过期时间。这一段一讲，老师就知道你不是只会调接口的“代码搬运工”。

4.3 购物车与订单的事务处理

购物车接口比较常规：加购、改数量、删商品、勾选。需要注意合并购物车的场景——用户未登录时加购的临时数据要放在客户端本地存储，登录后把本地和服务器端的购物车合并。不多做展开，因为毕设里接口不难。

重点是订单创建，这是整个项目里事务最集中的地方。流程是：

1. 前端传购物车选中的商品ID列表和收货信息
2. 后端查询商品信息，计算总价
3. 校验库存是否充足，余额是否充足
4. 生成订单号和订单明细快照
5. 扣减库存
6. 清空购物车中已下单的商品
7. 返回订单ID和支付金额

这里有一个经典的并发问题：两个人同时买最后一件商品，都通过了库存校验，最终超卖。解决办法是在扣减库存的SQL里加上库存条件：

UPDATE product SET stock = stock - #{count} WHERE id = #{productId} AND stock >= #{count}

受影响行数为0说明库存不足，直接抛出异常并回滚事务。这种写法比“先查库存再更新”安全得多，而且MyBatis-Plus的乐观锁插件也能实现类似效果。省事起见，直接用这条带条件的update语句最为稳妥，Redis扣减库存一般用Lua脚本保原子性，但对于毕设项目来说，SQL层面的条件更新已经足够。

4.4 支付模块的聪明做法

真正对接支付宝沙箱或微信支付，需要注册商户账号、下载SDK、配置密钥，这套流程走下来至少得两天。我建议毕设项目里做一个“模拟支付”模块：用户点击支付后，前端弹出一个支付确认框，后端直接修改订单状态为已支付，同时记录支付时间。

但这里你要留一个扩展点——定义一个PaymentService接口，模拟支付是其中的一个实现类。答辩时你可以说，真实环境只需要替换成支付宝的SDK实现类即可，接口保持不变。这既是合理的技术取舍，又是代码可扩展性的体现。

4.5 后台管理模块的数据统计

后台管理是很多学生忽视的地方，但它恰恰是加分项。宠物商城的后台至少包含：商品管理（增删改查和上下架）、订单管理（查看订单、发货操作）、分类管理、用户管理，外加一个首页数据面板。

数据面板建议用ECharts画两组图：近7天销售额折线图，分类销售占比饼图。SQL层用聚合查询，按支付时间分组求和：

SELECT DATE_FORMAT(pay_time, '%Y-%m-%d') AS day, SUM(pay_amount) AS total FROM orders WHERE status IN (1, 2, 3) AND pay_time >= DATE_SUB(CURDATE(), INTERVAL 6 DAY) GROUP BY day

这个统计接口前后端配合好，页面视觉效果非常加分。很多毕设管理系统都是纯表格，你多两张动态图表，就已经胜过一多半人了。

5. 实操过程与踩坑记录：把这几个坑填平，你的毕设稳了

说了这么多理论，我把实际动手过程中的典型问题和排查思路整理出来。这些坑基本都是我自己踩过、或者帮学生改项目时反复看到的，提前避开能省下大量时间。

5.1 环境与版本引发的连锁反应

最常见的坑是SpringBoot版本太高导致的配置失效。很多教程基于SpringBoot 2.2写，你用了3.0后，javax.servlet包变成了jakarta.servlet，很多配置类的import路径全部报红。我的建议是：锁死SpringBoot 2.7.x，不要追新。Java环境用JDK 1.8或JDK 11都行，别用JDK 17跑老教程的代码，否则像“--add-opens”这类JVM参数会烦死你。

数据库连接配置里有几个参数值得注意：

spring: datasource: url: jdbc:mysql://localhost:3306/pet_mall?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver

serverTimezone必须加，否则高版本MySQL驱动会报时区错误。characterEncoding=utf8不加的话，中文插入数据库变成问号。

5.2 前后端联调的经典问题

跨域问题是前后端分离必遇到的。开发时前端端口是8080，后端是8081，浏览器会拦截跨域请求。最简单的解决方式是在后端加一个CORS配置类，放行前端地址；或者在前端Vue的devServer里配置proxy代理，把/api开头的请求转发到8081。

拦截器和跨域配置还有一个“先后顺序”坑。SpringBoot中拦截器的注册时机如果晚于CORS配置，会导致请求在拦截器阶段就被跨域问题拦截，连Controller都到不了。配置类里用WebMvcConfigurer明确注册顺序，或者直接用Filter过滤器处理CORS，就能绕开这个坑。

5.3 文件上传与图片显示

宠物商品需要上传图片，很多学生的第一反应是用Base64直接存入数据库，结果库表膨胀迅速，页面加载极慢。正确做法是把图片保存到本地磁盘或云存储，数据库只存URL。本地存储时，要注意配置虚拟路径映射：

spring: web: resources: static-locations: classpath:/static/,file:D:/pet_mall_upload/

这样上传的图片放在D:/pet_mall_upload目录，浏览器直接通过http://localhost:8081/xxx.jpg就能访问。注意控制文件类型和后缀白名单，防止上传恶意文件。

5.4 缓存、事务与并发中的隐性故障

Redis缓存和数据库的一致性是常见隐患。我的做法是：更新商品时先更新数据库，再删除Redis中的对应key。下次查询时缓存缺失，重新加载数据库数据。这个方案叫Cache Aside Pattern，简单够用。千万不要“先删缓存再更新数据库”——中间隔着的短暂时间会有并发读到旧数据然后写回缓存，脏数据就进去了。

事务里还有一个经典坑：Spring的@Transactional默认只对RuntimeException回滚，如果业务里抛的是自定义的checked exception（比如库存不足异常继承自Exception），事务不会回滚。我建议自定义业务异常继承RuntimeException，或者在@Transactional里显式指定rollbackFor。

5.5 Maven构建与打包部署

最后是打包。后端用Maven的package命令打成jar包后，直接在服务器上运行java -jar pet-mall.jar即可。如果你的数据库和Redis都是云服务，一套完整的部署就完成了。我自己帮学生排查过好多次“本地能跑，服务器上404”的情况，十有八九是配置文件里写了localhost，部署时忘了改成云数据库地址。

还有一个冷门但实用的点：jar包里的application.yml外置。部署时把配置文件放在jar包同级目录，SpringBoot会优先读取外部配置，这样改数据库密码不用重新打包。这个细节讲出来，老师会觉得你实践经验很丰富。

前端Vue项目打包后，dist里的静态文件用Nginx托管就行：

server { listen 80; server_name your-domain; root /usr/local/pet_mall/dist; location /api/ { proxy_pass http://localhost:8081/api/; } }

注意Nginx的代理转发，所有/api前缀的请求都被转发到后端的8081端口，前端和后端就这样关联起来了。

5.6 答辩演示的准备工作

做完这些，你的项目基本就完整了。但我再多说一句：答辩前一定要准备演示数据，包括不少于16个商品条目、多张真实感强的宠物图片、几个不同状态的订单。别用“测试1”“测试2”这种名字当商品，页面看起来太假。数据要提前造好，演示时不要现场注册账号浪费时间，直接登录准备好的测试账号。

关于答辩时会问的技术点，我建议你重点准备三个：

• 下单过程中如何保证库存不超卖：讲SQL条件更新
• 用户密码如何安全存储：讲BCrypt加密
• 缓存与数据库的一致性如何保障：讲Cache Aside Pattern

这三个问题命中率极高，提前把逻辑捋顺，把代码翻熟，答辩基本稳了。

我个人做了这么多年的毕设指导，最深的体会是：毕设项目不求惊艳，但求完整和扎实。宠物商城这个题目恰好是一个“怎么打磨都不会跑偏”的载体，它既有电商系统的标准骨架，又有宠物垂直领域的场景亮点。你只要把基础功能做扎实，把数据库设计讲清楚，把事务和并发这几个关键点吃透，就已经是优秀的毕设了。最后再给你一个小建议：代码写完不是终点，花两天时间把每个表的字段、每个接口的流程、每个异常的处理都过一遍，做到能不看代码就画出整个系统的业务流程图。这个能力不仅让你答辩从容，也是你真正踏入Java开发行业的第一课。