SpringBoot+Vue图书商城系统实战：从架构设计到部署排错全解析

图书电子商务网站管理系统，听起来像是一个毕业设计里再常见不过的课题，但只要真动手做过一遍，你就会发现它比想象中要“厚实”很多。基于SpringBoot+Vue这套主流组合，配合Java、MySQL、MyBatis做出来的完整源码，不只是把用户注册、图书展示、购物车、下单这些页面堆在一起，真正难的是把权限、事务、分页、接口约定这些底层逻辑理顺。这篇文章我就把整个系统的设计思路、表结构、核心接口、Vue联调、部署上线这一条完整链路拆开讲清楚，重点是我在实际落地过程中踩过的坑和排雷方法。不管是正在做毕设，还是想快速搭一套可复用的商城管理后台，这篇文章应该都能给你省不少时间。

1. 项目定位与技术选型

1.1 为什么选“图书电商”这个业务载体

图书是电商系统里最理想的练手品类，没有之一。一个图书商城可以把电商的核心链路全部覆盖到：商品分类、图书上架、库存管理、购物车、订单生成、后台统计，业务逻辑清晰完整，但又不像家电、服饰那样牵扯到多规格、批量采购、复杂促销等重型玩法。拿图书记载一个系统的“最小完整闭环”，投入产出比非常合适。

对开发者来说，图书数据容易批量造，封面图可以网上找占位图，价格用小数点两位存好，没有太复杂的字段。你不需要在商品数据的“坑”里被细节拖住精力，可以把重心放在SpringBoot后端接口设计、MyBatis的SQL编写、Vue页面交互这些真正影响项目质量的地方。

1.2 技术栈选型的思路复盘

这个项目我最终定了SpringBoot + Vue + MySQL + MyBatis，原因是这四个东西的组合在国内中小项目里实在是太经典了，参考资料多、问题排查方便、招人匹配度也高。

SpringBoot解决的是Spring配置地狱问题。早期SSM项目光配置applicationContext.xml、spring-mvc.xml、数据源、事务管理器就要写一大堆，每个新模块都要手动声明bean，繁琐且容易出错。SpringBoot用自动配置和起步依赖把这些琐事全收敛了，一个pom依赖加一个application.yml就能把工程跑起来，上手速度快，后面接入拦截器、事务、定时任务也都有成熟的starter可用。

MyBatis则是我刻意选型的结果。相比JPA那种表结构自动生成的“黑盒”方案，MyBatis把SQL写在自己的Mapper.xml里，每一个查询、每一段动态SQL都肉眼可见，可控性极强。图书列表查询要关联分类、订单要联查商品和地址，这种业务场景用MyBatis写XML非常顺手。另外从学习和面试的角度看，手写动态SQL、手动处理结果映射、理解MyBatis的二级缓存机制，都是加分项。

前端用Vue，选它的理由很简单：组件化开发让页面可复用性高，矢量数据绑定和指令系统让交互实现效率高，而且Vue的生态足够成熟，Element UI、Vue Router、Axios这些东西一套下来就很完备。比较旧的JSP + jQuery方案在多人协作和后期维护上确实吃亏，Vue这种数据驱动视图的思路，写多了就回不去。

1.3 单体架构与前后端分离的取舍

当前项目我采用的是“前后端分离开发 + 单体部署”混合模式。开发阶段Vue通过Vite起本地服务，接口请求走代理转发到SpringBoot；部署上线时把Vue构建出的静态资源直接扔进SpringBoot的resources/static目录，整个系统只跑一个8080端口，一个就是服务，天然同一域名、没有跨域、甚至没有额外的Nginx配置干扰。

这种取舍对图书商城来说非常理想。如果上一套前后端两个项目分开部署，还得配置跨域、处理CORS预检、维护两个服务进程；而这个系统的用户量级和应用场景根本到不了需要前端CDN缓存、后端多节点扩展那一步。合并部署既保留了前后端分离开发模式对代码组织结构的优势，又让交付和演示变得非常省心。如果你非要拆开跑，也只需要在Vite配置里加一个proxy，生产环境用Nginx做反向代理，思路并不复杂。

2. 系统架构设计与核心业务建模

2.1 功能模块拆解与角色权限矩阵

先梳理系统里到底有哪些角色，再针对每个角色去划功能边界。这个项目我设计了三类角色：游客、普通用户、管理员。游客可以浏览图书列表、查看图书详情；普通用户额外拥有加入购物车、提交订单、查看自己的历史订单能力；管理员则负责后台的图书增删改、分类维护、用户禁用和订单状态管理。

权限控制只放在前端做隐藏按钮没有任何意义，后端的接口必须同样做校验。我给每个登录用户签发JWT，令牌里携带用户ID和角色类型，后端通过拦截器统一解析Token并赋予请求上下文。管理员专属接口再用一个AdminInterceptor验证角色，双重拦截，才能防止有人直接拿到普通用户Token去调用管理员接口。

整个系统按前后台分成两大入口管理端和用户端。管理端用侧边栏导航列出功能模块，用户端围绕图书浏览和购买流程展开。业务上涉及的模块包括图书管理、分类管理、轮播图管理、用户管理、购物车、订单管理、个人中心七大部分，其中轮播图管理是可选的扩展点，不是核心链路，但加上它管理端界面会显得更完整。

2.2 数据库表设计与关联关系

先上表清单，这套表结构支撑图1.5万本图书数据没有任何压力。

设计的时候有三个容易踩的坑提醒一下。一是金额字段不要用DOUBLE，要用DECIMAL(10,2)，否则累加计算时容易出现精度导致的“0.1+0.2不等于0.3”这类问题；二是order_item里一定要冗余一份图书标题和价格快照，因为订单生成后图书可能改名或调价，历史订单必须保留“当时交易的商品信息”，这也是电商系统的通用做法；三是购物车表加上（user_id, book_id）的联合唯一索引，防止同一个用户把同一本书加两遍，数据层面的兜底比在前端写判断靠谱得多。

2.3 接口设计与统一返回结构

后端接口我全部走RESTful风格，以资源为中心设计URL，动词统一放在请求方法上。图书模块是资源操作最多的部分，它的接口设计如下：

code复制GET    /api/book/page         分页条件查询图书
GET    /api/book/{id}         获取图书详情
POST   /api/book             管理员新增图书
PUT    /api/book/{id}        管理员更新图书
DELETE /api/book/{id}        管理员删除图书
GET    /api/category/tree     获取分类树
POST   /api/cart              加入购物车
GET    /api/order             查询当前用户订单
POST   /api/order/add         提交订单
POST   /api/pay               模拟支付

前后端接口交互必须有一个统一的返回结构。我的做法是定义Result对象，格式固定为三个字段：

java复制public class Result<T> {
    private Integer code;   // 200成功，500业务失败，401未认证，403无权限
    private String msg;
    private T data;
}

Code统一并且语义干净非常重要。前端Axios拦截器只需要检查code是否为200，不需要每个页面各自做判断。如果某个模块接口返回了401就统一跳转登录页，返回403就弹出无权限提示，代码重复率会大幅下降。

2.4 认证方案：JWT无状态登录

图书电商系统一般不要求SSO级别的联动，JWT是最适合的方案。用户登录成功后，服务端用密钥将“用户ID、角色、过期时间”这三个信息加密生成Token返回给前端，前端存储后每次请求放到请求头Authorization里。后端不需要在Session里保存任何状态，天然适合前后端分离架构。

JWT虽然好用，但有两点一定要注意。第一点，不要在Token里塞太多东西，用户头像、昵称这些非关键信息加进去只会让Token变长、解析变慢，必要的只有ID和角色。第二点，必须在Token过期时间上下足功夫，我设置的是2小时，前端拿到Token后需要在Axios响应拦截器里捕获401状态并引导用户重新登录。此外，如果项目稍微复杂一点，还可以引入一个refreshToken机制做无感续期，但图书商城这个量级用不上，2小时过期重登完全够用。

3. 后端完整落地：SpringBoot与MyBatis实战

3.1 工程结构搭建与核心依赖配置

后端工程我用IDEA初始化，基础JDK选1.8（稳妥，完全兼容），下面是pom.xml里的关键依赖配置：

xml复制<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.7.14</version>
    <relativePath/>
</parent>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.mybatis.spring.boot</groupId>
        <artifactId>mybatis-spring-boot-starter</artifactId>
        <version>2.3.1</version>
    </dependency>
    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <scope>runtime</scope>
    </dependency>
    <dependency>
        <groupId>com.auth0</groupId>
        <artifactId>java-jwt</artifactId>
        <version>4.4.0</version>
    </dependency>
    <dependency>
        <groupId>com.github.pagehelper</groupId>
        <artifactId>pagehelper-spring-boot-starter</artifactId>
        <version>1.4.7</version>
    </dependency>
</dependencies>

注意MyBatis starter版本和SpringBoot版本有对应关系，我一开始犯过用新版MyBatis 3.0配SpringBoot 2.7导致Bean初始化报错的错误。后来老老实实锁定MyBatis 2.3.x，避免了很多不必要的版本冲突。

工程分包我按经典三层结构来划分，controller、service、mapper、entity四个包，额外加一个common包放统一返回和异常处理，interceptor包放JWT拦截器。Entity实体类和数据库表一一对应，Mapper存访问数据库的接口方法，Service写业务逻辑，Controller只做参数接收和结果返回。这样大致的结构层级清楚，后面扩展新模块时直接照着Copy也很方便，业务复杂了再引入DTO/VO层做隔离也来得及。

3.2 MyBatis配置与动态SQL实战

核心配置文件是application.yml，数据源配置里有三个地方必须写对，少了任何一项，项目启动时不报错，但一访问接口就直接连不上数据库：

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/book_mall?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false
    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.bookmall.entity
  configuration:
    map-underscore-to-camel-case: true
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

其中的map-underscore-to-camel-case配置需要注意的是，它会把数据库列名underscore_case自动映射成Java实体里的驼峰字段，比如database列is_default自动映射到isDefault属性，省掉手写ResultMap映射的功夫。开发阶段开启log-impl打印SQL，排查问题时会非常直观。

图书分页查询是动态SQL最典型的应用场景，在Mapper.xml里写这样的代码块，筛选条件全部是可选参数，有条件就拼接，没条件就绕开：

xml复制<select id="selectPage" resultType="com.bookmall.entity.Book">
    SELECT b.*, c.name AS categoryName
    FROM book b
    LEFT JOIN category c ON b.category_id = c.id
    <where>
        <if test="title != null and title != ''">
            AND b.title LIKE CONCAT('%', #{title}, '%')
        </if>
        <if test="categoryId != null">
            AND b.category_id = #{categoryId}
        </if>
        <if test="minPrice != null">
            AND b.price &gt;= #{minPrice}
        </if>
        <if test="maxPrice != null">
            AND b.price &lt;= #{maxPrice}
        </if>
    </where>
    ORDER BY b.id DESC
</select>

这里再强调一个细节：<和>在XML中会被解析成标签符号导致报错，必须用<和>转义。这个坑我亲眼见过不少新手在编译阶段反复报错，一直以为是IDEA的问题，其实只是XML转义没有处理好。

3.3 登录注册与JWT拦截器实现

登录接口的Service层步骤比较固定，接收用户名密码后先根据用户名查询数据库，再用BCrypt验证密码是否匹配，匹配成功后用JWT生成Token返回给前端。注册的时候同样用BCrypt加密后再存库，任何人任何时候都不允许在数据库里明文存密码，这是最基本的底线。

Token校验我单独写了一个JwtInterceptor，实现HandlerInterceptor接口的preHandle方法，对所有带/auth/前缀之外的接口统一拦截。拦截器里我们先取出请求头Authorization字段，去掉“Bearer ”前缀，然后解析Token：

java复制@Component
public class JwtInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        if (!(handler instanceof HandlerMethod)) {
            return true;
        }
        String token = request.getHeader("Authorization");
        if (token != null && token.startsWith("Bearer ")) {
            token = token.substring(7);
            try {
                DecodedJWT jwt = JWT.require(Algorithm.HMAC256(secret)).build().verify(token);
                Integer userId = jwt.getClaim("userId").asInt();
                Integer role = jwt.getClaim("role").asInt();
                request.setAttribute("userId", userId);
                request.setAttribute("role", role);
                return true;
            } catch (Exception e) {
                response.setStatus(401);
                return false;
            }
        } else {
            response.setStatus(401);
            return false;
        }
    }
}

这个拦截器注册到WebMvcConfigurer时留意一下拦截路径的写法。需要放行的有/login、/register、图书列表和详情这种游客也能访问的接口，其余接口全部拦截。通过一遍一遍测试“哪些接口被拦了、哪些没被拦”，你会发现路径匹配顺序并不复杂，只是不排查时容易想当然。

3.4 订单流程：购物车到库存扣减的事务

订单模块是全系统最核心、也最容易出错的环节。我在设计时把下单流程拆成了这样几步，建议把它当成业务实现的模板来看：

1. 前端提交购物车选中项ID列表和收货地址ID；
2. 后端根据购物车ID查出对应商品，并校验这些商品归属当前用户，防止别人串单；
3. 循环判断每本图书的库存是否充足，不够的写入提示信息返回；
4. 生成订单主表记录，计算出总金额；
5. 批量生成订单明细记录；
6. 对所有购买的图书执行库存减量，更新销量字段；
7. 删除对应的购物车记录。

这七个步骤里的第4到第7步必须在一个事务里完成。实际开发中我使用@Transactional注解做声明式事务，一旦中途抛异常，整个订单状态和库存数据都会自动回滚，不会出现“订单建了但库存没减”或者“库存减了但订单没生成”这种数据不一致的场景。这个注解看起来简单，但要记住它默认只对RuntimeException回滚，对编译期异常不回滚，必要时需要指定rollbackFor = Exception.class。

检查库存时还要考虑并发问题。两个人同时抢购同一本书，这里必须用乐观锁或悲观锁来兜底。我在update语句的SQL里加了一个库存字段的条件判断，UPDATE book SET stock = stock - 1 WHERE id=#{bookId} AND stock >= 1，返回影响行数为0就说明库存已不足，这种写法比先查询再修改安全得多。

3.5 事务之外的性能优化细节

图书列表接口做到分页后，基础性能在单机下已经不会有什么大问题，但我还是加了几个很受用的优化点。

MySQL的索引是所有查询性能的基石，需要被高频查询的字段必须建索引。order表里的user_id字段、book表里的category_id字段、order_item表的order_id字段，这些都要建单列索引，否则随着数据量增长，关联查询会退化成全表扫描。

MyBatis一对一联查时可以配置懒加载，但这里我更推荐直接在SQL里写LEFT JOIN一把查完，避免循环查询造成N+1问题。图书详情关联分类、订单明细关联订单，这两个场景在SQL层通过JOIN就能解决，性能没有必要再绕到对象关系转换上去。

PageHelper分页插件一定要在查询执行前开启，分页参数ThreadLocal传递给接下来的第一个SQL，并且只对第一个查询生效。如果页面上需要和分类数据做复杂拼装，一定要记得在查询之前统一设置好参数顺序，分页完后及时调用PageHelper.clearPage()，防止线程复用时参数串到下一个请求。

4. 前端Vue：从环境搭建到整包交付

4.1 Vue工程初始化与路由设计

前端我使用的工具链是Vite + Vue3，比Vue CLI 2那套老工具链启动速度快一个量级。初始化命令如下：

bash复制npm create vite book-mall-web -- --template vue
cd book-mall-web
npm install
npm install vue-router axios element-plus pinia

安装依赖时需要注意Node版本和Vite版本的兼容性，Node 16以下跑Vite 4会提示版本不支持。如果本地正好是旧Node，用nvm切换一下版本，或者改用Vite 3都是可以的，没有必要为了最新版本硬刚环境。

路由结构我拆成两个层级，公开路由和需要登录的路由分离。登录页注册一个独立路由，其他页面全部套在Layout组件下。需要登录保护的路由统一加meta字段标记requiresAuth，路由守卫里判断当前是否有Token以及路由是否标记需登录，没通过就重定向到登录页。

4.2 Axios请求封装与响应拦截

前端请求封装是Vue项目工程质量的关键分水岭。一个完整的axios实例必须做好三件事：基本地址配置、请求头注入Token、统一处理返回码。

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

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

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

service.interceptors.response.use(
    res => {
        const data = res.data
        if (data.code === 200) {
            return data.data
        } else if (data.code === 401) {
            router.push('/login')
            ElMessage.error('登录已过期，请重新登录')
            return Promise.reject(new Error(data.msg))
        } else {
            ElMessage.error(data.msg)
            return Promise.reject(new Error(data.msg))
        }
    },
    error => {
        ElMessage.error('网络异常，请稍后重试')
        return Promise.reject(error)
    }
)

每一行都很关键。baseURL写/api，开发时配合Vite代理转发到后端，上线时可以全局换成正式接口域名；请求拦截器自动给请求带Token，所有页面的请求不需要自己重复设置Authorization；响应拦截器统一处理业务码，页面里再也不用写一大串if else判断逻辑。

4.3 核心页面逻辑：购物车与订单提交

购物车页面看起来只是表格加加减按钮，但实际上它牵涉到一套状态的联动逻辑。选中项变化后实时计算总价，商品数量变化后重新拉取库存做核对，这些状态我用Pinia做全局管理，组件之间共享购物车数据时不需要层层传递props。

订单提交页面的实现流程是：底部结算按钮点击后，把当前选中购物车ID列表提交给后端，后端一次性算好总金额返回订单预览数据，然后用户确认收货地址再点击确认下单按钮。这里两步的拆法有讲究，前端先展示预览让用户知道要付多少钱，用户确认后再次提交后端，中间加了一道安全确认，防止用户在填写地址的间隙订单金额悄悄变化而不知道自己被多扣钱。

图书列表页是一个非常典型的Vue组件化场景。搜索框、分类下拉、价格区间、分页组件拆分独立的子组件，父组件负责聚合数据并请求接口。分类采用级联选择器展示二级分类，选择一级分类时就传一级分类ID，选择二级分类时就传二级分类ID，规则统一，后端查询接口不需要做额外处理。

4.4 把Vue放进SpringBoot统一部署

前后端联调完毕，就到了打包部署这道关。首先在Vue项目根目录执行npm run build，生成的dist文件夹里是全部静态资源。接下来有两种做法：

第一种做法是直接复制dist目录下的所有文件到SpringBoot项目的resources/static目录，重新打包jar后启动，浏览器访问http://localhost:8080/index.html即可看到完整前端。第二种做法是保留前端项目和后端项目分开部署，Vite打包后用Nginx做静态资源服务，再把/api路径做反向代理转发到SpringBoot。这套图书商城的量级，第一种做法足够，还能少维护一个服务器进程。

有一个前端路由的坑必须提醒：Vue Router如果使用history模式，部署到SpringBoot后直接刷新页面或输入URL，会报404，因为Tomcat找不到对应的前端路由路径。解决方式有两种，要么Router改用hash模式，URL会变成#/login这种格式；要么在SpringBoot里添加WebMvcConfigurer配置，将无法匹配的路径全部转发到index.html。这两个方案我选hash模式，服务端代码零改动，最省事。

5. 部署排错实录与踩坑经验总结

5.1 环境初始化与工程启动清单

第一次跑通这套系统，我推荐按以下顺序来准备运行环境，避免东一榔头西一棒子。

第一步安装JDK并配置JAVA_HOME，运行spring-boot:run，确保后端能启动。第二步安装MySQL，建议直接上官方压缩包或dmg安装包，对应MySQL 5.7或8.0。MySQL 8连接驱动必须用com.mysql.cj.jdbc.Driver，同时url中要带上serverTimezone=Asia/Shanghai，否则数据库连接报"The server time zone value"的错误，这类报错光靠搜错误码很容易绕远路。第三步在MySQL中创建book_mall库，导入初始化SQL脚本。第四步启动前端开发服务器，npm run dev。

整个链路跑通的标志是浏览器输入地址后能看到首页图书数据。如果启动步骤按这个顺序来仍然报错，问题基本都集中在端口占用、依赖版本不匹配这两个点上，排查方向非常明确。

5.2 高频问题排查速查表

我把这个项目从开发到部署中反复踩过的坑和对应解法整理成一张速查表，对照排查效率最高：

前四个问题和第五个问题分别对应后端数据访问和前端联调两个阶段，排查时都要配合控制台日志来定位。MyBatis的Mapper绑定异常，绝大多数是因为mybatis.mapper-locations路径写错或namespace不一致引起的，打开target/classes目录查看是否生成了对应的Mapper.xml文件，秒出结论。

5.3 功能测试与数据验证

基本功能测试过程，我强烈建议做成一张checklist，否则到后面改来改去很容易漏掉回归。我的测试执行顺序是先跑核心链路，再跑权限和边界，测试账号分管理员和普通用户两组，场景覆盖如下：

• 使用管理员账号登录，创建图书分类，新增图书并填写库存、价格、封面；
• 退出登录，以游客身份访问图书列表，确认分页和分类筛选项都正常；
• 注册新普通用户，登录后将图书加入购物车，重复加同一本书验证不允许重复加入；
• 修改购物车数量超出库存，确认后端返回“库存不足”提示；
• 提交订单前先不选地址，确认系统提醒用户补全地址；
• 下单成功后查看库存是否减少、订单状态是否为待支付；
• 使用模拟支付接口付款后查看订单状态更新；
• 管理员后台修改订单状态为已发货，用户端能实时看到进度。

这个测试列表里至少一半是“边界场景”，而不是正常流程。因为正常流程怎么跑都通，代码真正容易出问题的就是数量负值、并发重复提交订单、权限越权这些边界点。我建议你在部署完一个版本后，按照这个清单花二十分钟跑一遍，能把绝大多数隐藏Bug提前逼出来。

6. 项目亮点、遗留问题与后续扩展方向

6.1 这套系统做得好的几个点

回看整个系统，我最满意的地方不是技术多么新，而是一整套代码在工程结构和可维护性上做到了“干净”二字。后端Service层没有把大量业务逻辑塞进Controller里，前端API调用全部通过统一封装的请求方法，而不是在每个组件里写碎片化的axios调用。换一个人接手这套源码，只要看一遍目录结构就能定位到想改的代码，这在团队协作里非常值钱。

另一个值得拿出来说的点是小成本高收益的功能细节。电商系统最关键的数据一致性和安全边界，用@Transactional、库存条件更新、JWT拦截器这三板斧就兜住了。没有引入复杂的微服务组件，也没有过度设计，但是核心链路在代码层面是站得住脚的。这套系统的边界承受力也许还够不上一线生产级别，但应付课程设计、个人项目展示和小型真实商城初期，完全能胜任。

6.2 已知的不足与优化方向

做项目最忌惮不肯回头看，我这边再复盘三个明显的短板作为第6部分的改进方向，你可以直接在这个框架上继续深化。

第一个是支付环节目前是模拟支付，真正上线时必须对接微信支付或支付宝沙箱。对接需要处理回调验签、金额核对、超时关闭订单，这套逻辑不复杂但涉及签名和异步通知，接口文档比想象中长。第二个是图书搜索目前只是数据库的LIKE模糊查询，数据量超过10万条时查询速度会明显下降，后续可以考虑引入Elasticsearch或者数据库全文索引。第三个是系统完全没有使用Redis，高频访问的图书分类和热销榜单每次都打到MySQL，对这类读多写少的数据引入Redis缓存后，访问性能会有立竿见影的提升。

6.3 基于现有代码继续扩展的几个建议

如果要在这套源码基础上继续扩展，我个人认为最划算的方向是这几个。第一个方向是接入Redis后顺便把购物车改成Redis存储，用户加购的响应时间会快一个数量级，也能给项目中增加一个面试里常被追问的缓存场景。第二个方向是引入Spring Security替代目前手写的JWT拦截器，这个更契合实际企业项目的鉴权方式，和JWT+拦截器的现有实现对比着看能更好理解框架的封装逻辑。第三个方向是给后台上传图书封面增加一个OSS对象存储，否则图片只能存在本地磁盘，换服务器部署时图片管网就成了麻烦事。

我个人在实际操作中最深的体会是：这种技术栈很标准的项目，代码写出来只是开始，真正拉开差距的是对业务链路的理解和排错的能力。你要是能把订单事务的边界、接口统一返回的约定、前端权限控制这些细节想透，拿这套源码再去改造成任何垂直品类的电商系统，都不会觉得吃力。