SpringBoot+Vue网上书店实战：订单设计与前后端联调避坑指南

简介：这是一份基于SpringBoot和Vue开发的网上书店项目，包含完整后端源码、前端页面、SQL数据库脚本及部署说明文档，适合计算机相关专业学生作为毕业设计、课程设计或项目练手。项目采用前后端分离架构，后端涵盖Spring Boot框架、Jpa持久层和Shiro安全控制，前端使用Vue、ElementUI和Axios完成页面与数据交互；MySQL负责业务数据存储，Redis提供缓存加速，阿里云对象存储处理文件上传，技术栈贴近企业实际开发。其中bookshop目录为已打包前端静态资源的后端工程，可独立运行于8443端口，方便快速启动验证；压缩包共105个文件，以Java源码、Vue组件、SQL脚本、配置文件和Markdown文档为主，大小仅2.7MB，并附有README说明，便于快速理解项目结构和环境配置。借助源码和数据库脚本，可以理解网上书店从图书展示、购物车到订单处理的模块设计，也能掌握Spring Data Jpa的数据操作、Shiro权限认证、Redis缓存以及OSS对象存储等集成方法，并在此基础上二次开发完成毕设或课设，整体代码结构清晰，便于按模块查阅。资源已在实际测试中运行成功，已有143人学习下载，适合需要了解前后端分离应用开发的读者参考。

1. 网上书店项目为什么值得自己搭一套：从技术选型到交付物边界

基于SpringBoot和Vue开发的网上书店，看起来就是个老生常谈的全栈项目，真正动手才知道深浅。说它普通，是因为功能无非是图书展示、购物车、下单、登录这几件事；说它不普通，是因为订单表怎么拆、前后端联调时跨域和鉴权怎么处理、数据库sql脚本能不能直接跑起来，直接决定这堆代码是一个能交付的系统还是一堆没法运行的文件。这个项目附带源代码、文档说明和数据库sql，适合三类人：学完基础想补完整项目经验的初学者、需要毕业设计选题的同学、以及想给团队内部搭一个图书管理小系统的一线开发。这些年我带新人做过不少次这个方向，最大的体感是：写CRUD谁都会，真正让项目翻车的永远是订单设计和联调阶段的玄学。

2. SpringBoot后端骨架：从项目结构到图书、订单、用户三个核心模块

网上书店的后端要撑起三件事：图书展示、下单交易、用户登录。拆开看就是商品模块、订单模块、账号模块。新人最容易犯的错是把代码全堆在Controller里，一个类上千行，改需求时牵一发动全身。我习惯把Controller写得越薄越好，业务规则往下沉到Service，数据操作留在Mapper，这样才能让后来接手的人快速定位问题。

2.1 后端项目结构怎么摆：controller/service/mapper 分层的取舍

网上书店这种规模，我不是很建议上DDD那套复杂分层。核心业务量不大，分层太深反而让初学者晕头转向。常见的SpringBoot web项目结构目录是controller、service、mapper、entity四层再加config、dto、common几个辅助包。一个标准的结构长下面这样：

com.example.bookstore ├── BookstoreApplication.java ├── config │ ├── CorsConfig.java │ └── MybatisPlusConfig.java ├── controller │ ├── BookController.java │ ├── OrderController.java │ └── UserController.java ├── service │ ├── BookService.java │ ├── OrderService.java │ └── UserService.java ├── mapper │ ├── BookMapper.java │ ├── OrderMapper.java │ └── UserMapper.java ├── entity │ ├── Book.java │ ├── Order.java │ ├── OrderItem.java │ └── User.java ├── dto │ ├── LoginRequest.java │ └── OrderCreateRequest.java └── common └── Result.java

Controller只做参数接收和结果包装，Service放业务规则，Mapper做数据库操作。entity对象对应数据库表，dto对象用来接收前端参数，不要把请求体直接绑定到entity上，否则前端多传一个字段就可能污染数据库。common包里的Result是统一返回结构，前端axios拦截器只认这一种结构，能省掉很多格式不一致的破事。参数说明：这里的包名是com.example.bookstore，你可以按自己公司域名反写来改；如果你用的是MyBatis XML版本，mapper包下还要在resources里建对应的BookMapper.xml，注意XML里的命名空间要和Mapper接口全限定名一致。

2.2 用 MyBatis-Plus 还是 JPA：网上书店这种业务我选哪个

这是后端选型时最常被问到的二选一。JPA上手快，单表CRUD不用写SQL，但一旦涉及多表关联、动态条件分页，要么遇到N+1查询，要么写JPQL绕半天。MyBatis-Plus在国内项目里更稳，单表CRUD已经封装好，复杂查询直接写XML，排查问题时看SQL日志一眼就能定位。我一般选MyBatis-Plus，不是因为它多高级，而是带新人时，出错能从控制台打印的SQL里直接看出来。

对应到pom.xml，只需要加两个依赖：

<dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency>

注意：如果你用的SpringBoot版本太高，比如到了3.x，而MyBatis-Plus还停在3.5.x老版本，启动时会因为循环依赖报错。这时候要么换用mybatis-plus-spring-boot3-starter这个专用starter，要么把SpringBoot版本降回2.x。网上书店项目不需要追新，稳定跑通最重要。参数说明：3.5.3是我用过的一个稳定版本，实际使用时建议去仓库看一眼当前release，别拿最新版本号直接跑，兼容性问题会让你怀疑人生。

2.3 图书分页、下单、登录鉴权：三个接口把后端骨架串起来

这三个接口正好对应网上书店的三条主链路：用户逛书店、用户下单、用户身份认证。先看图书分页，用MyBatis-Plus的Page对象很省事：

@RestController @RequestMapping("/api/book") public class BookController { @Resource private BookService bookService; @GetMapping("/page") public Result page(@RequestParam(defaultValue = "1") Integer page, @RequestParam(defaultValue = "10") Integer size, @RequestParam(required = false) String keyword) { Page<Book> p = new Page<>(page, size); LambdaQueryWrapper<Book> wrapper = new LambdaQueryWrapper<>(); if (keyword != null && !keyword.isBlank()) { wrapper.like(Book::getTitle, keyword).or().like(Book::getAuthor, keyword); } wrapper.orderByDesc(Book::getCreateTime); return Result.success(bookService.page(p, wrapper)); } }

page和size从URL传入，keyword是可选参数。用LambdaQueryWrapper构造动态条件，这样前端传不传关键词都能走同一个方法。orderByDesc按上架时间倒序排，新书在前面。参数说明：defaultValue = "1"和"10"表示前端不传时默认第一页、一页十条。注意MyBatis-Plus的分页必须配置PaginationInnerInterceptor插件，否则page方法会退化成查出全表再内存分页，数据量一大就卡死。

再看下单接口。我这里把下单拆成Controller和Service两步，Controller只负责拿当前登录用户和请求里的订单数据：

@PostMapping("/order") public Result createOrder(@RequestBody OrderCreateRequest req, HttpServletRequest request) { Long userId = (Long) request.getAttribute("userId"); Long orderId = orderService.createOrder(userId, req.getBookIds(), req.getAddressId()); return Result.success(orderId); }

userId是从request attribute里取的，由JWT拦截器在解析Token之后放进去。不要在Service里再次解析Token，否则一次请求要解两次，而且过滤器链的顺序容易出问题。参数说明：OrderCreateRequest里至少有bookIds、addressId两个字段。bookIds是用户勾选的图书id列表，addressId对应收货地址表。Service里要做库存校验、计算总价、生成订单号，并且用@Transactional把减库存和生成订单包在同一个事务里。

登录鉴权用JWT，最常见的做法是下面这种：

@PostMapping("/login") public Result login(@RequestBody LoginRequest req) { User user = userService.checkLogin(req.getUsername(), req.getPassword()); if (user == null) { return Result.error("用户名或密码错误"); } String token = jwtUtil.createToken(user.getId()); return Result.success(token); }

checkLogin里会对密码做加盐加密后比对，不能存明文。登录成功返回一串token，前端后续请求都带着它。这个环节最阴间的坑是：请求还没进Controller就被拦截器拦截了，所以拦截器的excludePathPatterns必须放行/login，还要放行不登录就能看的图书接口。这个在避坑章节里详细说。

这三段代码串联起来，就是网上书店的后端主线。书城首页和搜索页靠/page，购物车结算靠/order，个人中心靠/login。另外要注意统一返回的Result类，里面的字段结构要保持稳定，我习惯是code为0表示成功，非0表示失败，message给用户看，data放数据。这个约定写进文档说明的前几页，比在代码里到处加注释有用得多。

3. Vue前端实现网上书店：路由、组件和购物车状态

前端做的事比后端看起来琐碎得多。用户从书架点进详情，加入购物车，结算下单，每一步都涉及跨页面状态共享，这也是Vue项目最容易被写乱的地方。如果把购物车数据只放在某个组件的data里，刷新页面就丢，联调时后端怎么说都白搭。

3.1 从vue-router开始：前端页面骨架和路由守卫

网上书店的前端页面最少要有登录页、图书列表页、购物车页、订单列表页。用vue-router管理页面跳转，并且把需要登录才能访问的页面用路由守卫保护起来：

// src/router/index.js import { createRouter, createWebHistory } from 'vue-router' const routes = [ { path: '/login', component: () => import('../views/Login.vue') }, { path: '/', redirect: '/books' }, { path: '/books', component: () => import('../views/BookList.vue') }, { path: '/cart', component: () => import('../views/Cart.vue'), meta: { requiresAuth: true } }, { path: '/orders', component: () => import('../views/OrderList.vue'), meta: { requiresAuth: true } } ] const router = createRouter({ history: createWebHistory(), routes }) router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.meta.requiresAuth && !token) { next('/login') } else { next() } }) export default router

这里的关键是把requiresAuth写在meta里，而不是在代码里用字符串比对路径。好处是页面越来越多时，路由守卫只需要关心这个标记，不用维护一份路径清单。token存在localStorage里，关掉浏览器再打开还在，比sessionStorage更像一个“记住登录状态”的体验。参数说明：createWebHistory是HTML5 history模式，路径干净，但部署到Nginx需要配置try_files，否则刷新子路由会404。如果不想折腾，直接改成createWebHashHistory，URL带#号但省心，适合先跑通功能的场景。

3.2 图书列表与购物车：组件拆分和状态管理

图书列表是网上书店的门面。我用Element Plus的el-card把每本书渲染成卡片，组件内部只做展示和触发事件，数据请求单独放到api目录里：

<template> <div class="book-list"> <el-card v-for="book in books" :key="book.id" class="book-item"> <el-image :src="book.cover" fit="cover" /> <div class="info"> <h3>{{ book.title }}</h3> <p class="author">{{ book.author }}</p> <p class="price">￥{{ book.price }}</p> <el-button type="primary" @click="addToCart(book)">加入购物车</el-button> </div> </el-card> </div> </template> <script setup> import { ref, onMounted } from 'vue' import { ElMessage } from 'element-plus' import { listBooks } from '../api/book' import { addCartItem } from '../api/cart' const books = ref([]) const loading = ref(false) onMounted(async () => { loading.value = true const res = await listBooks({ page: 1, size: 12 }) books.value = res.data.records loading.value = false }) const addToCart = async (book) => { await addCartItem({ bookId: book.id, count: 1 }) ElMessage.success('已加入购物车') } </script>

listBooks和addCartItem是api目录里封装好的axios函数，组件里不直接写axios，方便统一处理token和错误码。分页size传12，因为书城首页一般做成一行四本、三行的网格；管理后台改成10条一页更自然。addToCart成功后只弹提示不跳转，用户能连续加购，这是电商前台的习惯。注意购物车数量要与用户绑定，这部分由后端把userId取出来关联，前端只管bookId。

购物车这种跨组件、跨页面的状态，我用Pinia。网上书店的购物车数据必须以后端为准，store里主要存当前用户最新列表和计算好的总价：

// store/cart.js import { defineStore } from 'pinia' export const useCartStore = defineStore('cart', { state: () => ({ items: [] }), getters: { totalPrice: (state) => state.items.reduce((sum, i) => sum + i.price * i.count, 0) }, actions: { setItems(items) { this.items = items } } })

totalPrice用getter派生，组件里直接读store.cart.totalPrice，不要在多个页面里各算各的，否则价格来源不统一。setItems方法在登录、结算后调用，比如加入购物车成功后重新拉一次购物车列表再setItems刷新。如果你接手的是Vue2项目，Vuex的写法也类似，state、getters、actions这些概念都能平移，迁移成本不高。

3.3 把Vue项目打包部署：Nginx静态资源还是打进SpringBoot

网上书店前端开发时跑在Vite的5173端口，后端跑在8080端口，联调走的是代理或CORS。部署时常见做法是先把前端构建成静态文件，再交给Nginx托管：

npm run build

构建完成后默认输出到dist目录。把dist目录里的内容放到Nginx指定的站点目录，并配置API反向代理：

server { listen 80; server_name your-domain.com; location /api/ { proxy_pass http://127.0.0.1:8080/api/; } location / { root /var/www/bookstore; try_files $uri $uri/ /index.html; } }

/api/开头的请求转发到SpringBoot接口，其他路径返回前端页面。try_files是解决history路由刷新404的关键，它让Nginx在找不到具体文件时回退到index.html，交给Vue Router处理。参数说明：如果前端和后端不在同一台机器，把127.0.0.1:8080改成后端服务器地址。另一种做法是把dist里的文件复制到SpringBoot的src/main/resources/static目录，然后后端直接打成单jar包，这种做法适合不想单独维护Nginx的场景，但下一次前端发版还得重新打后端包，我一般只在演示项目里用。

4. 数据库SQL脚本设计：从ER图到建表语句，订单系统是分水岭

网上书店的数据库sql脚本能不能一次跑通，是项目交付质量的第一关。我见过很多项目，代码写得像模像样，SQL脚本里却连外键都没有，订单表只有一张大宽表，联调时改改停停。这一章讲清楚表怎么拆、字段怎么定、初始化数据里该放什么。

4.1 数据表清单：用户、图书、分类、订单、订单项、地址

网上书店最少需要七张表，每张表的职责要单一。我把常见表名和关键字段列出来，你在动手建表之前先对着这张表核一遍：

用户表里role区分管理员和普通用户，管理员可以进后台管理图书，普通用户只能逛店下单。book表里的stock是库存，下单时要做扣减。order表是订单主表，order_item是订单明细表，这两张表的关系是网上书店数据库设计的分水岭。如果只设计一张订单表，把买的几本书拼成一个字符串存进去，后续查销量、对账、取消单全都会变成灾难。

4.2 核心建表语句：订单表为什么要拆成主表和明细表

订单主表和明细表拆开，核心原因是订单需要快照。用户下单时图书标题、价格、数量都属于下单那一刻的状态，如果只存一个book_id，将来图书改价或下架，历史订单就没法看了。下面是两张表的建表语句：

CREATE TABLE `order` ( `id` bigint NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '业务订单号', `user_id` bigint NOT NULL, `total_price` decimal(10,2) NOT NULL, `status` tinyint NOT NULL DEFAULT 0 COMMENT '0待支付 1已支付 2已发货 3已完成 4已取消', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `pay_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_user_id` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE order_item ( `id` bigint NOT NULL AUTO_INCREMENT, `order_id` bigint NOT NULL, `book_id` bigint NOT NULL, `title` varchar(200) NOT NULL, `price` decimal(10,2) NOT NULL, `count` int NOT NULL DEFAULT 1, PRIMARY KEY (`id`), KEY `idx_order_id` (`order_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

注意，order是MySQL的保留字，直接建表会语法报错，所以表名必须加反引号。这是我带人时遇到最多的低级报错，建议你把主表命名成t_order或orders，省得每条SQL都写反引号。订单状态用tinyint存数字，不要直接存字符串，状态流转在代码里用枚举维护。价格字段必须用decimal(10,2)，float在累加时会产生精度误差，下单和退款算错钱是血泪经验。

提示：不要建物理外键。网上书店这种场景，逻辑外键配合Service层校验就够了。物理外键在后续做数据清洗、批量导入、分库时都是麻烦，而且应用层没控制好还会造成死锁。

4.3 初始化数据与SQL脚本里该放什么

一份能直接跑起来的数据库sql脚本，除了建表语句，还要有初始化数据。管理员账号、分类、十几本图书样例这三样必须有，否则前端页面打开是空的，你根本没法验证功能。插入管理员用户时特别注意，密码不能明文：

INSERT INTO `user` (`id`, `username`, `password`, `nickname`, `role`, `create_time`) VALUES (1, 'admin', '202cb962ac59075b964b07152d234b70', '管理员', 'ADMIN', NOW());

这里示例的哈希串是'123'的MD5值，只为演示用。实际项目请用BCrypt对密码加密，因为MD5用彩虹表几秒钟就能破解，上线这么干等于裸奔。初始化数据还要注意主键冲突问题，脚本里用INSERT不要带AUTO_INCREMENT的具体值，或者写上id让表结构里的AUTO_INCREMENT重新计算。

SQL脚本文件最好按执行顺序编号：01_schema.sql负责建库建表，02_data.sql负责初始化数据。文档说明里第一页就写清楚：先执行schema再执行data，通过source命令导入前先set names utf8mb4，避免Windows下中文乱码。如果你用MySQL Workbench或命令行导入，脚本里不要出现DROP DATABASE这种删库操作，否则误执行会把别人数据清掉，这是最基本的职业素养。

5. 前后端联调避坑：CORS、Token鉴权、打包路径和数据库连接

代码写完不是结束，前后端联调才是项目真正的试金石。这一章只讲四件我在网上书店项目里反复遇到的翻车现场，按“现象到原因到解决”的顺序讲，每条都能直接抄。

5.1 CORS跨域：为什么前端请求后端总被拦截，报错说没有Access-Control-Allow-Origin

现象：浏览器控制台报CORS error，请求一直pending，或者后端明明打印了日志、前端却拿不到响应。原因是Vue开发服务器在5173端口，SpringBoot在8080端口，两个源不同，浏览器默认拦截跨域响应。解决：在后端配置一个CorsConfig，统一放行前端来源：

@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); } }

allowedOriginPatterns("")配合allowCredentials(true)，允许跨域请求携带Cookie和Authorization头。如果只用allowedOrigins("")和allowCredentials(true)一起使用，新版浏览器会直接拒绝这种配置。参数说明：开发阶段可以放行所有来源，上线前把allowedOriginPatterns改成你的前端域名，比如https://books.example.com。maxAge设成3600秒，浏览器会缓存预检结果，减少OPTIONS请求的次数。

5.2 Token鉴权：登录后接口还是401，拦截器排除路径没写对

现象：用户登录成功跳转首页，页面数据加载不出来，接口全返401。原因是拦截器拦截了/api/**，但排除路径没包含图书列表和分类列表，导致登录前就能访问的公开接口也被拦了。解决：注册拦截器时明确排除路径：

@Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(jwtInterceptor) .addPathPatterns("/api/**") .excludePathPatterns( "/api/user/login", "/api/book/page", "/api/category/list" ); }

图书列表、分类列表、图书详情都是要显示在登录页之前的内容，必须放行。如果你把需要登录的接口和公开接口混在一个前缀下，这个列表越写越长，很难维护。更稳的做法是给需要登录的接口统一加/api/auth/前缀，拦截器只拦这个前缀。参数说明：如果前端是调用/api/book/page拉首页，排除路径漏写会导致整个书城首页白屏。这种错误日志里不会报错，只会看到401，所以排查时要先意识到底层是拦截器在起作用。

5.3 Vue打包路径的坑：路由history模式刷新404，静态资源也404

现象：本地dev环境一切正常，npm run build之后放Nginx，访问首页没问题，刷新子路由就404，或者样式和JS文件加载不出来。原因：createWebHistory依赖服务器把不存在的路径回退到index.html，同时Vite默认构建产物使用绝对路径，部署在子目录时路径对不上。解决：Nginx配置加try_files回退，Vite的base按部署目录调整：

location / { root /usr/share/nginx/html; try_files $uri $uri/ /index.html; }

try_files最后一项把匹配不到的路径全部交给index.html，Vue Router再根据路由表渲染对应组件。如果你的站点部署在子路径/books/下，Vite的base要配置成'/books/'，同时router的createWebHistory也要传'/books/'，否则加载到的资源路径全是根目录。另一个常见情况是dist里引用的assets是绝对路径/assets/xxx.js，域名的根目录下又没有assets目录，把base改成'./'可以让资源变成相对路径。注意history模式和相对路径base需要一起调，否则子路由刷新会二次丢失。

5.4 数据库连接排查：时区差8小时、驱动不对、SQL脚本执行失败

现象：后端启动时数据库连接报错，或查出时间比北京时间少8小时。原因是JDBC URL里缺少serverTimezone参数，或者用了已经被移除的旧驱动。解决：在application.yml里检查连接串：

spring: datasource: url: jdbc:mysql://localhost:3306/bookstore?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver

MySQL 8.x的驱动类名必须是com.mysql.cj.jdbc.Driver，旧版com.mysql.jdbc.Driver在升级后只剩一个空壳，启动时很容易报ClassNotFound。URL里的时区指定为Asia/Shanghai，避免默认UTC导致的8小时偏移，别指望在代码里手动加8小时，那种魔改累死人。执行SQL脚本失败通常是脚本开头没有指定数据库，或乱用了Windows编码。MySQL命令行导入前先执行use bookstore;，文件编码用UTF-8无BOM，再set names utf8mb4，基本能避开中文乱码和字符集报错。

6. 网上书店进阶技巧：订单超时自动关闭与上线后验证

网上书店做完基础功能后，最值得加的一个真实业务规则是：订单超过30分钟未支付自动取消，并恢复库存。这是能从课程设计走向生产系统的关键差异点，也是面试时能展开聊的亮点。

用SpringBoot自带的定时任务就能实现，不需要引入消息队列。在启动类或配置类上加@EnableScheduling，然后写一个定时任务方法：

@Scheduled(cron = "0 */1 * * * ?") public void closeTimeoutOrders() { LambdaQueryWrapper<Order> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Order::getStatus, 0) .lt(Order::getCreateTime, LocalDateTime.now().minusMinutes(30)); List<Order> orders = orderMapper.selectList(wrapper); for (Order order : orders) { order.setStatus(4); orderMapper.updateById(order); orderItemMapper.recoverStock(order.getId()); } }

cron表达式每分钟触发一次，超时时间写在常量配置里，不要写死在SQL。查询条件用status等于0、createTime早于当前时间前30分钟，这样不会有重复处理。更新订单状态为4之后，再恢复库存，顺序不能反，否则用户看到订单已取消但页面还显示有货，下单时才发现库存不够。

上线后验证要分两步走。第一步先下一笔测试订单，把超时时间临时改成1分钟，再专注地等它自动取消；第二步看定时任务日志确认订单状态从0变成4。我早期在这里栽过跟头：把已支付和已发货状态值写反，导致财务对账单怎么都对不上，后来在代码里加状态流转枚举，每次修改状态都校验当前状态是否合法，类似“待支付才能改成已取消”“已支付才能改成已发货”，这种强制约束比注释可靠得多。

如果你希望这个项目更有含金量，还可以在定时任务里加失败告警、把库存恢复放在单独事务里。但不要一上来就上Redis延迟队列，订单量没到那个级别之前，定时扫描是最容易调试、最容易兜底的方案。这是我自己实践下来的教训：先把规则用最简单的方式跑通，再谈分布式架构。希望帮到你。

本文还有配套的精品资源，点击获取