先把这个项目的定位说清楚：这是一个基于SpringBoot + Vue + MySQL的图书电子商务网站管理平台，前端用 Vue 全家桶（Vue2/Vue3 + ElementUI + Axios），后端用 SpringBoot + MyBatis/MyBatis-Plus + JWT 鉴权，数据库采用 MySQL。功能覆盖前台图书展示、搜索、详情、加入购物车、下单支付（模拟）、后台图书管理、订单管理、用户管理、分类管理、轮播图管理等完整电商闭环。适合拿来当毕业设计、课程设计，也适合想系统学习 Java 全栈开发的人作为练手项目。下面这份内容是我基于同一类实战项目深度拆解出来的，不仅讲清楚功能怎么搭，还会把表结构设计、状态流转、前后端交互逻辑、常见报错和避坑经验一并交代清楚，希望能帮你真正把这套源码吃透。
1. 项目整体设计与技术选型解析
先说一个很现实的问题：为什么市面上的毕设选题那么多，偏偏“图书电商平台”经久不衰？因为它的业务复杂度卡在一个非常微妙的平衡点——既不像“学生管理系统”那样简单到没什么可写，又不像“双十一秒杀系统”那样复杂到学生根本做不完。图书电商天然包含用户、商品、购物车、订单、支付（模拟）、库存、分类、搜索、后台管理等多个模块，每一样都是 Java 全栈面试里最高频的考点。你把这个项目吃透，等于把SpringBoot 自动配置、MyBatis 持久层、RESTful API 设计、JWT 无状态认证、Vue 组件化开发、Axios 异步请求、SQL 表关系设计这些核心技能全部过了一遍。
1.1 为什么选 SpringBoot 而不是 SSM
很多课程还在教 SSM（Spring + SpringMVC + MyBatis），但实际企业开发里 SpringBoot 已经是绝对主流。原因很简单：SpringBoot 把以前需要大量 XML 配置的东西全部自动化了。你写一个图书查询接口，在 SSM 里要配置 web.xml、spring-mvc.xml、spring-mybatis.xml 三个配置文件，光跑通一个 Hello World 就要折腾半天；而在 SpringBoot 里，你只需要在pom.xml里引入spring-boot-starter-web依赖，写一个@RestController类，然后用@RequestMapping加上一个@Autowired注入 Service，项目就能直接跑起来了。
SpringBoot 对毕设的实际意义在于：它把你的时间从“折腾配置”里解放出来，让你有时间把精力放在业务逻辑和表设计上。这也是为什么几乎全部图书电商类毕设源码都选择 SpringBoot，而不是更底层的 SSM。如果你在项目答辩时被老师问“为什么用 SpringBoot”，你可以从自动配置、内嵌 Tomcat、生态丰富、与微服务架构自然衔接这几个角度回答，这本身就是加分项。
1.2 前端为什么用 Vue
Vue 在国内前端领域的普及率非常高，原因也很直接：上手曲线比 React 平滑很多，而且生态里跟后端管理平台最搭的 UI 组件库 ElementUI/Element-Plus 就是为 Vue 量身定制的。你做一个图书管理后台，需要表格展示、表单校验、分页、弹出对话框，用 ElementUI 就是简简单单的几个标签和属性；用原生 JS 写的话，光一个分页组件就能让你怀疑人生。
Vue 的响应式数据绑定也很适合电商类页面。比如前台搜索框输入关键字，页面下方的图书列表可以自动筛选；加入购物车之后右上角角标数量实时变化——这些交互需求用 Vue 的data+computed+watch处理非常顺手。你不需要操作 DOM，只需要维护数据状态，剩下的交给 Vue 的虚拟 DOM 去 diff 和渲染。
1.3 数据库为什么选 MySQL
这个其实不需要太多解释，MySQL 在中小型项目里几乎是默认选项。理由有三点：一是开源免费，学生随便装；二是生态成熟，Navicat、SQLyog、DBeaver 各种图形化工具齐全；三是跟 Java 生态的整合几乎没有障碍，MyBatis 的 SQL 操作、JDBC 驱动、连接池配置都有现成的方案。对于图书电商这种并发量不会很大的项目，MySQL 一步到位不用犹豫。
MySQL 里有一个点需要特别注意：数据库表的字符集一定要设置成 utf8mb4，而不是 utf8。因为 utf8 在 MySQL 里最多存3字节的字符，遇到 emoji 表情或者某些特殊符号会直接报错或者乱码。你可以把 utf8mb4 理解为“完整的 UTF-8”，这也是实际开发中的标准配置。
2. 核心功能模块与数据库设计拆解
图书电商平台的功能模块可以分为前台和后台两大部分。前台面向普通用户：图书浏览、分类筛选、关键字搜索、图书详情、加入购物车、下单、模拟支付、个人订单查看、个人信息维护。后台面向管理员：图书管理（增删改查）、分类管理、订单管理（发货/取消）、用户管理、轮播图管理、数据统计看板。这里有一个很多毕设容易做漏的点：前台和后台往往是两个独立的 Vue 项目，前台走用户端，后台走管理端，只是后端 API 共用一套。
2.1 核心数据表设计
图书电商的表数量通常在10到15张之间。以下是一张单子，你可以对照自己的数据库来检查是否有遗漏：
| 表名 | 核心字段 | 说明 |
|---|---|---|
| user | id, username, password, nickname, phone, email, avatar, role, status, create_time | 用户表，角色用于区分管理员和普通用户 |
| category | id, name, parent_id, sort, icon, create_time | 图书分类表，支持两级分类 |
| book | id, category_id, name, author, publisher, isbn, price, original_price, stock, sales, cover, description, status, create_time | 图书表，核心商品信息 |
| banner | id, image_url, link_url, sort, status | 首页轮播图表 |
| cart | id, user_id, book_id, quantity, checked, create_time | 购物车表，注意做唯一约束（user_id + book_id） |
| orders | id, order_no, user_id, total_amount, pay_amount, status, receiver_name, receiver_phone, receiver_address, create_time, pay_time, ship_time | 订单主表，状态字段要设计成 int 类型 |
| order_item | id, order_id, book_id, book_name, book_cover, book_price, quantity, total_amount | 订单明细表，快照用户下单时的商品信息 |
| address | id, user_id, receiver_name, receiver_phone, province, city, district, detail | 收货地址表 |
| comment | id, user_id, book_id, content, score, create_time | 评论表，可选模块 |
这里我想特别强调order_item表的作用。很多新手在设计订单时偷懒，只建一张 orders 表，把商品信息直接塞到订单表的一个字段里。这样做虽然也能实现功能，但如果用户在订单里购买了 3 本不同的书，数据在数据库里就会变成一堆 JSON 字符串，查询、统计都非常痛苦。正确的做法是订单主表和订单明细表一对多关联——orders 表只记录一笔订单的总体信息（订单号、总金额、收货人），order_item 表记录这一笔订单里具体包含哪几本书、每本书多少钱、买了几本。这样设计的好处是：以后做销量统计、图书推荐、用户画像扩展都很方便。
2.2 订单状态流转的设计思路
订单状态是电商项目的灵魂。很多毕设源码把订单状态做成字符串，比如直接用“待付款”“已付款”“已发货”，看起来直观，但实际开发中正规做法是用整数枚举来标记。我来列一下这套项目里常用的状态设计方案：
- 0：待付款（用户下单但未支付）
- 1：已付款/待发货（支付成功，等待商家发货）
- 2：已发货/待收货（商家已发货，等待用户确认）
- 3：已收货/已完成（用户确认收货或系统自动确认）
- 4：已取消（用户取消或超时未支付自动关闭）
用 int 做状态的好处非常多：一是存储空间小，二是可以做数字范围判断（比如大于等于1的都是“已支付”状态），三是以后接支付回调时签名验证更方便。在订单状态变更这一块，我在实际项目中强烈建议你使用状态标识字段 + 修改时间字段的配合方案，而且在每次状态变更时都应当做一次前置校验。比如用户取消订单时，必须确认当前状态是“待付款”，如果已经是“已发货”还允许取消，那物流体系就全乱套了。
2.3 表关系设计中的关键约束
数据库表设计最容易犯的错误之一就是“该加的约束不加”，然后靠 Java 代码强行做逻辑判断。我举三个具体的例子：
- 购物车表应该加上
UNIQUE KEY uk_user_book (user_id, book_id)唯一约束。没有这个约束，用户连续点击两次“加入购物车”，数据库里就会插入两条一样的记录，前端再不做合并处理的话，购物车就会越点越长。 - 订单号字段必须加唯一索引。订单号是用户查询、客服沟通、后续退款操作的关键凭证，万一并发场景下生成了重复的订单号，整个订单体系都会混乱。
- 外键如果你不是特别有把握，可以不建物理外键，但在 Java 实体类里必须维护逻辑关联关系。很多企业里是禁用物理外键的，因为外键会增加锁竞争、影响性能，但对毕设来说，物理外键建不建影响不大，不影响评分。
3. 核心业务实现：从前台登录到后台管理的完整闭环
这一节是重点中的重点。我按用户操作的完整路径来拆解，顺便把你拿到这套源码之后该怎么看、怎么改、怎么扩展的思路一并讲了。
3.1 用户登录注册与 JWT 鉴权
用户模块是几乎所有系统的第一步。这套项目里登录流程是这样的：前端把用户名和密码通过 axios POST 到/api/user/login，后端接收到请求后，用service层根据用户名查出用户记录，然后用BCrypt或者MD5（有些老项目用 MD5）对密码进行校验，校验通过后生成一个 JWT token 返回给前端。前端拿到 token 后存到 localStorage 或者 sessionStorage 里，之后每次请求都在 request 拦截器里把 token 塞进请求头：
// axios 请求拦截器 service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = token } return config })后端的 JWT 鉴权通常用一个拦截器实现，在 SpringBoot 里可以继承HandlerInterceptorAdapter或者实现HandlerInterceptor接口：
public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (StringUtils.isBlank(token)) { throw new BusinessException(401, "未登录，请先登录"); } Claims claims = JwtUtil.parseToken(token); request.setAttribute("userId", claims.get("userId")); return true; } }这里有几个关键点要注意：第一，拦截器一定要配置白名单，登录、注册、图书列表查询、图书详情这些接口不能拦截，否则用户还没登录就什么都看不了。第二，前后端分离项目的跨域问题要在 WebMvcConfig 里配置好CorsRegistry，允许前端的地址跨域访问，同时允许携带 Authorization 头。第三，密码存储一定不要用明文，数据库里存的应该是加密后的字符串。如果你的项目里密码是明文，建议至少改一下登录逻辑，用 SpringSecurity 自带的BCryptPasswordEncoder或者简单的DigestUtils.md5DigestAsHex做一次摘要。
3.2 图书上下架与分类管理
图书管理是后台的核心模块。添加图书时有两个细节特别容易踩坑：一是把书的总库存和已售数量放同一张表，每次下单都要同时扣减库存并累加销量；二是图书封面图的上传，注意不要直接存本地绝对路径，这样项目换个环境图片就全挂了。
文件上传这块我多说两句。毕设项目最简单可靠的方案是：后端接收 MultipartFile，保存到本地的一个upload/目录（路径用相对路径），然后把文件的访问 URL（比如/images/xxx.jpg）存到数据库，再通过一个静态资源映射配置把上传目录映射成可访问的 URL。你可以这样配置：
@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/images/**") .addResourceHandler("file:" + uploadDir); }如果项目里用了 MinIO 或者阿里云 OSS，那更好，直接上传到云端返回 URL 存库。但毕设项目一般不需要这么重，本地存储 + 静态资源映射已经足够。注意上传目录的路径分隔符，Windows 下是C:\upload\风格，Linux 下是/usr/upload/风格，建议用常量配置并拼接时用File.separator，避免换环境就崩。
3.3 购物车与订单提交的事务处理
购物车和下单是整套源码里最考验功底的部分，也是答辩时老师最可能追问的模块。购物车表设计的关键在于“合并”逻辑：同一个用户添加同一本图书时，不要插入新记录，而是把原有记录的 quantity 加1。这个操作可以用 SQL 里的ON DUPLICATE KEY UPDATE实现，也可以在 Java 里先查再增或改。为了不走弯路，我更推荐你先查再改，逻辑更清晰，也方便你在 Service 层写业务校验。
下单流程就比较讲究了，至少包括以下步骤：
- 前端从购物车里勾选要结算的商品，把选中商品的 ID 列表传给后端。
- 后端根据购物车 ID 列表查出购物车记录，关联图书表，计算总金额。
- 校验库存是否充足，不足则返回具体哪本书库存不够。
- 生成订单主记录，状态设为 0（待付款），订单号用时间戳 + 随机数生成。
- 生成订单明细记录，批量插入 order_item 表。
- 删除对应的购物车记录。
这里有个容易忽略的点：生成订单之后库存扣减的时机。常规方案是在提交订单时先行锁定库存（比如预扣库存），等支付成功之后再实际扣减，取消订单时再释放预扣的库存。但毕设项目一般没有接真实支付，通常是在用户支付（模拟）成功后再扣库存。还有一个更简单但能应付答辩的做法是：下订单时不直接扣库存，等模拟支付成功后再在一个事务里同时完成扣库存和变更订单状态。这是我见过多数可用源码采用的方式，好处是逻辑简单、边界清晰，而且你在答辩时能说清楚“为什么这样做”——避免下单不支付导致的库存虚占。
下单的核心方法必须加@Transactional注解。Java 的 Spring 事务是在RuntimeException抛出时自动回滚，所以你在 Service 层里要主动抛出业务异常而不是吞掉异常。很多学生写完代码后发现下单后数据库出现脏数据，十有八九是事务没生效。检查事务是否生效的关键是：看调用是否是外部调用。如果是同一个类里的方法 A 调方法 B，B 上的@Transactional是失效的，因为 Spring 的事务是基于 AOP 代理的，内部自调用不走代理。这个点被面试官问烂了，但真的能完全说清楚的人不多。
3.4 模拟支付、发货与订单状态更新
图书电商项目没有真实支付渠道，通常用“模拟支付”来代替。这个模块也别简单到只有一个“点击按钮就改状态”的接口。建议给它一个独立的前端页面，展示订单信息、金额，用二维码（后端生成一张固定图片）或者“模拟支付”按钮，点击后延时 1-2 秒再调后端接口，让整条流程看起来更像真实的支付体验。后端支付接口要做三件事：更新订单状态为 1、扣减图书库存、累加图书销量。这三件事放在一个事务里，保证数据一致性。
订单管理在后台主要是发货操作：管理员在后台看到新订单，点击发货，填写物流单号（没有的话随便填一个），订单状态改为 2。用户前台点击确认收货，状态改为 3。整个过程就是状态字段的数字变更，但每次变更都要记录操作时间字段，方便后续做售后处理。
3.5 前端路由与权限控制
前端 Vue 项目建议做成两个独立的页面结构：管理后台用 layout 侧边栏 + 顶部导航布局，前台图书展示页完全是另一套布局。路由划分大致如下：
// 前台路由 routes: [ { path: '/', component: () => import('@/views/Home.vue') }, { path: '/books', component: () => import('@/views/BookList.vue') }, { path: '/book/:id', component: () => import('@/views/BookDetail.vue') }, { path: '/cart', component: () => import('@/views/Cart.vue') }, { path: '/login', component: () => import('@/views/Login.vue') }, { path: '/order', component: () => import('@/views/Order.vue'), meta: { requiresAuth: true } }, ] // 后台路由 { path: '/admin', component: () => import('@/layouts/AdminLayout.vue'), meta: { requiresAuth: true, requiresAdmin: true }, children: [ { path: 'books', component: () => import('@/views/admin/BookManage.vue') }, { path: 'orders', component: () => import('@/views/admin/OrderManage.vue') }, { path: 'users', component: () => import('@/views/admin/UserManage.vue') }, ] }路由守卫是重点。没有路由守卫的毕设，用户直接改 URL 就能访问管理后台，这在答辩时是一个明显的漏洞。在 Vue Router 的beforeEach钩子里做全局守卫：
router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') const userInfo = JSON.parse(localStorage.getItem('userInfo') || '{}') if (to.meta.requiresAuth && !token) { next('/login') } else if (to.meta.requiresAdmin && userInfo.role !== 'admin') { next('/') } else { next() } })这个逻辑很简单，但能实打实地保护你的页面。至于后端接口的权限控制，除了在 JwtInterceptor 里查角色之外，还可以用@RequiresPermissions或者直接在每个@RequestMapping上加判断，毕设项目做到拦截器校验角色已经足够用了。
4. 环境准备与项目部署实操
很多人在毕设时卡住的地方往往不是代码本身，而是环境搭不起来。下面按顺序讲清楚从零到一跑起项目所需的全部步骤，尽量把每个坑都提前标记出来。
4.1 后端环境准备
后端需要的东西有：JDK 1.8（或更高，建议 JDK8 最稳）、Maven 3.6+、MySQL 5.7+（8.0 也完全兼容，注意驱动版本）、IntelliJ IDEA。这里的核心难点在于：MySQL 8.0 和 MySQL 5.7 的驱动坐标不一样，连接参数也不一样。如果你用的是 MySQL 8.0，pom.xml里的驱动依赖应该是：
<dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency>而application.yml里的连接需要加上时区和SSL配置：
spring: datasource: url: jdbc:mysql://localhost:3306/bookstore?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver如果数据库是 5.7 版本，驱动类名是com.mysql.jdbc.Driver，这个是新手最容易搞混的地方。还有一个小细节：MySQL 8.0 默认不允许公钥检索，有时候连接报错Public Key Retrieval is not allowed，在 URL 后面加上allowPublicKeyRetrieval=true就能解决。
4.2 前端环境准备
前端需要 Node.js（建议 14 以上，如果是 Vue3 项目建议 16 以上）、npm（或使用 yarn/pnpm）、Vue CLI。一个经典的大坑是：npm install 装依赖装到一半报错。多数原因是网络问题，源在国外访问速度慢。解决办法是更换淘宝镜像源：
npm config set registry https://registry.npmmirror.com另一个常见问题是 Node 版本过低，导致安装 Vue3 项目依赖时报ERESOLVE错误。如果项目用的是 Vite，通常需要 Node 14.18+ 或 16+。实在不想升级 Node 的话，可以在安装命令后面加--legacy-peer-deps，但治标不治本，还是建议把 Node 升级到长期稳定版。
4.3 从源码到运行：完整部署流程
拿到一套源码后，先别急着跑。我的建议是按下面这个固定顺序来：
- 用 IntelliJ IDEA 打开后端项目，等待 Maven 把依赖下载完（第一次下载会比较慢，属于正常现象）。
- 检查
application.yml里的数据库名、用户名、密码是否和你本地一致，不一致就改成你自己的。 - 在本地 MySQL 里创建一个数据库，名字和配置文件保持一致（比如
bookstore），然后导入项目里提供的bookstore.sql文件，导入方式可以是 Navicat 的“运行 SQL 文件”，或者命令行mysql -uroot -p < bookstore.sql。 - 启动后端项目，看到 SpringBoot 启动日志，端口默认 8080 没被占用，说明后端启动成功。
- 用 VS Code 或 WebStorm 打开前端项目，运行
npm install装依赖。 - 检查前端
src/utils/request.js里 axios 的baseURL是否指向后端地址（比如http://localhost:8080），不对的话改成你自己的。 - 执行
npm run dev启动前端开发服务器，浏览器访问http://localhost:8081或控制台打印的地址。 - 用种子数据里的管理员账号（项目介绍里一般会写明，比如 admin/123456）登录后台，看是否能正常调通接口。
如果这些步骤全部顺利跑通，那项目环境就没问题了。跑不通的话，看下面的常见问题排查部分。
5. 常见问题排查与避坑实录
这一节的价值在于：你在跑这套源码遇到的大部分报错，我都提前替你踩过一遍了。整理成表格方便直接查阅，并按出现频率排序。
| 报错现象 | 可能原因 | 解决办法 |
|---|---|---|
后端启动报Unable to acquire JDBC Connection | 数据库没启动/用户名密码错误/数据库名不存在 | 先确认 MySQL 服务已启动，再用客户端工具试连接同一个库，逐个排查。 |
前端npm install报错或卡住 | 网络源太慢/Node版本不兼容 | 换镜像源，npm config set registry https://registry.npmmirror.com；检查 Node 版本是否满足 package.json 要求。 |
| 前端请求接口报 404 | axios baseURL 配置错误/后端端口不对/接口路径不一致 | 打开浏览器调试工具 Network 看请求 URL，跟后端@RequestMapping路径一一核对。 |
| 前端请求接口报 401 | token 未传递/后端 JWT 拦截器拦截了白名单之外的接口 | 检查请求头是否加了 Authorization、是否需要登录后才能访问。 |
登录接口报Parameter password not present | 前端传参格式与后端不一致 | 检查前端 data 对象名是否跟后端@RequestParam或实体字段名一致，很多是大小写不一致。 |
| 图片上传成功但前端无法访问 | 静态资源映射配置没生效 | 检查addResourceHandlers的file:路径是否有协议前缀，Windows/Linux 下写法有差异。 |
| 下单成功但库存不减 | 扣库存逻辑写在支付成功分支里，但代码没有执行到 | 在支付接口里打断点，确认逻辑分支是否走了预期路径。 |
| MySQL 中文乱码 | 连接 URL 少了 encode 参数/表或字段的字符集不对 | 统一使用characterEncoding=utf8，表结构字符集使用utf8mb4，必要时重启 MySQL 让配置生效。 |
| 前端路由刷新后 404 | history 模式在开发服务器下缺少 fallback 配置 | 如果用 Vue Router 的createWebHistory，开发环境需要在 vue.config.js 里配置historyApiFallback，或者改成createWebHashHistory。 |
5.1 后端启动失败的快速自检清单
启动失败是最容易让人心态爆炸的问题。我分享一个快速自检的思路——从报错信息的最底部往上读。SpringBoot 报错堆栈很长，但真正的根因往往在最后几行的Caused by里。如果你看到类似这样的一行：
Caused by: java.sql.SQLException: Access denied for user 'root'@'localhost' (using password: YES)那问题就是在数据库账号密码上，直接去检查application.yml的username和password配置即可。如果堆栈信息显示的是Table 'bookstore.book' doesn't exist，说明数据库导入了但表不全，需要重新导入完整的建表 SQL 文件。
一个很容易被忽略的问题是：IDEA 打开的并不是 Maven 项目。正确打开 SpringBoot 项目的方式是选择项目目录下的pom.xml作为 Maven 项目导入，而不是直接 Open 文件夹。如果你打开后找不到spring-boot-maven-plugin或运行按钮是灰色，那大概率是 Maven 工程没有被正确识别。解决办法：右键pom.xml，选择Add as Maven Project。
5.2 端口占用与跨域问题的实战处理方法
后端默认端口 8080，如果你本地跑过其他 Java 服务，很可能冲突。改端口直接改配置文件：
server: port: 8088改了之后别忘了前端 axios baseURL 也要同步改，这是联调时最容易忽略的一环。
跨域问题在前后端分离项目中非常高频。表现是：前端能拿到后端响应，但浏览器控制台报CORS error。后端解决方案是在 SpringBoot 配置类里添加全局跨域配置：
@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); } }如果你用的是 Spring Security，跨域还要额外注意 Security 的过滤器链也会参与 OPTIONS 预检请求，此时需要在 SecurityConfig 里也放行跨域预检请求。
5.3 前端页面白屏和打包部署的注意事项
有时候npm run dev能跑，但npm run build之后部署到服务器就白屏了。多数原因是构建后静态资源的路径不对——默认生成的index.html里资源路径是绝对路径/js/app.js，直接部署到子目录时就会 404。解决办法是在vue.config.js里配置：
module.exports = { publicPath: './', }这在用 Nginx 部署到非根路径时尤其重要。如果是直接用spring-boot集成前端静态资源（前后端不分离部署），需要把npm run build生成的dist目录里内容拷贝到后端resources/static目录下，然后注意 SpringBoot 的静态资源不会主动拦截带 hash 的静态文件，一般没问题，但刷新非首页路由还是会 404，需要后端把不匹配的路径转发到index.html。
6. 如何把源码价值最大化：学习路径与二次开发建议
拿到这套源代码之后，最忌讳的做法是真接拿来就直接改一改交上去。对于项目是做课设还是自学，学习的路径都不一样。但我认为有一种通用的学习方式能够最大化源码的价值——看一遍、写一遍、改一遍。
看一遍的意思是，你至少要能从代码里抽离出完整的调用链。比如前台用户点击“购买”按钮，请求从哪里发出去、经过哪个 controller、哪个 service、哪条 mapper SQL、返回什么数据、前端怎么渲染——这条链路你能不看文档就串下来，才算“看懂”了这套源码。
写一遍的意思是，把核心的几个模块自己动手重新敲一遍，尤其是登录注册和下单事务这两块，自己敲和看别人的代码完全是两个难度。你会发现敲的过程中不断出现空指针、中文乱码、路由路径错误，而这些问题的解决过程正是你能力提升最关键的环节。
改一遍的意思是，在理解原代码的基础上，根据自己的想法加入几个新功能。这里我给几个适配毕设的创新方向：
6.1 推荐方向一：集成 Redis 缓存图书热门榜
现在很多毕设题目要求“有新意”，而这套图书电商项目最自然的扩展点就是给首页图书列表加上热门排行和缓存。
引入 Redis 依赖后，改造成本很低：把销量最高的前10本图书缓存到 Redis 的 ZSet 中，图书销量每次变更时更新 ZSet 分数；首页展示热门图书直接查 Redis 而不再查 MySQL。答辩时可以讲“利用 Redis 减轻了数据库压力，提升首页响应速度”，这个点非常实用，而且实际实现不超过100行代码。
6.2 推荐方向二：订单超时自动关闭
图书电商里如果没有真实支付，很容易出现“用户下单但永远不付款，订单一直挂在状态0”的情况。真实电商的做法是订单超过30分钟未支付就自动取消。实现方式有两种：一是用 Spring Task 定时任务每分钟扫描一次超过30分钟未支付的订单并关闭，这对毕设来说完全够用；二是用 RabbitMQ 的延迟队列来实现更优雅的超时处理。前者简单直接，后者适合有技术追求的答辩展示。
6.3 推荐方向三：后台数据统计看板
后台管理首页目前如果只是简单表格，可以考虑加一个统计看板：总销售额、今日订单数、图书销量 Top5、用户增长趋势。前端用 ECharts 画图，后端写几个统计 SQL（SUM(amount)、GROUP BY DATE(create_time)）。这块功能视觉冲击力强，答辩时演示效果极好，也是合格的“加分项”。
6.4 推荐方向四：图书评分与评论
图书在没有评分和评论的时候，用户选择起来会很费劲。你可以在图书详情页加入评分展示（平均分、各分值占比），用户购买后可以发表评论。这个功能会让数据库多一张评论表和一个评分子段，业务逻辑上多一个“用户只有购买后才能评论”的校验，属于中等工作量但收益明显的扩展点。
6.5 推荐方向五：多角色权限细化
现有项目如果是简单的 user / admin 两角色，你可以扩展成“管理员 + 运营 + 普通用户”三种角色，运营角色只能管理图书与轮播图，但无法查看用户列表和订单数据导出。这在 RESTful 接口上表现为接口层增加角色判断，在前端表现为菜单根据用户角色动态渲染，答辩时权限控制这部分讲清楚了非常出彩。
7. 答辩与课程设计文档撰写的实用经验
最后这一段说点“过来人”经验。很多学生代码写得不错，但答辩时讲不清楚，或者课程设计报告写得像说明书一样平淡，导致分数反而不高。我给自己学生反复强调的答辩要点有四条：
第一，讲清楚业务流程，而不是背诵技术名词。老师问“你这个购物车怎么实现的”，不要只说“用 Redis 存了”，而要说清楚数据流：用户在商品页点击加入购物车，前端把 bookId 和 userId 传给后端，后端校验通过后先查购物车表里有没有这条记录，有就数量加1，没有则插入新记录，返回最新的购物车列表给前端。老师说“好，明白了”，你就成功了。
第二，主动展示你遇到的困难和解决过程。老师最不想听的是“全部都挺顺利的”。你说“我当时前端改路由发现刷新页面就404，查了半天发现是 vue-router 的 history 模式需要后端配合做 fallback，后来我就换成 hash 模式解决了”——这种话能充分证明你是真的自己动手做过，而不是买来的源码。
第三，项目总结报告不要只写功能列表。课程设计报告的低分通病是全篇都在截图和罗列功能，没有把设计思路、数据库设计的理由、项目技术选型的对比讲进去。你应该用自己的话把“为什么选 SpringBoot 不选 SSM”“为什么订单要分成两张表”“为什么要把状态设计成 int 类型”这些判断逻辑写明白，这是报告的核心。
第四，准备几个扩展方向回答“还能怎么优化”。老师必问“如果以后要上线，你觉得哪里还需要改进”。你可以回答：接入真实微信支付、引入 Redis 缓存热点数据、用 ElasticSearch 做全文检索、用 MinIO 做分布式存储、部署时用 Nginx 做动静分离。就算你没做过，能分析出这套架构在真实生产环境中的不足，也足以证明你对全栈开发是有整体理解的。
我在实际带项目的过程中，见过太多学生卡在“源码能跑”到“项目能讲明白”之间这道坎上。源码只是起点，能把每一个接口的业务含义、每一张表的设计动机、每一个状态的流转路径讲清楚的人，才是真正把项目吃透了。这套 SpringBoot + Vue 图书电商平台的代码量不算大，但麻雀虽小五脏俱全，只要你按照上面的路径认真过一遍，不管是应付毕业答辩还是准备面试，你都会有一个拿得出手的完整作品。
