SpringBoot+Vue手机商城项目全解析：从数据库设计到部署答辩

搞毕设或者课设的朋友，大概率见过这类项目标题：SpringBoot + Vue 手机商城。说真的，这个组合在 Java 全栈里属于最稳妥、最不容易翻车的一类选题。“欢迪迈手机商城”这个名字本身不关键，关键在于它背后那条完整链路——用户端商城购买、后台管理平台维护、Java 后端提供接口、MySQL 存数据、Vue 负责页面渲染，一条线全通。对于想用一套代码完成毕业设计、课程设计或者系统学习 SpringBoot + Vue 前后端分离开发的人来说，这个项目就是一套非常标准的“全栈教科书”。

我见过太多同学拿着这类源码却不知道怎么讲清楚，或者跑起来之后改一行代码就崩。这篇文章不打算贴大段大段废话，而是从项目拆解、后端业务、前端交互、数据库设计、本地运行到答辩准备，完整过一遍。如果你正准备拿这套项目做毕设或课设，或者刚接触前后端分离想找个真实项目练手，这篇内容应该能帮你少走不少弯路。

先说明一点，文中涉及的具体代码和表结构是以常见商城项目实践为基础的合理归纳，不同版本的源码会有差异，但核心思路和坑点基本通用。

1. 项目全貌与核心选型拆解

1.1 这个商城项目到底包含哪些功能

一个标准的手机商城项目，表面上看着是“卖手机的”，实际拆开看是两类角色、两套界面、一条闭环。

用户端商城：注册登录、首页轮播图、商品分类展示、商品列表带分页和筛选、商品详情页、加入购物车、购物车数量修改和删除、结算下单、收货地址管理、订单列表和订单详情、模拟支付、订单取消和确认收货。

后台管理端：管理员登录、仪表盘统计数据（商品数、订单数、用户数、销售额这些）、商品管理（增删改查、上下架、图片上传）、分类管理、订单管理（查看、发货、处理退款）、用户管理、轮播图管理、公告管理、修改密码这类基础功能。

这两块的业务逻辑是一套后端接口支撑的。对比一下就知道，这项目比“图书管理系统”“学生管理系统”那种单表增删改查要强不少，但又不像电商中台那样复杂到没法收尾，属于正好卡在“有深度、能做完、能讲清”的黄金位置。

1.2 为什么选 SpringBoot + Vue + MySQL，而不是其他方案

这个问题不仅是选型问题，更是答辩必问题。我建议所有用这套项目的人，都要能当场讲出三个理由。

第一，前后端分离是目前企业开发的主流形态。SpringBoot 只写 RESTful 接口，不关心页面长什么样；Vue 只负责页面渲染，通过 Axios 调接口拿数据。两边解耦，职责清晰，这本身就是可以写进简历的“项目亮点”。相比之下，早期 JSP + Servlet 那套 JSP 页面里嵌 Java 代码的方式，早就不是主流了。

第二，这套技术栈的生态和学习成本最均衡。SpringBoot 把 Spring 的配置简化到了极致，约定大于配置，你不需要写一堆 XML；Vue 有中文文档、有 Element-UI 这样现成的组件库，页面做出来颜值在线，对 Java 后端出身、前端基础薄弱的同学非常友好。用一个词总结就是“门槛低、上限够”。

第三，MySQL 配合这套技术栈，资料太丰富了。从建库到调优，从 JDBC 到 MyBatis-Plus，网上能搜到的解决方案一抓一大把。真到了报错排查的时候，你几乎不可能遇到“全世界只有你一个人踩到这个坑”的情况。

1.3 后端目录结构怎么组织的

源码拿到手，先别急着跑，先把目录结构看明白。常见的 SpringBoot 后端分四层，这是标准写法：

com.huanmadimall ├── controller // 接收前端请求，返回 JSON 数据 ├── service // 业务逻辑层，写订单、购物车、登录校验等核心逻辑 ├── mapper // 数据访问层，操作 MySQL 数据库 ├── entity // 实体类，对应数据库表结构 └── config // 配置类，比如跨域配置、拦截器配置、静态资源映射

前端 Vue 工程的结构也有固定套路：

src ├── api // 每个模块的接口请求封装 ├── assets // 静态资源，图片、样式等 ├── components // 公共组件 ├── router // 路由配置 ├── store // 状态管理（Vuex 或 Pinia） ├── views // 页面文件，按模块分文件夹 ├── utils // 工具类，比如 axios 封装 └── App.vue + main.js

把这两棵目录树看懂，你就知道这个项目从头到尾是怎么串起来的。前端页面请求 → axios 封装 → 后端 controller → service 处理业务 → mapper 查数据库 → 数据原路返回 → 前端渲染，整条链路就是毕设答辩时你要讲的第一张图。

2. 后端核心业务实现原理解析

2.1 登录鉴权与用户会话：JWT 是怎么工作的

先说登录这块，因为它是整个项目所有接口的安全入口。现在的商城项目一般不会用传统的 Session 方式，而是用 JWT（JSON Web Token）。

流程是这样的：用户提交用户名密码，后端校验通过后，生成一个加密后的 token 字符串返回给前端。前端把 token 存在 localStorage 里，每次请求都通过请求头带过去。后端在拦截器里校验 token 是否有效，有效就放行，无效就返回 401 让前端跳回登录页。

有个关键细节你要知道：token 里面是包含用户信息的，所以后端不需要在服务器端保存会话状态。这叫做“无状态认证”，分布式部署的时候特别有用。

用一个不太严谨但很好懂的类比：传统 Session 是去游乐园，入口给你发一张贴纸，你玩每个项目前都得把贴纸给工作人员看一眼；JWT 是你直接买了一张印着你姓名和有效期的通票，每个项目的工作人员扫一眼票面信息就知道你是谁、票有没有过期。

代码实现上，JWT 相关的核心配置一般长这样：

// 拦截器中校验 token 的简化逻辑 public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("token"); if (token == null || token.isEmpty()) { response.setStatus(401); return false; } try { Claims claims = JwtUtil.parseToken(token); request.setAttribute("userId", claims.get("userId")); return true; } catch (Exception e) { response.setStatus(401); return false; } }

你要在答辩中讲的点有两个：一是前端如何携带 token，二是后端如何解析 token 并拿到当前用户 ID。尤其是第二个点，后面做购物车、订单的时候全部要用到，属于全项目最核心的上下文信息。

2.2 商品分类与列表查询：多表关联和分页条件筛选

商城商品列表是一个典型的“多条件筛选 + 分页查询”场景。商品和分类的关系是一个分类下面有多个商品，属于一对多关系，一般在商品表里存一个 category_id 字段来关联分类表。

页面上的筛选条件通常有三个：商品名称（模糊查询）、分类 ID（精确匹配）、上架状态（1 上架，0 下架）。如果用了 MyBatis-Plus，代码会简洁很多：

LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.hasText(name), Product::getName, name) .eq(categoryId != null, Product::getCategoryId, categoryId) .eq(Product::getStatus, 1) .orderByDesc(Product::getCreateTime); Page<Product> page = productMapper.selectPage(new Page<>(pageNum, pageSize), wrapper);

这一段代码几乎是模板级的，市面上绝大多数商城项目都是这么写的。你要理解的不是语法本身，而是like方法里面的条件参数：第一个参数是 boolean，只有为 true 时后面的条件才会拼接进 SQL，这样就能避免用户没输入关键词时 SQL 报错或者查出脏数据。

分页这里有个细节值得注意：前端要传给后端两个参数，pageNum（第几页）和 pageSize（每页几条）。后端返回的结果不光要有当前页的数据列表，还要有总条数 total，前端才能算出总页数和“共 xx 条”的展示。上面代码里selectPage返回的 Page 对象里就带了 total，直接包装成统一返回结果即可。

2.3 购物车与订单闭环：状态流转和库存扣减

购物车和订单是商城业务里的重头戏，也是答辩时最容易显深度的地方。

加入购物车这个动作，本质上是对 cart 表的插入或更新操作：如果这个用户已经加过同一件商品，数量加 1；如果没有，新增一条记录。所以判断“是否已存在同款”是第一步。这里要记住，购物车表里必须同时存 user_id 和 product_id，并且最好建一个联合唯一索引，防止同一用户重复插入同一商品的数据。

从购物车结算到订单生成，流程是这样的：

1. 前端把购物车里选中的商品 ID 列表传给后端。
2. 后端逐条查询商品当前价格和库存。
3. 校验库存是否充足，不充足直接返回提示“xx 商品库存不足”。
4. 用事务把购物车记录清空、扣减库存、生成订单主表记录、生成订单明细表记录。

这里必须重点讲事务。订单生成的整个过程，要么全部成功，要么全部失败，不能出现“库存扣了但订单没生成”的情况。SpringBoot 里实现这个特别简单，在 service 方法上加一个@Transactional注解，任何一步抛出异常都会整体回滚。

订单状态是一个典型的状态机，常见的状态定义如下：

每次状态变更时，都要判断当前状态是否允许变更。比如待付款的订单不能直接点“确认收货”，否则逻辑就乱了。这个点你答辩时随口一提，老师就知道你不是只会照着抄代码。

模拟支付就更有意思了。真实项目的支付要对接微信支付宝，但毕设项目里一般做一个模拟支付按钮，逻辑就是：把订单状态从 0 改成 1，顺便写入支付时间。有些项目还会做个“余额支付”或者用随机生成的支付流水号来模拟，展示起来效果更好。

2.4 后台管理端的统计与报表：别只会select *

管理后台的仪表盘页面需要用 ECharts 展示柱状图、折线图之类。很多同学的实现方式是后端写好几个单独的接口，比如“近七天销售额”“各分类商品数量”等。

这里有个很实用的经验：写这类统计接口时，尽量在 SQL 层面完成聚合计算，不要全表查出来到 Java 里再慢慢循环累加。比如查近七天每天的订单销售额，一条 SQL 就能搞定：

SELECT DATE(create_time) AS day, SUM(total_amount) AS amount FROM orders WHERE create_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DATE(create_time) ORDER BY day;

这种写法效率高，而且答辨时你可以顺势讲出“聚合函数 + group by”的 SQL 优化意识，绝对加分。

3. 前端 Vue 工程与页面交互拆解

3.1 用户端页面和路由设计

用户端商城一般是这些页面：首页、商品列表页、商品详情页、购物车页、结算页、订单列表页、订单详情页、登录注册页、个人中心、地址管理页。

路由设计上有两个方向。如果页面之间不通过 URL 传参，直接用路由跳转就行；但商品详情页必须接收商品 ID，所以路由要配置成动态路由，比如/product/detail/:id，跳转时带上 id，页面里通过this.$route.params.id取出来调接口。

首页的布局一般是轮播图 + 分类导航 + 推荐商品。轮播图数据来自 banner 表，后端给一个查询接口，前端用 Element-UI 的 Carousel 轮播组件渲染。商品列表页支持点击分类跳转并自动带上分类参数，这里涉及“路由传参”的写法：

this.$router.push({ path: '/product/list', query: { categoryId: this.categoryId, pageNum: 1 } })

页面里再从this.$route.query.categoryId取参数，拼进接口调用的参数里。这个传参写法区分好 path + query 和 name + params 两种方式，很多新手在这里被搞晕。

3.2 Axios 封装与 token 注入是前端的命脉

前端项目里，所有请求都经过 axios。如果不做统一封装，你会发现在每个页面里重复写请求头、重复处理错误提示，代码又臭又长。成熟项目一定会做封装，而且封装完你必须能讲清楚三个拦截器。

请求拦截器的核心作用就是注入 token：

service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['token'] = token } return config })

响应拦截器有两个职责：统一处理业务错误，统一处理登录失效。

service.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { Message.error(res.msg) return Promise.reject(new Error(res.msg)) } return res }, error => { if (error.response.status === 401) { Message.error('登录状态已过期，请重新登录') localStorage.removeItem('token') router.push('/login') } return Promise.reject(error) } )

这段代码几乎是商城项目的标准答案。你想想，如果没有统一响应拦截器，每个页面都得写一遍“判断 code 不等于 200 就弹错误提示”，项目代码量至少翻一倍。能主动讲出这个设计思路，说明你有工程化意识。

3.3 管理端页面：表格 + 弹窗 + 表单的标准组合

管理端的页面形态高度统一：一个搜索区域 + 一个表格 + 一个新增/编辑弹窗 + 一个删除确认。Element-UI 把这些都封装好了，上手难度极低。

商品管理页是最典型也最复杂的。表格列包含图片、名称、价格、库存、分类、状态、操作按钮；搜索区有商品名称输入框、分类下拉框；新增和编辑共用一个弹窗，里面是商品信息的表单，图片上传要用 Element-UI 的 Upload 组件。

这里有一个重要的区别你要明白：新增和编辑是同一个弹窗，但保存调用的接口不同。新增调 POST 接口，编辑调 PUT 接口，而且编辑时要把当前行的数据回显到表单里。代码上一般用Object.assign(this.form, row)或者直接把row深拷贝给表单对象，避免修改表格数据被联动修改。

管理端的路由守卫也要讲一下：未登录的管理员不能直接访问 /admin 下的页面。做法是在路由配置里加 meta 字段标记哪些页面需要登录，然后在全局前置守卫里判断：

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

这个机制是“前端路由守卫”，配合后端的 JWT 拦截器形成双重防护。答辩时主动说出口，层次感马上就上来了。

3.4 Vue2 和 Vue3 的差异，很容易在这类项目里踩坑

市面上的商城项目源码有两种常见版本：Vue2 + Element-UI + Vuex，以及 Vue3 + Element-Plus + Pinia。用之前先看清版本，很多同学直接照着教程把 Element-UI 的代码复制到 Vue3 项目里，一堆组件不生效，特别崩溃。

Vue2 用选项式 API，数据写在 data 里，方法写在 methods 里，页面逻辑集中但一长就容易散；Vue3 用组合式 API，逻辑按功能抽成一块一块。现在新项目建议直接学 Vue3，但如果你拿到的源码是 Vue2 也没关系，跑通一个项目的架构远比追新版本重要。你只要在答辩时能说清楚自己的项目用的是哪个版本、为什么用这个版本，就已经合格了。

4. 数据库设计与关键表结构

4.1 核心表有哪些，各自的职责是什么

商城项目的数据库一般由这些表组成：

这个设计可以说非常经典。我挑几个重点字段说明一下：

订单主表里有一个address_snapshot字段，很多新手看不懂。它的作用是“地址快照”——用户下单那一刻，把收货地址完整信息存一份到订单里。这样即使用户之后修改了默认地址，这笔订单的发货地址还是下单时的地址。这是电商系统的真实业务场景，不是冗余设计，而是为了业务一致性。

订单明细表为什么要冗余product_name和product_image字段？同样的道理：商品下架、改名、换图片都不能影响历史订单的展示。数据库设计里的“冗余字段”往往是为了性能和业务稳定，这个点讲出来显得很专业。

4.2 建表语句的关键细节

以订单表为例：

CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '订单ID', order_no VARCHAR(32) NOT NULL UNIQUE COMMENT '订单编号', user_id BIGINT NOT NULL COMMENT '用户ID', total_amount DECIMAL(10, 2) NOT NULL COMMENT '订单总金额', status TINYINT NOT NULL DEFAULT 0 COMMENT '订单状态 0待付款 1待发货 2待收货 3已完成 4已取消', address_snapshot VARCHAR(500) COMMENT '收货地址快照', pay_time DATETIME COMMENT '支付时间', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '下单时间', INDEX idx_user_id (user_id), INDEX idx_status (status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表';

注意几个刻意设计：

金额字段一定用DECIMAL(10, 2)，绝对不能用 float 或 double。浮点数在 Java 和 MySQL 里都有精度问题，算钱的时候会出现 0.1 + 0.2 = 0.30000000000000004 这种离谱结果。所有涉及金额的计算，Java 端也要用BigDecimal。

order_no字段加 UNIQUE 约束，业务层生成订单号时一般用时间戳加随机数。为什么不用自增主键当订单号？因为订单号会暴露在用户面前和支付流水里，自增 ID 太好猜了，也容易被爬虫遍历。

索引设计是另一个得分点。user_id加索引是因为“查我的订单”是最常见的查询；status加索引是因为管理后台要按状态筛选订单。你不需要懂太深的索引原理，只要会解释“我根据查询频率给常用字段建了索引”，答辩老师就清楚你有数据库设计意识了。

4.3 表关系梳理：站在数据库视角看整个商城

分类和商品是一对多，商品和订单是多对多，通过 order_item 中间表关联。用户和订单是一对多，用户和地址是一对多，用户和购物车项是一对多。

把这些关系画成一张脑图，你的项目逻辑就闭环了。很多同学答辩时被问到“你这个项目有什么亮点”，其实不需要说什么高并发、分布式，能把表关系和业务闭环讲清楚，比什么都强。

5. 本地跑起来与部署上线实操

5.1 环境版本推荐与安装清单

跑这个项目之前，先把环境备好。我推荐的版本组合是：

• JDK 1.8 或 11（SpringBoot 2.x 用 JDK8 最稳，3.x 需要 JDK17，先用 2.x 就不折腾）
• MySQL 5.7 或 8.0
• Maven 3.6+
• Node.js 14 以上（Vue2 项目用 14/16 都行，Vue3 + Vite 建议 16+）
• 开发工具：后端用 IDEA，前端用 VS Code 或 WebStorm，数据库可视化用 Navicat 或 DataGrip

这里特别提醒：环境的“大版本”一定要匹配。SpringBoot 3.x 对应 JDK17，MyBatis-Plus 3.5.x 对应 SpringBoot2.x，版本混了基本上跑不起来，而且报错信息新手根本看不懂。

5.2 完整启动步骤，照着做就行

第一步，创建数据库。打开 Navicat，新建一个数据库，字符集选 utf8mb4，然后导入项目里的 SQL 文件。SQL 文件一般叫mall.sql或者hotdj.sql，通常放在项目根目录或者 db 文件夹里。

导入成功后检查一下表数量，如果只有四五张表，可能是个阉割版项目；正常商城项目至少十张表以上。

第二步，配置后端。打开application.yml或application.properties，修改数据库连接信息：

spring: datasource: url: jdbc:mysql://localhost:3306/huandimaimall?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 你自己的密码

注意 url 里的serverTimezone=Asia/Shanghai不能丢。MySQL 8 的连接驱动要求显式指定时区，不然会报时区错误。

第三步，启动后端。用 IDEA 打开后端工程，等 Maven 把依赖下载完，找到启动类，右键运行。看到 Spring Boot 启动成功的日志，说明后端已经好了。

第四步，启动前端。在命令行进入前端工程目录，先执行npm install装依赖，再执行npm run serve（Vue Cli 项目）或npm run dev（Vite 项目），启动成功后浏览器访问 localhost 对应的端口就行。

这里最常出的问题是npm install特别慢或者报错。解决办法是切换 npm 镜像源：

npm config set registry https://registry.npmmirror.com

第五步，联调。前端页面能打开、能调接口、能登录、能下单，项目就跑通了。

5.3 最常见的启动报错和排查思路

端口被占用是最常见的。后端默认 8080，前端默认 8081 或 5173，如果启动时提示端口被占用，要么改端口，要么杀掉占用进程。

数据库连不上的报错长这样：Access denied for user 'root'@'localhost'或者Communications link failure。前者是用户名密码配错了，后者是 MySQL 没启动或者 url 配错了。

前端调不到接口，老是报 404 或跨域。跨域报错的经典标志是浏览器控制台出现CORS policy或者blocked by CORS。解决思路有两种：后端加跨域配置类，或者前端在开发环境配 devServer 的 proxy 代理。后者的写法如下：

devServer: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

为什么更推荐用代理？因为 npm run serve 起来的前端服务器和后端不是同一个端口，浏览器直接跨域；代理的意思是把 /api 开头的请求转发给 8080，浏览器看的是同源请求，跨域问题自然消失。生产环境部署时，Nginx 也承担同样的代理职责。

5.4 部署到服务器，别再用本地 localhost 演示

毕设一般完成到“本地能跑”就给过了，但如果你想把项目真正部署到服务器，或者演示的时候不想出现“在我电脑上能跑”这种尴尬名场面，建议按下面的方式部署。

后端打包：在 IDEA 里执行 Maven 的 package，生成 jar 包，扔到服务器上执行：

java -jar mall.jar --spring.profiles.active=prod

前端打包：执行npm run build，生成 dist 目录，里面是纯静态文件。把 dist 目录放到 Nginx 的 html 目录下，然后配置 Nginx：

server { listen 80; server_name 你的域名或服务器IP; location / { root /usr/share/nginx/html/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

这里面的try_files $uri $uri/ /index.html;特别加粗划重点。因为 Vue 用 history 模式路由时，浏览器访问/product/list这类地址，服务器上根本没有这个物理路径，不配置 try_files 的话一刷新就 404。这个坑我见过无数人踩。

关于项目里的 /api 前缀，我要单独说一句。很多源码里的接口路径本来就带 /api，比如http://localhost:8080/api/product/list，此时前端代理配置里 target 直接写代码里就行，不用再拼一次 /api。但也有一些项目前端请求是/api开头而后端接口不带，情况不一样，你拿到的源码怎么写的就按它的来。能搞清楚这个映射关系，Nginx 配置就不会错。

5.5 快速二次开发：给项目加一个新功能模块的完整步骤

学会跑通项目只是第一步，真正有含金量的是会改项目。我建议你在原项目里加一个新模块练手，流程固定为五步：

第一步，数据库建表，比如“商品评论表”。第二步，写实体类 entity，字段和表对齐。第三步，写 mapper 接口，继承 BaseMapper，复杂查询就写 SQL。第四步，写 service 和 controller，提供/api/review/list这类接口。第五步，前端新建 api 文件、views 页面，加路由和菜单，调通接口。

如果完整走完这五步，比背十篇技术博客都有用。很多同学毕设答辩被问“项目是不是你自己做的”，最直接的证明方式，就是言之有物地说清楚某个模块怎么加的、遇到什么问题、怎么解决的。

6. 答辩前必须想清的 12 个问题和常见坑实录

6.1 高频提问与回答思路

1. “为什么选这套技术栈？”——企业主流、前后端分离、学习成本适中、资料丰富，三点足够。
2. “订单和商品的关系怎么设计的？”——多对多，通过订单明细表解耦，明细里冗余商品快照。
3. “购物车如何实现？”——每个用户一张购物车记录，同商品数量累加，结算时校验库存。
4. “支付是怎么做的？”——模拟支付，把订单状态流转到已支付，同时写入支付时间。
5. “如果用户同时买同一件商品，库存扣多了怎么办？”——用 MySQL 行锁或者乐观锁，UPDATE product SET stock = stock - 1 WHERE id = ? AND stock > 0，更新影响行数为 0 说明库存不足。
6. “为什么不直接用 Session 而要引入 JWT？”——无状态、适合前后端分离和分布式部署。
7. “商品搜索是怎么做的？”——LIKE 模糊查询，如果数据量大可以引入全文检索或 Redis。
8. “权限控制怎么做的？”——前端路由守卫 + 后端 JWT 拦截器，双保险。
9. “图片上传怎么处理？”——本地上传，存到服务器磁盘，通过静态资源映射对外访问。
10. “订单的金额用什么类型？”——BigDecimal 和 DECIMAL，避免浮点精度问题。
11. “JWT 过期了怎么办？”——前端响应拦截器捕获 401，清 token 跳登录页。
12. “项目有没有考虑安全问题？”——密码用了 MD5 加盐或 BCrypt，登录接口做了参数校验，JWT 校验了签名。

回答这些问题时，关键在于不要背稿，而要把思路讲出来。你可以先一句结论再展开一句原因，控制在三十秒内说完是最好的。

6.2 实战开发中的高频坑，我一条条给你列出来

图片上传成功但访问 404。原因通常是后端没配置静态资源映射。SpringBoot 默认只映射 static 目录，如果你把图片传到了项目的 upload 文件夹里，需要加一个配置，把磁盘路径映射成 URL：

@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:" + uploadPath + "/"); }

MySQL 5.7 导入 SQL 文件报错Invalid default value for 'create_time'。这是因为系统是 MySQL 8 默认的 sql_mode 和旧项目 SQL 冲突，执行SET sql_mode = '';后重新导入即可。这个报错很隐性，中文搜索半年可能都搜不到标准答案。

前端页面改了没效果。常见原因是浏览器缓存。使用无痕模式或者 Ctrl + F5 强制刷新。Vue CLI 项目热更新偶尔也会失效，重启 npm run serve 一般能解决。

登录后刷新页面，用户信息丢失。很多项目的用户信息存在 Vuex 里，一刷新就清空了。解决办法是把基础用户信息存到 localStorage，初始化时判断有没有 token 和用户信息再赋值。

前端能跑但有接口 404。看一下前端请求路径和后端 Controller 的 RequestMapping 是否完全一致。这种问题多数是/api前缀不一致导致的，前后端各写各的，没人对。

6.3 想拿高分，可以往这几个方向加亮点

原项目跑通只是及格线。时间充裕的话，我建议按性价比从高到低加这些增强：

Redis 缓存：把轮播图、商品分类、热门商品这种高频读取且不常变的数据存到 Redis，设置过期时间。加这个功能只需要引入依赖、改 service 几行代码，但答辩时能讲出“缓存穿透和缓存一致性”的概念，档次完全不同。

Spring Security：如果原项目用的拦截器 + JWT 做认证，可以升级为 Spring Security + JWT。虽然学习曲线陡了一点，但能把“认证授权框架”写在简历上，含金量不是一个级别。

接口参数校验：给 Controller 的参数加上 Valid 注解，统一处理校验异常。这个小改动能展示你对代码规范的重视。

Docker 部署：写一个 docker-compose 把 MySQL、后端 jar、Nginx 前段都跑起来，部署过程变成一条命令。这个亮点在计算机类毕设里非常吃香，因为学校实验室一般没几个人能拿出容器化方案。

消息队列：订单创建后发个 MQ 消息给积分服务或者短信服务。这个属于进阶中的进阶，如果你连主线业务都还没吃透，不建议轻易尝试，容易被问倒。

7. 一点个人经验分享

我带过的同学里，做商城的不少，最后分数高的那拨人有个共同特点：他们都是先把项目完整跑通，理解每一层在干什么，再动手改代码。反观那些急着堆技术名词的人，连购物车数量改了之后后端怎么刷新价格都说不清，一问一个卡壳。

如果你准备拿这套项目应付毕设，我给你的建议是：先用一周时间把整个项目跑通，再花两周时间从登录到下单完整走一遍代码，亲手写一次购物车和订单的全流程，最后把老师可能问的问题列成清单，一个个对着项目讲一遍。能完成这个过程，你收获的不仅是学分，而是真正对全栈开发有了体感。

我最后再分享一个小细节。答辩的时候被问到不知道的问题，不要硬编。你可以坦诚说“这个问题我确实没考虑过，如果继续深入的话，我的想法是这样”，然后把思路往你熟悉的方向上引。老师不是要考倒你，而是想看你的思考过程。你只要在项目里真实动手写过代码、踩过坑、修过 Bug，你就是最稳的。祝你的项目顺利过关。