SpringBoot+Vue宠物商城项目全解析：从架构到部署-平芜编程栈

先说一句大实话：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, role
t_category	分类表	name, pid（支持二级分类）, sort
t_pet	宠物商品表	name, category_id, breed, age, price, original_price, stock, sales, img, status, health_status, vaccine_info
t_cart	购物车表	user_id, pet_id, quantity, checked
t_address	收货地址表	user_id, receiver_name, receiver_phone, province, city, detail, is_default
t_order	订单主表	order_no, user_id, total_amount, pay_status, order_status, receiver_info, create_time
t_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 环境准备：这些版本搭配直接决定你能不能一次跑通

做毕设或课设最消耗意志力的环节其实不是写代码，而是环境搭建。版本不匹配带来的报错足以劝退一半人。我在这套源码上实测过的环境组合，你可以直接照抄：

组件	建议版本	备注
JDK	1.8 或 8	SpringBoot 2.x + JDK8 是最稳组合
Maven	3.6.x 以上	不要用 3.9 最新版，偶尔有依赖解析问题
Node.js	14.x 或 16.x	对 Vue 2 项目最友好，18+ 也勉强能用
npm	6.x/8.x	推荐用 npm 或 yarn 都行
MySQL	5.7 或 8.0	两者通用，注意连接串
IDEA	2022+	后端开发主工具
VSCode	最新版	前端开发推荐

搭环境的顺序建议是：先按 MySQL → JDK → Maven → IDEA 的顺序装好后端环境，再装 Node.js，最后用 VSCode 或 IDEA 打开前端。

MySQL 这块有一个高频坑：连接串里的时区问题。如果你用的是 MySQL 8.0，连接串不带serverTimezone=Asia/Shanghai会直接报The server time zone value 'ÖÐ¹ú±ê×¼Ê±¼ä' is unrecognized，所以请确保你的application.yml里数据库连接配置与下面类似：

spring: datasource: url: jdbc:mysql://localhost:3306/pet_shop?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/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> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- MyBatis-Plus 核心 --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <!-- MySQL 驱动 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <!-- JWT 鉴权 --> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency> <!-- Lombok 简化实体类 --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> </dependency> </dependencies>

后端启动入口类不需要手写太多东西，@SpringBootApplication+main方法就足够了。真正影响你后续开发体验的是 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 接口里写Page<Pet> 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 --from=builder /app/target/pet-shop.jar /app/app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"]

构建时会用 Maven 先打包出 jar，再放到运行镜像里。这里有个实际经验：第一次构建因为要拉完整的 Maven 依赖，可能会花好几分钟，属于正常现象。

第二步，前端镜像。前端项目先执行npm run build把 dist 打出来，再写个 Dockerfile 配合 nginx：

FROM nginx:alpine COPY dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf

nginx.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.yml：

services: 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?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/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"

这里提醒一个小白必踩的坑：容器内部访问 MySQL，host 不要写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。

解决办法有两种，二是后端全局配置 CORS：

@Configuration 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 前端刷新后页面 404：history 路由模式与静态服务器的爱恨情仇

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。

这个问题的根源往往出在两个地方：

数据库连接串没有加serverTimezone=Asia/Shanghai，导致 JDBC 驱动用了服务器的默认时区（可能是 UTC），和本地东八区差了 8 小时。
后端实体类的LocalDateTime序列化为 JSON 时格式不对。用 Jackson 的话，可以在application.yml里统一配置：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

这样前端拿到的就是格式化好的字符串，对于商城订单这类对时间敏感的场景非常关键。很多同学做订单列表时发现“创建时间对不上”，排查了两三天最后发现就是少了这一行 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看一下重复依赖。