先说一句大实话SpringBoot Vue 这类商城项目放到 GitHub 上一抓一大把但绝大多数都是“能跑就行”的半成品——代码乱、没注释、表结构随意、前端页面粗制滥造。真正适合拿去当毕设、课设或者静下心来学一遍的反而难找。我最近正好完整过了一遍这套“宠物商城网站管理平台”的源码前后端分离、Java MySQL 打底功能从用户注册登录、商品浏览到下单支付模拟再到后台的商品、订单、用户管理一整套闭环都有。这篇文章我尽量不作假大空的架构吹嘘把我在跑通这套源码过程中觉得最有价值的部分、最容易被卡住的细节以及适合你拿去答辩和学习的技术点一条一条拆给你看。不管你是准备毕设、正在做课设还是想借个项目把 Vue 和 Spring Boot 串起来这篇都能给你省下不少自己摸索的时间。1. 项目整体设计与技术选型思路1.1 为什么是 SpringBoot Vue而不是其他组合老有人问做商城项目为什么选 SpringBoot Vue而不是 SSM JSP或者 Django React我的看法是这套组合是目前国内学习和招聘两端覆盖最均衡的。从学习角度讲SpringBoot 把 SSM 那套繁琐的 XML 配置几乎全干掉了你写一个RestController、一个Service接口就起来了对新手来说“从 0 到能跑通”的心理门槛低很多。Vue 同样如此模板语法、响应式数据比 jQuery 时代直观太多前端写页面就像在描述状态“数据是什么页面就长什么样”不需要你手动操作 DOM链路短。从就业角度讲你去翻 Java 开发岗位的 JD十份里面七八份都写着“熟悉 Spring Boot”“了解 Vue 或 React”。做这个项目相当于提前把岗位描述里的关键词变成了你简历上可验证的项目经验。面试官问你“做过什么”你能讲出用户从注册到下单的完整数据流这比背一百道八股文都有说服力。再说这套源码本身的技术选型里面有几个细节值得注意后端用的是 SpringBoot 2.x MyBatis-Plus而不是原生 MyBatis。MyBatis-Plus 的分页、条件构造器、代码生成器能让你少写大量重复的 mapper XML特别适合开发周期短、一个人全干的毕设项目。前端是 Vue 2 Element UI。你可能会问“怎么不用 Vue 3”这里我说明一下Vue 2 的生态在现阶段仍然非常成熟Element UI 的组件基本是开箱即用表格、表单、弹窗都能直接找参照对课设和毕设来说写起来比 Vue 3 Element Plus 更省心。当然如果你学校要求新技术后面我会提到怎么平滑迁移。数据库用 MySQL 5.7/8.0 都行源码里默认配置兼容性很好只要注意连接串的时区参数别在时间字段上栽跟头。1.2 商城系统功能模块的合理拆分宠物商城听起来是个“商城”但你真正拆开看它的模块结构比普通电商更有辨识度——它有宠物特有的字段品种、年龄、疫苗情况、健康状态这让你的数据库设计和页面展示都有戏可做不至于跟别人的图书商城、手机商城长得一模一样。整套系统的功能模块按用户角色可以分成两条主线前台用户C端模块注册登录邮箱/用户名 密码后端用 JWT 签发 token无状态鉴权商品浏览分类筛选、关键词搜索、分页展示、商品详情购物车加购、改数量、删项、勾选结算订单流程确认订单、填地址、提交订单模拟支付、查看订单状态、取消订单个人中心个人信息修改、收货地址管理后台管理员B端模块仪表盘订单总量、商品总量、用户总量等统计卡片商品管理上架/下架/编辑/删除、库存调整分类管理宠物分类、商品分类的增删改订单管理订单列表、发货操作、查看订单详情用户管理用户列表展示、禁用/启用账号这个功能划分是我比较推荐的结构。它覆盖了一个完整业务闭环用户进来到下单支付但每个功能的实现深度又不至于让你写不出来。你去看很多烂大街的项目常见问题是“后台管理功能一大堆前台却很简陋”这是本末倒置。用户端、管理员端两边均衡才是对的因为答辩老师问的是你“如何实现一次完整的交易流程”而不是“你做了多少个 CRUD 页面”。1.3 数据库设计宠物商城的表结构如何区别于普通商城数据表设计是这类项目最容易被小看的环节但也是最能看出一个人基本功的地方。这套源码我大概梳理了一下核心表有 7 张左右表名用途关键字段t_user用户表username, password, nickname, avatar, phone, rolet_category分类表name, pid支持二级分类, sortt_pet宠物商品表name, category_id, breed, age, price, original_price, stock, sales, img, status, health_status, vaccine_infot_cart购物车表user_id, pet_id, quantity, checkedt_address收货地址表user_id, receiver_name, receiver_phone, province, city, detail, is_defaultt_order订单主表order_no, user_id, total_amount, pay_status, order_status, receiver_info, create_timet_order_item订单明细表order_id, pet_id, pet_name, pet_img, price, quantity几个关键设计点我特别说一下第一商品表和订单明细表之间一定要“快照”字段。什么叫快照你看 t_order_item 里存了 pet_name、price哪怕你以后把商品改名了、价格调了用户的历史订单里显示的还是下单当时的信息。我见过很多新手只存 pet_id然后订单页面靠关联查询去拿商品名和价格这是逻辑 bug 的温床——一旦商品被删整条订单记录就变成乱码了。这套源码在快照设计上是到位的。第二订单状态一定要用状态字段而不是靠时间推导。t_order 表里同时有 pay_status支付状态和 order_status订单状态两者分开管理比单一状态字段扩展性更强。举个例子一笔订单可能处于“待发货”但已经“已支付”也可能处于“待支付”但“已取消”拆开以后状态组合清晰很多。第三宠物表要留出与普通商品区分开的字段。很多同学做商城毕设把狗、猫、仓鼠全部塞进一个简单的product表名字叫得跟卖手机似的。这套源码区分了breed品种、age年龄、health_status健康状态、vaccine_info疫苗信息这四个字段不仅让表结构更像“宠物商城”还能让你的查询、筛选功能比普通商城多出“按品种筛选”“按健康状态筛选”这写在论文里就是一个小小的创新点。2. 核心功能模块解析与实操要点2.1 用户端购物链路从注册到下单的完整数据流任何商城项目最核心的一条线就是“用户能顺利买下一件东西”。这条链路穿过了前端页面、后端接口、数据库三个层面。我按数据流顺序拆解一遍每个环节我都标注了容易出现 bug 的点。第一步注册登录与鉴权。前端的登录页提交表单后端收到用户名密码后先去数据库比对密码是 BCrypt 加密存储的不是明文比对成功之后生成一个 JWT token 返回给前端。前端把 token 存到 localStorage 或者 vuex 里在 axios 的请求拦截器里自动带上Authorization: Bearer token这个请求头。后端做一个拦截器统一校验从 token 里解析出 userId 和 role。这里最容易被同学忽略的一点拦截器要放行登录注册接口和商品浏览接口但购物车、订单等接口必须校验身份。如果不做放行配置你会发现自己访问商品列表都报 401排查半天才发现是拦截器把“不需要登录的接口”也拦了。源码里用WebMvcConfigurer注册拦截器时通过excludePathPatterns(/api/user/login, /api/user/register, /api/pet/list, /api/pet/detail/**, ...)这种方式做白名单非常直观。第二步商品浏览与加入购物车。商品列表接口支持分类筛选和关键词搜索MyBatis-Plus 的QueryWrapper通过.eq()和.like()动态拼接查询条件。购物车表设计为用户级数据每次加购之前先查一下该用户购物车是否已有同款宠物如果已经存在就直接累加数量否则插入新记录。这个“幂等”判断很容易漏漏了会出现同一个用户购物车里两条一模一样的商品记录。第三步提交订单与库存扣减。理论上这一步是商城项目中最容易翻车的地方因为涉及“先查库存、再扣库存、再生成订单”多个动作。如果你们在没有事务保护的情况下依次执行这些 SQL一旦某一步报错库存扣了但订单没建成数据就脏了。这套源码在OrderService的提交订单方法上加了一个Transactional注解让扣库存、生成订单主表记录、生成订单明细、清空已勾选购物车这四个操作变成一个原子操作全部成功才提交事务任何一个环节抛异常就整体回滚。这部分的业务逻辑值得所有做商城毕设的同学好好看先校验商品是否还存在、库存是否足够然后用乐观锁式 SQLUPDATE t_pet SET stock stock - #{quantity}, sales sales #{quantity} WHERE id #{id} AND stock #{quantity}去扣库存通过受影响行数判断是否扣成功。这种写法能有效避免两个人同时下单导致超卖虽然你对毕设并发要求不高但写出来之后在答辩现场你能讲清楚“为什么用这个 SQL 而不是先 SELECT 再 UPDATE”是很加分的。第四步模拟支付与订单状态流转。真实项目对接微信/支付宝支付需要商户号、证书等一堆东西毕设几乎不可能也不必要。这套源码做的是模拟支付跳转到一个“模拟支付页面”点击确认支付后端把订单的 pay_status 从 0 改成 1。这个做法既保证了业务流程完整又不会被支付资质卡住。你在论文里写清楚这是“沙箱支付环境/模拟支付”老师不会质疑的。2.2 后台管理端权限控制和资源管理的关键实现后台管理端是很多同学做商城项目时的“舒适区”——因为无非是增删改查。但二线城市招聘面试时面试官基本都会追问一个点你都做了后台权限那它是怎么控制不同角色能访问的接口的这套源码的角色体系比较简单用户表里有一个role字段1 表示管理员0 表示普通用户。管理员登录后拿到 token前端根据 token 里的角色字段决定要不要渲染后台管理入口后端在拦截器里校验请求路径是否是/admin/**如果是就检查当前用户角色是否是管理员。这里想提醒你一个常见到了有点愚蠢的错误只做前端路由守卫后端接口不做校验。我见过一个同学的后台管理接口只要你手写 URL普通用户也能直接调通。这属于典型的“纸糊权限”。正规做法一定是后端校验为主、前端控制作为体验优化。这套源码里后端的角色校验逻辑写得很清楚你在答辩的时候可以特意提一句“前端隐藏只是视觉逻辑真正的控制是在后端拦截器里做的”这会让老师觉得你的安全意识在线。商品管理模块有一个功能很值得你去看它的实现方式图片上传。宠物商城必然有商品图片而商品图片的上传其实是很多项目的老大难。这套源码用的是本地存储方案——后端接收 MultipartFile重命名后存入服务器本地的一个 upload 目录再把图片的访问路径写回数据库。这种做法够用且简单但你要注意两点重命名时最好用 UUID 原始文件名后缀避免中文文件名和同名覆盖的问题需要配置一个静态资源映射把/upload/**路径映射到本地磁盘目录否则前端img src/upload/xxx.jpg会 404。具体在后端就是类似这样的代码Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { String uploadPath System.getProperty(user.dir) /upload/; registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath); } }这段代码意味着你的项目从哪个目录启动它就会在哪个目录下创建 upload 文件夹。很多同学第一次部署 jar 包后图片全部 404检查了半天才发现是因为换目录启动了。2.3 订单状态机的设计一份让答辩老师点头的订单状态流转图订单模块这类源码很多同学写的版本都是订单有个 status 字段0 代表待付款 1 代表已付款 2 代表已发货 3 代表已完成 4 代表已取消然后各种 if 判断。这种写法的问题是状态很“平”缺少流转概念的约束。这套源码的订单状态管理比较规范的地方在于它将支付状态和订单状态拆开且每个状态流转操作都有独立的方法而不是一坨 if-else。核心流转方向大概是这几个待付款 → 已付款用户模拟支付记录支付时间已付款 → 已发货管理员后台点击发货填写物流单号已发货 → 已完成用户点击确认收货待付款 → 已取消用户主动取消或超时未支付系统自动取消每个动作在后端都有独立的方法比如cancelOrder()、confirmOrder()、deliverOrder()方法内部先做状态校验状态合法才执行更新。为什么要这么做因为状态机设计的最核心价值不是写起来好看而是防止非法的状态跳跃——比如一笔订单待发货状态直接被改成已完成或者已经取消的订单又被支付了这些逻辑错误在 if-else 写法里很难避免但用状态机的思路写每个入口都是一个独立方法状态校验集中、好读、好维护。我个人的建议是你在论文里画一张简单的状态流转图文字版即可不依赖过多图表工具把上面四个方向的触发条件、操作人写清楚。这份图就算只讲三分钟也能向老师证明你不是在“堆页面”。3. 实操过程与关键环节实现3.1 环境准备这些版本搭配直接决定你能不能一次跑通做毕设或课设最消耗意志力的环节其实不是写代码而是环境搭建。版本不匹配带来的报错足以劝退一半人。我在这套源码上实测过的环境组合你可以直接照抄组件建议版本备注JDK1.8 或 8SpringBoot 2.x JDK8 是最稳组合Maven3.6.x 以上不要用 3.9 最新版偶尔有依赖解析问题Node.js14.x 或 16.x对 Vue 2 项目最友好18 也勉强能用npm6.x/8.x推荐用 npm 或 yarn 都行MySQL5.7 或 8.0两者通用注意连接串IDEA2022后端开发主工具VSCode最新版前端开发推荐搭环境的顺序建议是先按 MySQL → JDK → Maven → IDEA 的顺序装好后端环境再装 Node.js最后用 VSCode 或 IDEA 打开前端。MySQL 这块有一个高频坑连接串里的时区问题。如果你用的是 MySQL 8.0连接串不带serverTimezoneAsia/Shanghai会直接报The server time zone value Öйú±ê׼ʱ¼ä is unrecognized所以请确保你的application.yml里数据库连接配置与下面类似spring: datasource: url: jdbc:mysql://localhost:3306/pet_shop?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver如果你用 MySQL 5.7驱动和时区要求会宽松一点但建议也照这个配置写兼容两种数据库。3.2 后端初始化从 application.yml 到第一个查询接口这一步我给你画一条“最小可行路径”——哪怕你的代码是从零开始按这个顺序走也能把后端跑起来。首先确认pom.xml里导入核心依赖这套源码用到的关键依赖如下我做了精简说明dependencies !-- SpringBoot Web 启动器 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- MyBatis-Plus 核心 -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency !-- MySQL 驱动 -- dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency !-- JWT 鉴权 -- dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependency !-- Lombok 简化实体类 -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId /dependency /dependencies后端启动入口类不需要手写太多东西SpringBootApplicationmain方法就足够了。真正影响你后续开发体验的是 MyBatis-Plus 的两个配置分页插件和 SQL 日志。Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }加上PaginationInnerInterceptor之后你的 Mapper 接口里写PagePet page petMapper.selectPage(new Page(current, size), wrapper);就能自动分页开发效率高很多。然后按 Controller → Service → Mapper → Entity 的顺序把“宠物商品列表”这个最简单的接口打通。Controller 层注意统一返回结果格式这套源码用了一个Result类包了一层code、data、message前后端约定好格式后页面判活就容易多了这是非常实用的工程习惯。3.3 前端核心实现Vue 页面怎么优雅对接后端接口前端部分我会重点讲三个核心点axios 封装、路由守卫、页面数据流。axios 要封装成模块而不是在每个组件里直接this.$http.post()裸用。一个典型的封装是创建 axios 实例设置基础路径baseURL加上请求拦截器和响应拦截器。import axios from axios import { Message } from element-ui import router from /router const service axios.create({ baseURL: process.env.VUE_APP_BASE_URL || /api, timeout: 15000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }) service.interceptors.response.use( response { const res response.data // 这里可以统一处理业务异常比如 code ! 200 if (res.code ! 200) { Message.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) } Message.error(error.message || 网络异常) return Promise.reject(error) } ) export default service路由守卫的作用是在前端控制页面访问权限。比如未登录用户不允许访问购物车和个人中心非管理员不允许访问后台管理页面。典型写法是router.beforeEach((to, from, next) { const token localStorage.getItem(token) const role localStorage.getItem(role) if (to.meta.requiresAuth !token) { next(/login) return } if (to.path.startsWith(/admin)) { if (!token || role ! 1) { next(/) return } } next() })页面数据流的实现就更是“套路化”的操作了商品列表页在created()生命周期里调getPetList()拿数据把返回结果赋给组件里的petList数组然后 template 里用v-for渲染。整个过程用 Element UI 的el-table、el-card、el-pagination组件做展示你只要照着官方文档写样式基本不会太丑。前端这一部分想提醒你的是Vue 2 项目中图片路径有讲究。如果你把图片路径直接写死成/upload/xxx.jpg那打包后部署时这个/upload路径必须指向后端服务器上的静态资源目录。开发阶段你可以用 Vite/Webpack 的 devServer 做代理解决但生产环境你得在 nginx 里配置location /upload/ { alias /full/path/to/upload/; }。这个坑在本地开发时看不出来上了服务器就暴露。3.4 前后端部署进 Docker一条编译到上线的完整操作记录很多同学把项目在本地跑起来就算完事了但如果你想简历上多写一条“熟悉 Docker 部署”我建议你把这一节看完。这套源码用 Docker Compose 部署非常方便整体分三步。第一步后端镜像。项目根目录放一个 Dockerfile 内容大致如下FROM maven:3.8-jdk8 AS builder WORKDIR /app COPY pom.xml . RUN mvn dependency:resolve COPY src ./src RUN mvn package -DskipTests FROM openjdk:8-jre-slim WORKDIR /app COPY --frombuilder /app/target/pet-shop.jar /app/app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]构建时会用 Maven 先打包出 jar再放到运行镜像里。这里有个实际经验第一次构建因为要拉完整的 Maven 依赖可能会花好几分钟属于正常现象。第二步前端镜像。前端项目先执行npm run build把 dist 打出来再写个 Dockerfile 配合 nginxFROM nginx:alpine COPY dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.confnginx.conf 里要做两件事一是把/api的请求代理到后端容器端口 8080二是解决 Vue 路由的 history 模式刷新 404 问题server { listen 80; location /api/ { proxy_pass http://backend:8080/api/; } location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } }try_files这一句是关键中的关键。如果缺失你的路由只要不在首页刷新一下就会出现 404。这也是前端部署时最容易踩的隐蔽坑。第三步编排整体。在根目录写一个docker-compose.ymlservices: mysql: image: mysql:5.7 container_name: pet-shop-mysql environment: MYSQL_ROOT_PASSWORD: root MYSQL_DATABASE: pet_shop ports: - 3306:3306 volumes: - mysql_data:/var/lib/mysql backend: build: ./backend container_name: pet-shop-backend depends_on: - mysql environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/pet_shop?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai SPRING_DATASOURCE_USERNAME: root SPRING_DATASOURCE_PASSWORD: root ports: - 8080:8080 frontend: build: ./frontend container_name: pet-shop-frontend depends_on: - backend ports: - 80:80这里提醒一个小白必踩的坑容器内部访问 MySQLhost 不要写localhost要写服务名mysql。因为每个 Docker 容器都有独立的网络命名空间localhost在容器里指向的是容器自身不是宿主机上的数据库。这套配置里SPRING_DATASOURCE_URL用的就是jdbc:mysql://mysql:3306/pet_shop这里的mysql指的就是 compose 里那个 mysql 服务名。所有服务启动后访问http://localhost就能打开前端页面访问http://localhost:8080/api/pet/list能直接看到后端接口返回的 JSON整套链路就算通了。4. 常见问题与排查技巧实录不管是什么商城项目只要你亲手跑一遍、亲手部署一次就一定会遇到几个“资料里查不到、但特别普遍”的问题。我把这套源码运行阶段最常见的几个坑拿出来讲每一类都是实战中踩完总结的。4.1 跨域问题前端请求被拦截怎么办前端在 8080后端在 9090或任一不同端口浏览器会因为同源策略直接拒绝请求。跨域报错的表现是控制台一堆CORS或者Access to XMLHttpRequest at xxx from origin xxx has been blocked by CORS policy。解决办法有两种二是后端全局配置 CORSConfiguration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }一是前端用 Vite/Webpack 的 devServer 代理把/api的请求转发到后端。如果源码里已经配了代理而你仍然遇到跨域报错先确认代理配置中changeOrigin是否为 true再看请求打过去后的响应头是否正常。两条路选一条就行配了后端 CORS 又加前端代理属于画蛇添足有时还会因为重复设置 Cookie 相关 header 导致新的问题。4.2 前端刷新后页面 404history 路由模式与静态服务器的爱恨情仇Vue 默认的vue-router在开发模式下用 hash 路由URL 长这样/#/goods刷新没毛病。但上线后如果你换成history模式URL 变成/goods刷新的时候请求的是服务器上的/goods这个路径而服务器不会 Vite/Webpack 帮你把路由重新定回index.html于是首页以外的路由全部 404。解决方案在 nginx 配置我上面已经写过了核心就是try_files $uri $uri/ /index.html;。如果你用的是 Docker nginx记得把这个配置加进去。如果是后端直接托管前端静态资源那需要看 SpringBoot 有没有配好 forward 规则。这是部署场景最高频的坑没有之一。4.3 时间字段的时区与格式错乱你可能会遇到这些情况数据库里存的create_time和页面显示的时间差了 8 个小时或者前端拿到的create_time是一串数字时间戳而不是2025-06-12 14:30:00。这个问题的根源往往出在两个地方数据库连接串没有加serverTimezoneAsia/Shanghai导致 JDBC 驱动用了服务器的默认时区可能是 UTC和本地东八区差了 8 小时。后端实体类的LocalDateTime序列化为 JSON 时格式不对。用 Jackson 的话可以在application.yml里统一配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8这样前端拿到的就是格式化好的字符串对于商城订单这类对时间敏感的场景非常关键。很多同学做订单列表时发现“创建时间对不上”排查了两三天最后发现就是少了这一行 time-zone 配置。4.4 IDEA / Maven 依赖冲突与版本坑SpringBoot 2.7 / 3.x 的版本差异相当大主要体现在javax包名迁移到jakarta、Spring Security 配置链变化等地方。如果你的源码是基于 SpringBoot 2.x 写的但你本地 Maven 仓库被 IDEA 强制用了 3.x 版本会发现一大堆类找不到、包名对不上。我遇到的典型报错是java.lang.NoClassDefFoundError: javax/servlet/ServletOutputStream或者是Unable to start ServletWebServerApplicationContext。解决办法很简单严格按照项目原有的 pom 版本依赖来跑不要自作主张升级大版本。如果你的毕设指导老师要求用新版 SpringBoot那你要补的安全知识就多了不少不建议在项目初期盲目升版。另外还有mybatis-plus-boot-starter和mybatis-spring-boot-starter同时存在时会报Invalid bound statement (not found)。这种坑属于典型的手动导入依赖时“重复造轮子”排查方式就是在 Maven 视图里检查有没有红色的冲突标记或者mvn dependency:tree看一下重复依赖。5. 写在最后的实操心得这套宠物商城源码我完整看下来最大的感受是它没有炫技但每一样功能都实用——用户端和后台端功能均衡表结构经得起推敲订单流程事务控制到位前后端鉴权思路清晰CORS、时区、静态资源配置也都有意识地做了处理。对于一个毕设或课设来说它的代码量和难度正好处在一个“能讲清楚原理”的红利区间。如果你准备用它来学习我建议你要做三件“给自己加码”的事第一把订单提交流程中的每一步打断点跑一遍。从购物车勾选到库存扣减到订单生成看事务是怎么回滚的试试故意把库存改成 0看会不会被优雅拦截。这是你去答辩现场能够直接演示的“底层原理证明”。第二给商品表加一个“宠物性格标签”之类的字段从数据库到后端接口到前端筛选完整走一遍新增字段的流程。这种“在原项目上二次开发”的经历比直接说“我做了整个项目”更让人信服因为你能讲清楚影响面有多少。第三至少把 Docker 部署跑通一次。现在很多学校的答辩都是让你现场演示而现场最容易翻车的不是功能 bug而是环境差——本机能跑、老师电脑跑不了。Docker 打包之后至少给你一张“哪里都能跑”的护身符。我自己做这个项目的时候踩过最大的坑是关于前端刷新 404 的问题。当时部署完了之后页面能打开但我点了“商品详情→返回→刷新”直接一片白排查了一晚上才发现就是 nginx 少了一行try_files。后来我把这条经验写进了团队的部署 checklist 里再也没有第二次。这套项目本身的技术路线非常值得参考你把它跑通、读透、改出新东西收获的远不只是“一个毕设”——你拥有的是一整套“从前端页面到数据库事务、从开发到部署”的完整思维框架。这比任何单一的技术点都值钱得多。