SpringBoot2Vue3MyBatis-PlusMySQL8.0 这套技术组合做图书商城系统算是 Java Web 领域里非常典型的全栈练手项目。我最近从头到尾跑通了一个带完整文档的版本把前端、后端、数据库整个链路都过了一遍今天把拆解过程和实操心得完整整理出来给正在做毕设、课程设计或者想系统打通前后端技能的读者一份可以直接参考的路线。这个项目能解决的问题很明确完整演示了电商类系统的核心闭环包括用户注册登录、图书分类浏览、商品检索、购物车管理、订单生成与状态流转以及后台管理功能。它不是那种只搭了个壳子的 demo而是真正把 SpringBoot2 的后端接口、Vue3 的前端交互、MyBatis-Plus 的数据持久化、MySQL8.0 的数据存储串成了一个可运行、可扩展的完整系统。适合的人群也清晰Java 基础扎实但没有完整做过 Web 项目的人准备毕业设计的学生以及想快速cover 一套主流技术栈的初中级开发者。1. 项目整体设计与技术选型思路1.1 为什么是 SpringBoot2 Vue3 这套组合先说技术选型。SpringBoot2 和 Vue3 在这两年几乎成了 Java Web 全栈项目的标准答案原因很实际。SpringBoot2 相比前辈 Spring MVC XML 配置时代优势在于约定大于配置。一个图书商城需要的 Web 层、事务管理、数据源配置、JSON 序列化、参数校验SpringBoot 都能通过 starter 自动装配解决。你在 pom.xml 里引入依赖写一个带SpringBootApplication的入口类一个可运行的 Web 服务就起来了不用再像以前那样花几个小时去琢磨 web.xml、spring-mvc.xml、applicationContext.xml 那一堆配置文件。项目里常用的是 SpringBoot 2.7.x 版本这个版本既保留了 2.x 的稳定生态又对后续升级到 3.x 留了缓冲空间是目前兼容性最稳的选择。Vue3 这边Composition API 带来的代码组织方式变化是核心。相比 Vue2 的 Options APIVue3 的setup语法糖可以把某个功能相关的响应式数据、计算属性、方法逻辑聚在一起组件复杂了以后维护起来明显更顺手。图书商城的首页、商品列表、购物车、结算页这些模块用 Vue3 写起来逻辑更清晰尤其在购物车这种状态频繁变动的页面ref和reactive的组合比 Vue2 的data更灵活。再加上 Element Plus 组件库表格、表单、弹窗、分页这些后台管理界面的常见元素直接拿来用开发效率高一大截。1.2 MyBatis-Plus 与 MySQL8.0 的搭配逻辑MyBatis-Plus 在这个项目里的定位是增强工具。它没有取代 MyBatis而是在 MyBatis 的基础上提供了通用 CRUD、条件构造器、分页插件、代码生成器这些能力。我的体会是MyBatis-Plus 对图书商城这类业务逻辑主要集中在 Service 层的项目尤其合适。比如对图书表的增删改查、对订单表的分页查询用BaseMapper继承省掉了大量重复的 XML 映射编写。图书列表页的复杂筛选条件用QueryWrapper的like、eq、between链式拼接就能解决可读性还比 XML 好。MySQL8.0 的选择则是顺应趋势。8.0 相比 5.7默认字符集变成了 utf8mb4对生僻字和 emoji 支持更好窗口函数、CTE 这些新特性虽然在这个项目里用得不多但为后续扩展留了空间。更重要的是8.0 在 Docker 部署、云数据库支持、性能优化方面都更现代再守着 5.7 没有意义。实际连接时需要注意8.0 的 JDBC 驱动类名是com.mysql.cj.jdbc.DriverURL 里必须带上serverTimezone参数这个细节很容易坑到第一次用 8.0 的人后文我会专门展开。1.3 图书商城项目的模块划分整个系统从功能上可以拆成前台和后台两大部分。前台面向普通用户核心链路是注册登录 → 浏览图书 → 搜索筛选 → 加入购物车 → 提交订单 → 模拟支付 → 查看订单。这个链路模拟了真实电商的核心交易过程每一步都有明确的数据表支撑和状态字段管理。后台面向管理员核心链路是登录验证 → 图书管理新增/编辑/上下架→ 分类管理 → 订单管理发货、完成→ 用户管理。后台功能相对标准化重点在于权限控制和数据统计的可扩展性。模块拆分的核心思想是前后端分离。后端只提供 RESTful API前端通过 axios 调用接口获取 JSON 数据渲染页面。这种架构下前端和后端可以并行开发部署时也可以独立扩展。项目里完整的文档对模块划分讲得很清楚数据库设计文档、接口文档、部署说明都有对新手理解全栈项目结构帮助非常大。2. 数据库设计与核心表结构2.1 从业务需求反推表设计我做这个项目时第一步不是写代码而是先把数据库表设计出来。图书商城这种业务表结构相对成熟但我建议你不要直接照抄任何人的建表 SQL而是从业务需求出发自己推一遍。先梳理实体关系用户、图书、分类、购物车项、订单、订单详情。这六个实体几乎可以覆盖所有核心需求。用户表存储账号密码、昵称、联系方式、地址图书表存储书名、作者、ISBN、价格、库存、封面图、简介、上下架状态分类表存储分类名称、父级分类、排序购物车表存储用户 ID、图书 ID、数量、加入时间订单表存储订单号、用户 ID、总金额、状态、收货信息、下单时间订单详情表存储订单 ID、图书 ID、图书名称快照、单价、数量关键设计点有两个。第一个是图书名称快照这个概念。订单详情里必须冗余存储图书的名称和下单时的单价不能只存图书 ID因为图书价格后续可能调整如果订单详情里只存 ID历史订单显示的价格就全乱了。第二个是订单和购物车的关系提交订单时把购物车中选中的商品复制到订单详情表然后清空对应购物车项这个逻辑要保证事务性。2.2 关键表结构和字段设计细节我直接把核心易错点拿出来说。用户表密码字段用VARCHAR(255)而不是更短的VARCHAR(60)因为项目一般用 BCrypt 加密同一次注册、同一个密码每次生成的密文长度都是 60 个字符如果用 50 就可能存储失败。我踩过这个坑后来统一扩展成了 255。状态字段status用TINYINT1 表示启用0 表示禁用默认值 1。图书表的price字段我建议用DECIMAL(10,2)而不是FLOAT或DOUBLE。浮点类型在 MySQL 中存储金额会出现精度丢失比如 19.9 存入后可能变成 19.899999。DECIMAL是定点数按字符串存储能精确表示到分位。库存字段stock用INT注意区分库存和可售量的概念有些项目会把锁定库存和实际库存分开这里简单处理就先不拆了但如果后续要做秒杀或者高并发扣库存就要考虑单独设计。订单表是重点。订单号order_no用VARCHAR(32)生成规则建议用yyyyMMddHHmmss加随机数避免直接暴露自增 ID。总金额total_amount也用DECIMAL(10,2)。状态字段status存TINYINT0 待付款1 已付款待发货2 已发货3 已完成4 已取消。收货信息里如果可能有多地址需求可以用单独的表但简单项目直接在订单表里冗余receiver_name、receiver_phone、receiver_address字段就够了。2.3 主键策略与公共字段处理MyBatis-Plus 对主键和公共字段有很好的支持。主键策略我建议都用IdType.ASSIGN_ID这是雪花 ID 生成方式在分布式环境下也能保证全局唯一不会像AUTO_INCREMENT那样在分库分表场景下失效。这样做还有一个好处前端可以提前拿到 ID方便后续操作。公共字段用 MyBatis-Plus 的自动填充功能处理。比如每个表的create_time和update_time如果在每个 INSERT、UPDATE 的 mapper 方法里都手动赋值代码会非常啰嗦。在实体类的字段上加上TableField(fill FieldFill.INSERT)和TableField(fill FieldFill.INSERT_UPDATE)注解然后实现一个MetaObjectHandler在 insert 和 update 方法里统一赋值LocalDateTime.now()所有表的创建和更新时间就都能自动维护了。这里提一句create_time的类型选择。我用的是DATETIME类型对应 Java 的LocalDateTime。不用TIMESTAMP因为TIMESTAMP有 2038 年问题而且受时区影响大。DATETIME就是一个纯粹的日期时间值不受会话时区影响做电商订单这类业务更安全。3. 后端核心功能实现解析3.1 登录鉴权JWT 拦截器图书商城系统里前台用户登录、后台管理员登录、接口权限控制这三个逻辑是必须理清的。我用的是 JWT 拦截器的方案没有引入 Spring Security因为图书商城这个权限模型比较简单用安全框架反而增加学习成本。JWT 的流程是这样的用户登录成功后后端生成一个 token 返回给前端。token 里封装了用户 ID、用户名、角色USER 或 ADMIN设置过期时间。前端拿到 token 后存储在 localStorage 里每次请求时在 axios 拦截器中加到Authorization头。后端写一个拦截器对需要登录的接口路径进行拦截解析 token如果解析失败或过期就返回 401 状态码。核心代码大致是这样Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (StringUtils.isNotBlank(token) token.startsWith(Bearer )) { token token.substring(7); try { Claims claims Jwts.parser() .setSigningKey(your-secret-key) .parseClaimsJws(token) .getBody(); request.setAttribute(userId, claims.get(userId)); return true; } catch (Exception e) { response.setStatus(401); response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\msg\:\登录已过期请重新登录\}); return false; } } response.setStatus(401); response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:401,\msg\:\未登录\}); return false; } }在配置类中注册拦截器时要注意放行路径的设置。/api/user/login、/api/user/register、/api/books/**前台浏览不需要登录要放行/api/admin/**这种后台接口则需要拦截而且最好再判断角色。我把前台的/api/user/**和后台的/api/admin/**分开管理逻辑更清晰。3.2 图书检索与分页查询图书列表页是整个系统访问量最大的接口设计上要考虑查询效率和参数扩展性。用 MyBatis-Plus 的分页插件第一步在配置类里添加PaginationInnerInterceptor注意配置 MySQL 方言第二步在 Service 层使用PageBook接收参数。实际查询时前端会传这几个参数keyword关键字模糊匹配书名或作者、categoryId分类、minPrice和maxPrice价格区间、sort排序字段、pageNum和pageSize分页。Service 层代码大概这样public PageResultBook queryBooks(String keyword, Long categoryId, BigDecimal minPrice, BigDecimal maxPrice, String sort, int pageNum, int pageSize) { PageBook page new Page(pageNum, pageSize); LambdaQueryWrapperBook wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.isNotBlank(keyword), Book::getTitle, keyword) .or(StringUtils.isNotBlank(keyword), w - w.like(Book::getAuthor, keyword)) .eq(categoryId ! null, Book::getCategoryId, categoryId) .ge(minPrice ! null, Book::getPrice, minPrice) .le(maxPrice ! null, Book::getPrice, maxPrice) .eq(Book::getStatus, 1) // 只查询上架图书 .orderByDesc(1.equals(sort), Book::getSales) .orderByDesc(2.equals(sort), Book::getCreateTime); bookMapper.selectPage(page, wrapper); return new PageResult(page.getRecords(), page.getTotal(), page.getCurrent(), page.getSize()); }这里有个优化经验关键字模糊查询用LIKE在数据量大时可能慢但图书商城这个量级完全够用先不考虑 Elasticsearch 或全文索引。后续如果要优化可以在title和author上建索引或者引入FULLTEXT索引。前端页面的搜索逻辑我用了一个防抖函数用户停止输入 300ms 后才发起请求避免每敲一个字就打一次接口。3.3 购物车与订单状态机购物车和订单关联紧密我用一个 Service 方法处理提交订单事务。购物车表里存了user_id、book_id、quantity、checked字段。前端购物车页面可以对商品勾选或不勾选结算时只提交勾选的商品。提交订单的 Service 方法需要加Transactional注解这是关键。因为涉及多张表的写操作插入订单主表、批量插入订单详情、扣减图书库存、清空购物车中已购商品。任何一个环节失败数据都会不一致。扣减库存的代码要特别注意并发问题。简单做法是 SQL 中加条件判断this.update(new LambdaUpdateWrapperBook() .setSql(stock stock - quantity) .eq(Book::getId, bookId) .ge(Book::getStock, quantity));这样即使两个用户同时下单最后一本书也只有一个请求能成功更新另一个受影响行数为 0事务回滚前端提示库存不足。订单状态流转我用了状态机思想从待付款到已付款、已发货、已完成每一步都有前置状态校验。用户取消订单时如果订单是待付款状态要回补库存这也是一个容易遗漏的点。我在写的时候就遇到过订单取消后库存没恢复的 bug排查了半天才想起来回补逻辑没写。3.4 文件上传与静态资源映射图书封面图上传这个功能看起来简单踩坑却不少。后端接收MultipartFile保存到一个指定目录比如D:/book-mall/upload/然后把文件的访问路径存到数据库比如/upload/xxx.jpg。为了让这个路径能通过 URL 访问SpringBoot 里需要配置静态资源映射Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceHandler(file:D:/book-mall/upload/); } }特别注意跨平台问题。Windows 下路径用D:/book-mall/upload/Linux 下就要改成/usr/book-mall/upload/。我建议写配置项放到application.yml里例如在里面定义upload.path部署不同环境时改配置就行不要写死在代码里。关于存储文件名我推荐用 UUID 加时间戳的方式重命名避免中文文件名乱码和重名覆盖问题。前端上传用 Element Plus 的el-upload组件要注意action属性必须指向后端接口地址name属性要和后端接收的MultipartFile参数名一致默认是file保持一致就不用额外改了。上传组件其实我用的是http-request自定义上传方法这样方便在 axios 实例上统一带上 token。4. 前端 Vue3 落地实践4.1 工程结构搭建前端工程我用的 Vite 创建相比 Webpack启动速度快配置也简洁。创建命令npm create vitelatest book-mall-frontend -- --template vue npm install npm install vue-router4 pinia axios element-plus sass工程结构按照功能划分清晰易扩展src/ ├── api/ # 接口请求封装 │ ├── book.js │ ├── order.js │ ├── user.js │ └── cart.js ├── components/ # 通用组件 ├── router/ # 路由配置 ├── stores/ # Pinia 状态管理 ├── views/ # 页面组件 │ ├── home/ │ ├── book/ │ ├── cart/ │ └── admin/ ├── utils/ │ ├── request.js # axios 封装 │ └── auth.js # token 管理 └── App.vueVue3 中组件通信方式和 Vue2 变化很大。简单场景用props和$emit跨组件状态用provide/inject全局状态用 Pinia。我这套代码里购物车数量这种全局性状态放 Pinia用户信息也放 Pinia刷新页面时再从 localStorage 恢复。其他的像图书列表页到图书详情页用路由参数传 ID 就行不引入多余的组件通信。4.2 axios 封装与接口对接axios 封装是每个 Vue 项目都必须做好的基础工作。核心是给所有请求统一加上 token统一处理错误码统一加载状态。import axios from axios import { ElMessage } from element-plus import { useUserStore } from /stores/user import router from /router const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const userStore useUserStore() if (userStore.token) { config.headers.Authorization Bearer userStore.token } return config }) request.interceptors.response.use( response { const res response.data if (res.code 200) { return res } if (res.code 401) { userStore.logout() router.push(/login) ElMessage.error(登录已过期请重新登录) } ElMessage.error(res.msg || 请求失败) return Promise.reject(new Error(res.msg)) }, error { ElMessage.error(error.message || 网络异常) return Promise.reject(error) } ) export default request这里有个跨域配合问题。前后端分离开发时前端访问http://localhost:5173后端接口在http://localhost:8080浏览器会因为跨域拦截请求。后端处理跨域可以在配置类里加CorsFilter也可以前端走 Vite 代理。我推荐开发环境用 Vite 代理这样浏览器请求不跨域后端不用额外处理生产环境用 Nginx 反向代理前端和后端部署在同一域名下天然没有跨域问题。4.3 状态管理与路由守卫Pinia 项目里主要管理三个模块user用户信息、token、登录状态、cart购物车数量、商品列表、app全局状态。购物车数量这个 state我在登录后拉取一次加入购物车成功后立即cartStore.setCount()更新。刷新页面时Pinia 状态会重置需要从接口重新拉取所以在App.vue的onMounted里做一次恢复操作。路由守卫这块登录保护是必须的。前端路由表把需要登录的页面放在特定 meta 下beforeEach拦截时判断用户 tokenrouter.beforeEach((to, from, next) { const userStore useUserStore() if (to.meta.requiresAuth !userStore.token) { next({ path: /login, query: { redirect: to.fullPath } }) } else { next() } })登录成功后跳转到redirect参数指向的页面这样用户体验比较友好不会登录后丢失本来想去的页面。后台管理页除了登录校验还加了一层角色校验to.meta.role ADMIN如果 token 对应的是普通用户直接踢回首页并提示无权限。5. 环境搭建与本地部署实操5.1 后端环境配置后端本地运行所需环境JDK 8 或 11我用的是 JDK 1.8因为 SpringBoot 2.7 官方最低支持 Java 8Maven 3.6MySQL 8.0本地直接安装或者 Docker 起一个开发工具推荐 IDEA社区版就够用拿到源码后第一步修改application.yml里的数据库连接配置。注意 MySQL8.0 的 JDBC URL 必须带serverTimezone否则启动时报时区错误spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/book_mall?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your-password第二步入 IDEA 的时候设置 Maven 仓库推荐使用阿里云镜像不然首次mvn install拉依赖会非常痛苦。mirror idaliyunmaven/id mirrorOf*/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url /mirror第三步导入数据库。把源码里的book_mall.sql一般都在sql或docs目录下用 Navicat 或命令行执行。命令行导入的方式是mysql -u root -p book_mall.sql导入后检查表是否齐全我用的是SHOW TABLES;验证。还要注意初始管理员账号和密码通常在 SQL 文件里就能看到注释项目文档里也会写清楚我用文档里给的管理员账号登录省得重新去数据库里查。5.2 MySQL8.0 配置细节MySQL8.0 安装后有几个坑非常普遍。第一个是字符集。MySQL8.0 默认字符集就是 utf8mb4但如果你是从 5.7 升级来的老库可能还是 utf8。建库时建议显式指定CREATE DATABASE book_mall DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;用 Navicat 建库时也能选字符集记得选 utf8mb4。我之前遇到中文乱码问题排查到最后就是建库时用了默认的 latin1 字符集。第二个是密码加密方式。MySQL8.0 默认的caching_sha2_password在一些老版本客户端里不被支持报错是Authentication plugin caching_sha2_password cannot be loaded。我用的 Navicat 版本比较新没遇到这个问题但如果你用老版本连接工具可能需要改回mysql_native_passwordALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY your-password;第三个是时区问题。MySQL 连接 URL 里如果不加serverTimezoneAsia/ShanghaiJDBC 驱动会报类似The server time zone value й׼ʱ is unrecognized的错误。加上参数就好。如果后端时区不对会出现时间差 8 小时这种诡异问题排查起来也容易蒙圈。5.3 前后端启动流程完整启动分为三步。第一步启动 MySQL确保服务运行中数据库已经导入。用mysql -u root -p能连接就说明没问题。第二步启动后端。IDEA 里找到入口类BookMallApplication直接运行 main 方法。启动成功后控制台会打印 SpringBoot 的 banner显示 Tomcat 启动在 8080 端口。看到类似Started BookMallApplication in 5.32 seconds的日志就说明启动成功。可以用 Postman 简单测下接口比如GET http://localhost:8080/api/books?pageNum1pageSize10返回 JSON 数据就是正常的。第三步启动前端。命令行进入book-mall-frontend目录先执行npm install因为项目用了 Element Plus、axios、Pinia 等依赖安装可能需要几分钟。装完后执行npm run devVite 默认跑在 5173 端口浏览器打开http://localhost:5173就能访问系统。如果前端请求能正常返回数据就说明前后端联调通了。部署上线的话前端执行npm run build生成dist目录后端执行mvn clean package生成 jar 包再把 jar 包和dist静态文件放到服务器上用 Nginx 做反向代理。注意后端部署时上传文件的路径、数据库连接信息都要改到生产环境对应配置。6. 常见问题与排查技巧实录6.1 数据库连接类问题这类问题在首次运行项目时出现频率最高报错信息也五花八门。我把典型的几种情况列成了一张速查表。报错现象根本原因解决方案Driver com.mysql.cj.jdbc.Driver not found驱动依赖没引入或版本不对检查 pom.xml 中 mysql-connector-java 依赖SpringBoot 2.7 一般用com.mysql:mysql-connector-j或mysql:mysql-connector-java8.0.33Connection refusedMySQL 没启动或端口不是 3306检查 MySQL 服务状态netstat -ano | findstr 3306查看端口监听Unknown database book_mall数据库没创建或名字不对执行CREATE DATABASE book_mall;注意大小写Access denied for user rootlocalhost用户名或密码错误检查application.yml中的密码确认 MySQL 中 root 密码Public Key Retrieval is not allowed8.0 的 allowPublicKeyRetrieval 设置URL 参数加allowPublicKeyRetrievaltrueuseSSLfalse还有个比较隐蔽的坑是数据库版本和驱动版本不匹配。MySQL8.0 的库用 5.x 的驱动连接会报Communications link failure或者其他奇怪的通讯异常。检查依赖里 mysql 驱动版本是不是 8.x只看pom.xml里mysql-connector-java的版本号就行。6.2 前端依赖与跨域问题前端跑不起来多数是 Node 环境和依赖安装的问题。Node 版本过旧会导致 Vite 启动报错。Vite 3 要求 Node 14.18Vite 4 要求 Node 16。用node -v检查版本不满足要求的先去官网装新版本。npm install安装慢或失败可以把 npm 源切到国内镜像npm config set registry https://registry.npmmirror.com如果你用的是 sass很容易碰到二进制编译失败的问题。项目安装的是sassDart Sass 版本不要装成node-sassnode-sass 在不同 Node 版本之间兼容性极差当年 Vue2 项目里我吃了不少这个亏。如果你发现package.json里有node-sass直接改成npm uninstall node-sass npm install -D sass前端能显示页面但接口全报错第一条排查思路是看浏览器开发者工具里的 Console 和 Network。Network 里请求如果状态码是 404说明接口路径没对上如果是 405可能是 GET/POST 请求方式不一致如果是 401大概率 token 没带上或已过期。跨域问题在开发环境表现最典型浏览器 Console 报CORS policy错误。排查思路分两步确认后端是否配置了CorsFilter同时检查前端 Vite 代理配置是否生效。vite.config.js里示例server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }配置完代理记得重启npm run dev改了 Vite 配置不会热更新。6.3 MyBatis-Plus 使用细节MyBatis-Plus 用起来方便但不小心踩坑也很憋屈。第一个坑是逻辑删除配置。如果表里配了TableLogic注解的deleted字段所有查询都会自动带上deleted0条件如果你在 Service 代码里又手动写了eq(Book::getDeleted, 0)查询还正常但如果你要查所有数据包括已删除的用默认方法就查不出来此时需要.ignoreLogicDelete()方法不同版本 API 略有差异。图书上下架用逻辑删除不太合适我建议用status字段控制删除操作也改成把status置为 0避免逻辑删除带来的统计口径混乱。第二个坑是分页插件不生效。如果只引入依赖没注册 BeanselectPage会得到所有数据而page.getTotal()返回 0。检查配置类Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }这个 Interceptor 必须注册为 Spring Bean不注册分页SQL的LIMIT语句就不会被自动拼接。第三个坑是updateById的空字段不更新。MyBatis-Plus 默认更新策略是字段为 null 时不更新这在图书编辑场景下很容易出问题。比如编辑图书时表单没填某个字段提交后这个字段就保持旧值这符合预期但如果你想把一个字段显式清空为 null默认策略就不生效。处理方式是标记TableField(updateStrategy FieldStrategy.IGNORED)或者用LambdaUpdateWrapper的.set(Book::getDescription, null)显式改。6.4 前后端联调其他常见坑购物车数量不同步这个点很典型。用户加入购物车后前端顶部导航的购物车角标如果不立即更新用户就会疑惑是不是没加成功。我的做法是在点击加入购物车成功后调用一次cartStore.setCount()同时把侧边栏的购物车列表缓存清掉下次进入购物车页面时重新拉取最新数据。订单提交重复点击导致的重复订单问题。用户连续点两次提交订单按钮会生成两个订单。前端可以在提交中状态禁用按钮后端更好的做法是幂等处理比如前端生成一个唯一的requestIdUUID后端在订单表里记录这个requestId并建唯一索引重复请求会被数据库拦截。书籍库存扣减后已取消的订单要做好回补逻辑我已提到了但再强调一遍订单取消这个方法里要更新库存。图片不显示的问题路径问题居多。前端请求/upload/xxx.jpg后端要能映射到文件系统的目录。如果用了 Nginx 部署需要在 Nginx 配置里加location /upload/ { alias /usr/book-mall/upload/; }不配置这个生产环境图片加载就是 404。本地开发时检查application.yml里配置的上传路径和实际保存路径是否一致。7. 二次开发与扩展方向7.1 支付、评论、推荐图书商城做完基础闭环后扩展空间非常大。第一位值得做的是评论系统。现在很多订单完成后就没有后续参与了加一个评价功能用户可以对订单项评分和发表文字评论。表结构新增book_comment表关联用户和图书前台列表页展示评价数量和评分提高信息可信度和活跃度。支付对接可以考虑沙箱模式。真实对接支付宝或微信支付需要企业资质个人学习者可以先接一个模拟支付接口把支付流程走通。我建议是后端增加一个payOrder接口前端传订单号和支付方式后端把订单状态从待付款改为已付款并记录支付时间这个流程核心是理解支付回调的概念为将来对接真实支付做好接口准备。推荐系统是加分项。简单版可以做猜你喜欢根据用户历史订单中的图书分类统计用户偏好分类推荐同分类下销量高的图书。这不涉及复杂的协同过滤算法一条 SQL 加一个推荐 Service 就能实现但体验提升很明显。进阶一点的可以考虑用户行为埋点记录浏览记录再推荐这个就属于真正推荐系统的入门了。7.2 性能优化与部署上线项目如果只是本机跑着玩不需要优化。但如果想部署上线有几个点一定要提前考虑。后端数据库连接池默认用的是 HikariCP配置时可以调整最大连接数和连接超时时间。图书商城并发不大默认值就够了但要注意生产环境的 MySQL 连接池上限不能超过数据库本身允许的最大连接数不然会报连不上的错误。前端性能方面我建议开发环境下用 Vite 代理生产环境构建产物dist后用 Nginx 托管。npm run build后看产物体积Element Plus 全局引入打出来的包会很大可以改成按需引入按需引入需要配置unplugin-vue-components和unplugin-auto-import插件能瘦身不少。图片资源用 CDN 或压缩插件优化页面首屏加载速度能明显提升。部署层面后端用 jar 包方式运行配合 systemd 服务管理或者 Docker 容器化都行。容器化的话写一个Dockerfile基础镜像用openjdk:8-jdk-alpine把 jar 包放进去。前端用 Nginx 容器的做法也比较成熟。数据库可以独立容器运行也可以直接用云数据库。这个扩展方向对理解现代云原生部署非常有帮助。我在实际使用中发现这个项目最有价值的地方不在于代码本身有多炫而在于它把一套主流的全栈技术栈如何协同工作展示得很完整。跟着跑通一遍前后端交互、数据库设计、鉴权流程、状态管理、部署路径这些知识点都会有一个体系化的认识。特别是那些报错和排查过程才是成长最快的地方。如果正处在学习 Java Web 的爬坡阶段手头又没有完整的项目经验这个项目值得认真过一遍代码跑通之后再往里面加自己的功能模块才算真正吃透了。