SpringBoot+Vue图书商城系统设计与实现全栈开发指南

每次看到“基于SpringBoot+Vue的图书电子商务网站管理系统”这种题目，我第一反应就是：又是一个经典到不能再经典的Java全栈毕业设计选题。甭管是本科还是专科，图书馆管理、图书商城这类业务几乎占据了Java Web类课程设计的大半壁江山。但说实话，经典归经典，真能从零把一个SpringBoot + Vue + MySQL + MyBatis的图书电商系统跑通、讲清楚、扛住答辩的项目，其实并不像标题看起来那么“烂大街”。

这篇文章我就以这套图书电子商务网站管理系统为例，把整个项目的设计思路、数据库建模、后端接口实现、前端页面联调，以及环境搭建和部署环节的坑，完整拆开讲一遍。内容是拿常见毕业设计源码的实践路径做底子，再把我在实际开发里踩过的坑、总结的经验一并补进去。无论你是准备拿这套项目交作业，还是想借它入门全栈开发，这篇都能当一份“避坑操作手册”来用。

先说清楚，这套系统能做什么：前台面向普通用户，提供图书展示、关键词搜索、分类筛选、加入购物车、下单购买、订单管理；后台面向管理员，提供图书信息维护、分类管理、用户管理、订单处理和统计概览。技术组成就是标题里那套：SpringBoot负责后端接口，Vue负责前端页面，MySQL存数据，MyBatis负责数据库操作。整个项目跑起来之后，前后端通过JSON格式的RESTful接口通信，典型的Vue + SpringBoot前后端分离开发模式。

1. 项目定位与技术选型拆解

1.1 为什么是SpringBoot + Vue，而不是其他组合

作为一个带过不少毕设项目、也接手过不少“历史遗留烂代码”的人，我可以负责任地说，SpringBoot + Vue这个组合能成为主流，不是因为它花哨，而是因为它稳、资料多、踩坑答案一搜就有。

先看后端。SpringBoot的本质是“约定大于配置”，它帮你把Spring MVC、Tomcat内嵌服务器、依赖管理等一堆繁琐的配置都封装好了。你不需要像以前用SSM框架那样写一堆XML配置文件，一个spring-boot-starter-web依赖拉进来，写个@RestController就能往外吐接口。这对学生党来说极其友好，因为学习曲线被大幅拉平了。

再看前端。Vue的核心优势是组件化开发和响应式数据绑定。你把页面拆成一个个组件，比如图书卡片组件、购物车列表组件、分页组件，每个组件只管自己那块逻辑，维护起来非常清爽。而且Vue的模板语法上手很快，v-for循环渲染图书列表、v-if控制登录状态显示、v-model绑定搜索框内容，这些都是直觉式的写法，不需要像老式jQuery那样手动操作DOM。

选择MySQL和MyBatis也很容易理解。MySQL是开源数据库里普及率最高的，安装简单、性能够用、面试常问；MyBatis则是半自动ORM框架，SQL由自己掌控，灵活性极高，而且它的动态SQL标签对复杂查询的支持非常实用，比如图书搜索要根据关键词、分类、价格区间动态拼接查询条件，用MyBatis的<where>和<if>标签就能优雅搞定。

1.2 这套技术栈解决了什么问题

如果换个思路，用纯JSP + Servlet写这个图书商城，行不行？也能跑，但你得自己处理Servlet的线程安全、手动拼接HTML、手动管理数据库连接池，开发效率低到怀疑人生。用前后端不分离的Thymeleaf模板引擎可以吗？可以，但页面交互稍复杂一点，Ajax局部刷新就写到你手酸。

SpringBoot + Vue这套组合，本质上是把“后端接口开发”和“前端页面开发”彻底解耦。后端人员只需要关注业务逻辑和数据交互，把数据以JSON格式返回；前端人员只需要关注页面渲染和交互，拿JSON数据往模板里填。这种分离带来的直接好处是：并行开发效率高、接口可以复用、后期维护时改动前端不影响后端，反过来也一样。

另外，这套技术栈对“找工作”这件事也有加成。现在Java开发岗位的招聘JD里，SpringBoot几乎是标配要求，Vue也是前端方向最普及的框架之一，MySQL更是通用技能。你把这样一个全栈项目做完、吃透，等于同时点亮了后端、前端、数据库三条技能线，无论是毕业答辩还是面试聊项目，都有实打实的内容可以说。

2. 系统模块划分与数据库设计

2.1 前台与后台的功能边界

做这个项目，第一步不是写代码，而是把功能清单理清楚。图书电商和普通图书管理系统最大的区别在于：它多了“购物车”和“订单”这两个电商核心概念。所以前台和后台的边界要从业务上划清楚。

前台（用户端）的功能路径是这样一条线：用户注册/登录 → 浏览图书列表 → 查看图书详情 → 搜索或按分类筛选 → 加入购物车 → 提交订单 → 查看我的订单 → 确认收货。围绕这条主线，还会延伸出一些辅助功能，比如个人中心里修改资料、查看收货地址、模拟支付等。

后台（管理端）则是围绕“商品”和“交易”做管理：管理员登录 → 图书分类管理 → 图书信息增删改查 → 订单状态处理（发货、完成） → 用户管理 → 数据统计面板。

功能划清楚之后，数据库的表结构就自然浮出来了。我见过不少同学一上来就建表，结果建到一半发现字段不够用、表关系理不清，返工重来。先画功能路径图、再建表，顺序不能反。

2.2 核心数据表设计详解

图书电商系统的核心表，按业务域可以分成三组：用户域、图书域、交易域。下面这张表结构是我个人比较推荐的方案，也是实际项目中验证过最稳的。

这里有几个容易忽略的设计细节值得单独说。

第一，订单表为什么要冗余一份收货人信息？很多初学者会想着用外键关联用户地址表，下单时去查地址。但电商系统的真实逻辑是：订单生成后，地址不能随用户修改而变动，否则历史订单就乱了。所以正确的做法是把收货人、电话、地址直接冗余到订单表里。

第二，图书信息表里的sales字段（销量）不能漏。图书详情页的“销量xx件”就是从这来的，图书列表按销量排序也靠它。有些同学只统计订单明细，而不单独维护销售数字，结果列表页每次排序都要做聚合查询，数据量大一点就会卡。

第三，order_item里的book_name、book_price也不是冗余，而是“快照”。下单那一刻图书名称和单价被固化下来，之后就算后台把书价改了、书名改了，用户的订单明细依然是当时下单时的样子。这是电商系统的一个核心思维：让订单忠于历史，而不是忠于现状。

2.3 MyBatis表关联查询的几个经典写法

表建好了，接下来就是用MyBatis去操作它们。这里挑几个实际开发里高频使用的查询场景，直接上Mapper代码片段，都是验证过能跑的写法。

图书列表分页加分类筛选，这是图书商城首页的核心接口。使用MyBatis动态SQL拼接：

xml复制<select id="selectBookPage" resultType="com.example.entity.BookInfo">
    SELECT b.*, c.name AS category_name
    FROM book_info b
    LEFT JOIN book_category c ON b.category_id = c.id
    <where>
        <if test="categoryId != null">
            AND b.category_id = #{categoryId}
        </if>
        <if test="keyword != null and keyword != ''">
            AND (b.book_name LIKE CONCAT('%', #{keyword}, '%')
                 OR b.author LIKE CONCAT('%', #{keyword}, '%')
                 OR b.isbn LIKE CONCAT('%', #{keyword}, '%'))
        </if>
        <if test="status != null">
            AND b.status = #{status}
        </if>
    </where>
    ORDER BY b.sales DESC, b.id DESC
</select>

这个语句把图书搜索、分类筛选、上下架状态过滤三个条件都纳入了同一个动态SQL里。LEFT JOIN分类表查出分类名称，避免了在Java代码里二次查库。

购物车列表查询，需要联查图书表拿到最新的图书信息和库存状态：

xml复制<select id="selectCartItemsByUserId" resultType="com.example.vo.CartItemVO">
    SELECT ci.id, ci.book_id, ci.quantity, ci.checked,
           bi.book_name, bi.price, bi.cover, bi.stock
    FROM cart_item ci
    LEFT JOIN book_info bi ON ci.book_id = bi.id
    WHERE ci.user_id = #{userId}
    ORDER BY ci.create_time DESC
</select>

这个查询的关键点是：购物车项只存了book_id和quantity，图书名称、单价、封面、库存都是实时联表查出来的。这样做的目的是保证用户每次打开购物车看到的都是最新价格和库存状态。

2.4 订单生成的业务逻辑与事务控制

订单模块是整个系统里最能体现业务逻辑功底的部分，也是答辩时老师最爱问的地方。生成订单这个操作，涉及三个核心步骤：

第一步，先根据购物车中选中的记录，计算出订单总金额。这里千万别用前端传过来的金额做后端信任数据，必须由后端根据图书表里的最新单价重新核算一遍。原因很简单：用户在前端页面上看到的单价是加载页面时的快照，但如果下单那一刻管理员改了价格，前端页面的价格就是过期的，如果直接信任前端传参，那系统就是被人拿价格数据随便薅羊毛的状态。

第二步，扣减库存。UPDATE book_info SET stock = stock - #{quantity} WHERE id = #{id} AND stock >= #{quantity}，这种写法是把库存扣减和库存校验合并成一条原子SQL，避免高并发情况下超卖。在图书电商这种业务场景下，超卖的严重程度没有秒杀系统那么夸张，但同样需要严谨处理。

第三步，插入订单表和订单明细表。订单明细要循环插入，有多少种图书就有多少条记录，每条记录都包含下单时的图书快照信息。

这三步操作虽然简单，但它们必须在同一个数据库事务里完成。SpringBoot里用@Transactional注解就能搞定，一旦某一步抛出异常，整个事务回滚，保证不会出现“扣了库存但没生成订单”或者“生成了订单但库存没扣”这种数据不一致问题。

java复制@Transactional(rollbackFor = Exception.class)
public Order createOrder(Long userId, List<Long> cartItemIds, OrderAddress address) {
    // 1. 查询购物车选中项，联表获取图书最新价格
    // 2. 循环计算总金额
    // 3. 逐项扣库存
    // 4. 插入订单主表
    // 5. 插入订单明细
    // 6. 清除购物车对应项
}

2.5 用户注册登录与Token认证

用户登录认证这块，我见过很多同学用Session，这也是教材里最经典的方案。但放在前后端分离的项目里，Session方案有几个别扭的地方：一是跨域请求要额外配置Cookie，二是后端集群部署时Session共享是个麻烦事，三是移动端App如果要复用这套接口，Session根本用不了。

所以更推荐用JWT（JSON Web Token）做认证。用户登录成功后，后端生成一个带有效期的Token返回给前端，前端存在localStorage里，之后每次请求都在HTTP请求头里带上Authorization: Bearer <token>。后端用一个拦截器或过滤器统一校验Token，解析出用户ID后存入请求上下文，后续接口直接从上下文里拿当前登录用户，不用每次查询数据库。

这种方案的好处是接口天然无状态，前端控制登录态非常灵活：Token快过期了可以用拦截器做静默刷新，退出登录直接删掉本地Token就行。配合SpringBoot的拦截器注册，代码量不大但体验和安全性都上一个台阶。

3. 后端核心实现：SpringBoot整合MyBatis的完整答卷

3.1 项目工程结构与分层设计

后端工程结构建议用标准的Controller-Service-Mapper三层架构，这是每个Java开发都知道的基础分法，但很多没经验的人写着写着就乱套了。我的建议是严格按照下面的目录来组织：

code复制src/main/java/com/example/bookshop/
├── controller/        # 接口层，只做参数接收和结果返回
│   ├── UserController.java
│   ├── BookController.java
│   ├── CartController.java
│   └── OrderController.java
├── service/           # 业务逻辑层，核心业务都在这
│   ├── UserService.java
│   ├── BookService.java
│   └── OrderService.java
├── mapper/            # MyBatis数据访问层，只做SQL操作
│   ├── UserMapper.java
│   ├── BookMapper.java
│   └── OrderMapper.java
├── entity/            # 数据库实体类，和表字段一一对应
├── vo/                # 视图对象，接口返回给前端的数据模型
├── common/            # 通用类：统一返回结果、常量、异常处理
└── config/            # 配置类：拦截器注册、跨域配置等

这个分层的核心原则是：Controller层必须保持“薄”，只负责参数校验和调用Service，不在Controller里写业务逻辑；Service层承载所有业务规则；Mapper层只做数据访问。这样分开的好处是，答辩时老师问你“某个需求改了，你改哪一层”，你能非常清晰地说出影响范围。而且后续做单元测试，Mock掉Service层就能测Controller，非常方便。

统一返回结果这个类，是整个项目里看着不起眼但极其关键的一个基础类。我建议定义成Result<T>，包含三个字段：code（状态码，200成功，500失败，401未登录）、message（提示信息）、data（响应数据）。所有Controller接口都返回这个封装类型，前端axios统一根据code判断请求是否成功，而不是靠HTTP状态码。这个规范一旦定了，前后端联调时沟通成本会直线下降。

3.2 MyBatis配置与数据源连接

SpringBoot整合MyBatis，核心配置就那么几项，但每一项都有坑。

application.yml里的数据源配置，注意serverTimezone参数必须设置，否则会报时区错误。MySQL 8.x版本驱动必须带com.mysql.cj.jdbc.Driver，这是新手最容易踩的坑之一，很多人从旧项目拷配置，驱动还写着老版本的com.mysql.jdbc.Driver，直接启动报错。

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/bookshop?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
    username: root
    password: 123456
    driver-class-name: com.mysql.cj.jdbc.Driver
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

mybatis:
  mapper-locations: classpath:mapper/*.xml
  type-aliases-package: com.example.bookshop.entity
  configuration:
    map-underscore-to-camel-case: true

map-underscore-to-camel-case这个配置非常实用，它能把数据库的create_time字段自动映射到Java类的createTime属性，不用每个实体类字段都加@TableField注解。如果没有这个配置，查询结果映射出来的对象会有大量字段为null，这是排查半天都很难发现的问题。

另外，MyBatis的Mapper接口和XML文件要放在对应的包路径下，并且在启动类上记得加@MapperScan("com.example.bookshop.mapper")注解，否则Spring容器扫描不到Mapper接口，启动直接报“Invalid bound statement”错误。

3.3 图书搜索与分页查询接口实现

分页查询是高频接口，图书列表、订单列表、用户列表都离不开它。这里推荐用PageHelper这个分页插件，它最大的价值在于使用简单：只需要在Service方法执行查询之前调用PageHelper.startPage(pageNum, pageSize)，接下来执行的MyBatis查询就会被自动拦截并拼上LIMIT语句，同时还能通过PageInfo拿到总记录数、总页数等分页元数据。

java复制public PageResult<BookInfo> getBookPage(Integer pageNum, Integer pageSize,
                                        Integer categoryId, String keyword) {
    PageHelper.startPage(pageNum, pageSize);
    List<BookInfo> bookList = bookMapper.selectBookPage(categoryId, keyword);
    PageInfo<BookInfo> pageInfo = new PageInfo<>(bookList);
    return PageResult.of(pageInfo.getList(), pageInfo.getTotal());
}

分页参数这里有一个细节：前端传来的pageNum是从1开始的，而SQL的LIMIT是从0开始的，PageHelper自动处理了这层转换，你不需要手动pageNum - 1，千万不要画蛇添足。

图书详情接口反而简单，根据主键查询单条记录返回即可。但这里有一个很小的优化点：图书详情页通常会展示“同类推荐”，可以在详情查询的业务方法里，根据当前图书的分类ID再查同分类下的其他图书，按销量取前几条返回。这个功能实现起来就是一条SQL的事，但对系统完整度的提升非常明显。

3.4 购物车与订单接口闭环

购物车的接口实际上很直接：添加、删除、修改数量、查询列表、清空。但要注意的是，添加购物车时要先查一下这个用户是否已经把这本书加过了，如果加过了就做数量累加，而不是再插入一条新记录。这个判断放在Service层里做，每次操作带着用户ID和图书ID一起查。不做的后果就是用户的购物车会出现同一本书的多行记录，看着很蠢，体验很差。

订单相关接口则要处理好几种状态流转。订单状态不要只用字符串存储，建议用数字枚举：0待支付、1待发货（已支付）、2已发货、3已完成、4已取消。前后台对这个状态的展示和操作要对应起来：用户端可以取消待支付订单，确认收货后订单变成已完成；管理端看到已支付订单可以标记发货，看到已完成订单可以查看详情。这个状态机逻辑理清楚了，前后台各角色操作权限自然就清楚了。

下单接口的入参要同时包含两个信息：用户选中的购物车项ID列表，以及收货地址。地址信息要注意：如果系统还没做地址簿功能，就让用户在下单弹窗里直接填写；如果做了地址簿，则传递地址ID，从地址表查出完整地址。学生项目建议直接做后者，因为地址簿功能本身也是一个加分亮点，可以在答辩时多聊几句“为什么地址要独立成表”。

4. 前端核心实现：Vue和SpringBoot的丝滑对接

4.1 Vue前端工程与路由设计

前端工程我用Vue CLI或Vite创建，配合Vue Router做页面路由控制，UI组件库使用Element UI或Element Plus。这套组合是当前Vue项目最普适的搭配，资料多、组件丰富、看得见的案例也多。

路由规划上，前台和后台要分开架子。前台页面路由：/首页图书列表、/book/:id图书详情、/cart购物车、/orders我的订单、/login登录、/register注册。后台管理路由统一挂在/admin路径下，再套一层AdminLayout布局组件，下面包含/admin/books图书管理、/admin/categories分类管理、/admin/orders订单管理、/admin/users用户管理等子路由。

路由守卫是前端必须做的一个环节。用router.beforeEach判断用户访问的页面是否需要登录权限，如果当前没有Token且目标路由需要认证，就强制跳转到登录页。后台管理页还需要额外判断用户角色，如果不是管理员就直接拦截跳回首页。逻辑不复杂，但能有效防止普通用户绕过前端入口直接访问管理页。

4.2 axios封装与后端接口联调

axios请求封装是我每次做项目都会第一个写的前端工具函数。统一封装的请求模块里，要做三件事：设置baseURL、请求拦截器自动加Token、响应拦截器统一处理业务码。

javascript复制import axios from 'axios'
import { ElMessage } from 'element-plus'
import router from '@/router'

const request = axios.create({
  baseURL: '/api',
  timeout: 10000
})

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

request.interceptors.response.use(
  response => {
    const res = response.data
    if (res.code === 401) {
      localStorage.removeItem('token')
      router.push('/login')
      return Promise.reject(new Error('登录已过期'))
    }
    if (res.code !== 200) {
      ElMessage.error(res.message || '请求失败')
      return Promise.reject(new Error(res.message))
    }
    return res
  },
  error => {
    ElMessage.error('网络异常，请稍后重试')
    return Promise.reject(error)
  }
)

这里有个关键点：baseURL: '/api'是配合开发环境代理使用的。前端的请求路径写成/api/book/list，然后在vue.config.js里配置开发代理，把/api开头的请求转发到后端的http://localhost:8080。这样就可以完美绕开开发阶段最常见的跨域问题，而且生产环境部署时，把前后端打包到一起后，同源请求连代理配置都不需要改。

4.3 关键页面实现与组件设计

图书列表页是系统的门面，实现思路很简单：页面加载时调用图书分页接口，把返回的数据渲染到卡片布局里。Element UI的el-card卡片组件非常适合做图书展示，封面图、书名、作者、价格、销量、加入购物车按钮，一个卡片就包含了。分类筛选做成侧边栏或顶部标签栏，点击分类时重新请求接口，同时重置分页页码。

图书详情页看一眼就知道重点在哪：大图展示、图书信息区、购买操作区。购买操作区放“加入购物车”和“立即购买”两个按钮，立即购买可以直接跳转下单确认页。详情页需要展示完整的图书描述，如果后台录入的图书描述是富文本，前端用v-html输出之前，要留意内容安全和XSS风险。学生项目里即使不用富文本、只放纯文本摘要，也建议保留这个意识。

购物车页则是一个典型的“列表+底部结算栏”结构。列表里每行展示图书勾选框、封面、书名、单价、数量步进器、小计金额；底部结算栏固定显示“已选X件，合计：¥XXX”和“去结算”按钮。这里要特别处理好勾选状态的变化：用户勾选或取消勾选时，要实时重新计算底部的合计金额。用Vue的computed计算属性来做这个逻辑，是最优雅的方案，数据一变界面自动更新，完全不用手动操作DOM。

4.4 前后端接口联调的调试思路

联调阶段最痛苦的往往是跨域问题。开发阶段的解决方案前面提过，用Vue CLI的代理转发最省事。但如果你不想配置代理，也可以在后端加一个全局跨域配置类，实现WebMvcConfigurer接口的addCorsMappings方法，允许指定来源跨域访问。

需要提醒的是，后端跨域配置一旦放开，等于任何人从任何域名都能调你的接口。所以生产环境要慎重，最好只允许固定的前端域名跨域。这也是很多源码项目容易忽略的安全细节，答辩时你要是能主动提出来，老师对你的印象会好很多。

联调时的另一个高频问题就是接口字段对不上，Java后端习惯用驼峰命名，数据库字段是下划线命名，前端如果直接映射JSON字段，经常会遇到create_time和createTime混乱的问题。统一规范的做法是我在前面配置里提到的：后端开启map-underscore-to-camel-case，让实体类字段统一用驼峰风格；前端就用后端返回的驼峰字段名。两边约定好，不要一会儿下划线一会儿驼峰，能省掉大量联调时间。

5. 环境搭建与打包部署避坑实录

5.1 本地开发环境搭建的完整步骤

在开始写代码之前，先把环境一次性配好。很多同学出问题不在代码本身，而是卡在环境搭建上。就用这套图书电商系统需要的环境，我按顺序理一遍。

第一步，装JDK 8或JDK 11，建议用JDK 8就行，因为SpringBoot 2.x系列对JDK 8支持最稳。装的时候记得配好JAVA_HOME环境变量，并在命令行执行java -version验证。

第二步，装IDEA。社区版就够用了，打开项目后自动识别Maven工程。有一点要提醒：IDEA首次打开项目时会自动下载Maven依赖，这个过程受网络环境影响，可能很慢。如果等太久，请检查Maven仓库镜像是否配置为阿里云镜像，配置位置在Maven的settings.xml里，加上阿里云中央仓库地址后，依赖下载速度会从“乌龟”变成“高铁”。

第三步，安装MySQL。Windows上建议用安装包而不是压缩包。每一步安装过程都要仔细看，尤其是设置root密码那一步，建议设成123456这种简单密码，项目里好配。安装完先确认MySQL服务正常启动，然后执行mysql -u root -p登录命令行，创建数据库bookshop，把项目里的SQL脚本导入，中文乱码多半是字符集没设对，建库语句带上DEFAULT CHARSET utf8mb4就行。

第四步，安装Node.js，这个很简单，官网下载LTS版本，一路下一步就完了。Vue项目依赖安装走npm install，如果因为网络原因装不动，可以把npm源切到国内镜像。

这几个步骤看起来多，但整套环境配下来其实就是“下一路软件、点一路下一步”的事。真正容易出问题的是后面项目启动阶段，下面单独列几个高频故障。

5.2 Vite前端项目联调前的配置要点

Vite相比Vue CLI的好处是启动速度快到飞起，但配置代理的写法有一点区别。在vite.config.js里，通过server.proxy选项配置开发代理：

javascript复制export default defineConfig({
  server: {
    port: 3000,
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true
      }
    }
  }
})

启动Vite项目后，前端跑在3000端口，后端跑在8080端口，前端所有/api开头的请求都被代理转发到后端。这个过程中前后端两边端口要保持固定，别一会儿3000一会儿5173，自己把自己绕晕。

还有一个经常被忽略的Vite配置：如果你不是把index.html放在项目根目录下，或者要自定义前端构建输出目录，Vite的打包配置（build.outDir）和后端静态资源目录要对齐。打包部署到SpringBoot时，前端构建产物要能正确输出到src/main/resources/static目录里，如果你的项目结构是前后端完全分离的仓库，那就在部署时把构建产物手动复制过去，或者配置CI脚本自动复制。

5.3 SpringBoot打包与前端产物合并部署

项目开发完成后，部署方式可以有两种选择。

一种是把后端打成Jar包，前端打包后的静态文件直接放进SpringBoot的src/main/resources/static目录，这样最终只有一个Jar包，里面既有后端接口又有前端页面，一条java -jar bookshop.jar命令就能启动整个应用。这种部署方式最适合毕业设计演示和服务器部署，部署成本极低，不会出现“前端一个服务、后端一个服务、还要配Nginx反向代理”这种复杂的运维操作。

前端打包命令是npm run build，生成的是一个dist目录，里面有index.html、js文件夹、css文件夹等静态资源。把它们直接复制到static目录就完成了合并。要注意的是，Vue项目里如果配置了路由的history模式，生产环境刷新页面会404，因为静态文件服务器找不到前端的路由路径。最简单的解决方法有两种：一是改用hash模式路由，路径变成/index.html#/book/1这种风格，所有资源都是单页面的内部切换，不存在404问题；二是在后端加入一个路由转发规则，找不到路径时统一转发到index.html。学生项目演示建议直接用hash模式，简单稳定不折腾。

第二种方式是把前端打包产物放到Nginx里，后端只提供接口，通过Nginx做反向代理把/api请求转发到后端端口。这种方式更接近企业级生产架构，但部署复杂度明显更高，需要会配Nginx。如果你做这个项目的目的是练手和答辩，第一种方式完全能应对。

5.4 部署之后的几个小坑

Jar包部署到服务器后，有几个问题值得提前预防。

首先是端口占用问题和端口没对外开放的问题。服务器上的8080端口，很多云服务商默认安全组是不放开的，你本地访问不通，第一反应不要以为是项目没启动，先查安全组规则。其次是数据库连接问题，服务器上的MySQL要和本地的配置区分开，注意数据库账号的访问权限是要允许远程连接的，否则后端连不上数据库会一直报连接失败。

其次是上传文件的存放位置。图书封面、用户头像这类上传功能，如果文件存在了项目的临时目录里，一旦重启服务文件就没了。建议在配置里指定一个固定的外部存储路径，比如D:/upload/（Windows服务器）或者/var/upload/（Linux服务器），并把上传文件路径做成可配置项。否则你每次重新部署，图片全部丢失，用户体验很糟糕。

最后是日志问题。代码里System.out.println不要乱用，建议用SLF4J日志框架输出，配合logging.file.name配置把日志输出到指定目录文件。出了问题直接翻日志文件，在服务器上排查问题会省力很多。这个习惯从做第一个项目时就要养成。

6. 常见问题与排查技巧实录

6.1 后端启动与数据库相关故障

后端启动报错是出现频率最高的问题，这里把常见故障排列成一个速查表，直接照着排查。

6.2 前端联调与部署故障

前端的问题相对好定位，但有些故障现象非常迷惑人。

页面能打开但数据请求失败，看浏览器F12控制台的网络请求。如果请求路径显示的是/api/book/list且返回404，那大概率是后端没有这个接口或路径不匹配；如果请求被CORS错误拦截，且你没有配置代理，那就是跨域没处理；如果请求返回401，那就是Token没带或者过期了。用Postman直接请求后端接口，是区分“前端问题”和“后端问题”最快速的办法。

打包之后前端页面白屏，这个坑也很常见。原因通常是静态资源的路径配置不对，index.html里引用的JS/CSS路径是绝对路径，导致部署后找不到资源。Vite打包时，在vite.config.js里设置base: './'，让资源路径改成相对路径，就能解决。另外一个原因是路由模式，用createWebHistory时刷新页面后端没有兜底，改成createWebHashHistory即可。

还有一个隐性坑：前端调用了后端接口，但页面上显示的数据是旧的。这一般是浏览器缓存问题，也可能是前端没有重新构建打包。每次改完前端代码，一定要重新执行npm run build，再用新的dist目录替换旧的静态资源，不然你改的东西根本没进部署包里。

6.3 业务逻辑上的典型Bug

业务逻辑Bug比环境问题更隐蔽，而且往往是答辩老师重点问的地方。我见过很多学生项目，代码跑得通，但稍微换个操作顺序就出问题。

典型Bug之一是下单时库存负数问题。用户下单不会校验库存，或者校验和扣减不是原子操作。结果用户把最后一件库存买走了，另一个用户再下单时，库存直接变成负的。前面讲过的UPDATE ... WHERE stock >= #{quantity}这个写法就是专门解决这个问题的，要让两条并发请求只有一条能执行成功。

典型Bug之二是购物车重复添加问题。同一本书被添加了两次，购物车里出现两行一样的记录，用户手动删除还找不找得到是哪个。解决方式就是添加之前先查询，已经存在就更新数量，不存在才插入。

典型Bug之三是订单状态混乱。用户取消了订单，但库存没有加回来；或者管理员发货后，订单状态没有流转到下一步，用户端一直显示“待发货”。这个问题的根源是状态流转逻辑没有写全，每做一个状态变更操作，都要问自己一句：下一步状态是什么？需要回滚什么数据？

6.4 答辩前必查的几个细节

这套项目如果是用于课程设计答辩，做完代码之后，还要花半天时间做“答辩前检查”。有些细节不检查，演示现场很容易翻车。

第一，数据要造得好看点。图书表里至少要有20本书以上，封面图不能是空白，价格要有梯度，销量要有差异。很多学生只插三五条数据，页面空荡荡的，演示效果大打折扣。

第二，敏感信息不能明文存储。数据库里的用户密码，至少要用Spring Security的BCryptPasswordEncoder做加密存储，或者退一步用MD5加盐。直接明文存密码的，在答辩时被老师看到，印象分直接减半。

第三，统一异常处理需要检查。程序里如果出现了未捕获的异常，前端会收到一坨英文的堆栈信息，非常难看。建议写一个全局异常处理器，用@RestControllerAdvice统一拦截异常，把异常信息包装成友好提示返回给前端，同时把完整的异常堆栈记录到日志里。

第四，删除功能的友好性。图书删除之前，要检查是否有订单关联，有的话要么做逻辑删除，要么给出“该图书有订单记录，不能删除”的提示。很多系统直接物理删，万一删了有历史的图书，订单明细里就只剩一串ID，连名称都查不出来了。

我个人在实际开发里最深的体会是：这类全栈项目，真正拉开差距的从来不是“会不会调框架”，而是“边界情况想得够不够周全”。面试官和老师看项目，看的不是你能把CRUD写得多花哨，而是你面对“库存扣减”“订单快照”“登录认证”“异常处理”这些真实业务场景时，有没有产品思维和工程意识。把这套图书电商系统完整做下来、把每个设计决策的为什么都讲清楚，比只跑通一遍代码的收获大得多。

最后再分享一个小技巧：开发过程中，把每一个踩过的坑、对应的解决方案，随手记在项目的README里。这不仅是你答辩时的绝佳素材，也是你面试时聊项目最好的“谈资储备”。做项目的过程，本身就是一条经验积累曲线，记录下来的才真正算数。