简介基于 Spring Boot 与 Vue 构建的前后端分离商城系统源码面向正在学习 Java Web 与前端框架的开发者适合用于课程设计或毕业设计。项目按前台用户端与后台管理端拆分明细用户侧涵盖注册登录、商品查询、购物车汇总、总价计算与订单流程管理侧提供分页、权限、关键字检索以及商品、分类、订单、用户、轮播图等模块的增删改查操作。压缩包共 3217 个文件类型集中在前端构建产物与源码上包括 Vue 单文件组件、JS/CSS/SCSS/TS 等样式与逻辑文件以及少量 Java 控制器、实体类、XML 映射和服务端配置整体体积仅 6.79MB便于快速下载与本地部署。已有 2015 人学习下载代码结构较清晰既能学习前后端交互、接口设计与权限控制也可在此基础上扩展营销或支付模块。目录中说明文档与构建脚本齐全配合分类清晰的前端资源适合局部替换或二次开发。1. 拿到这份 SpringBootVue 前后端分离商城源码先想清楚这三个问题打开压缩包最先看到的是基于SpringBootVue的前后端分离商城系统源码这几个字。它要解决的问题很直白用SpringBoot提供restful接口用Vue做页面中间只走JSON商城该有的注册登录、商品列表、购物车、下单支付、后台管理全都有。这类源码最适合两类人一是课程设计和毕业设计的学生二是刚学完Vue和SpringBoot、想找一个完整项目把前后端串起来的开发。它的真正门槛不在单个技术而在于前端路由、后端鉴权、订单状态这三条线怎么连起来。我拿到这种压缩包第一件事不是启动而是先翻数据库脚本和登录接口把核心表看明白再启动项目。顺序反了你会在各种奇怪报错里浪费一下午。2. 把压缩包跑成本地可用的商城环境准备与启动步骤2.1 解压后先摸项目结构前后端各自的家先解压用tree -L 2Windows 用dir /s看整体结构。一个标准的前后端分离源码目录基本分三大块backendSpringBoot后端、frontendVue前端、sql数据库脚本。有的包会把前端放到mall-web、后端放到mall-serverSQL 脚本放在根目录的db或者doc里。如果你看到的是前后端代码混在一起、没有明确分离的文件夹那说明这份源码名不副实后面改动会很痛苦。我在动手前会先确认几件事前端是 Vue 2 还是 Vue 3构建工具是 vue-cli 还是 vite。看package.json里的依赖就能判断这决定你要装哪个 Node 版本。后端是 Maven 单模块还是多模块。pojo、mapper、service、controller是否分层清晰还是全塞在一个类里。SQL 脚本是单独的.sql文件还是放在某个模块的resources目录里。这些信息对应着后面会踩的坑Vue2 配 Node 14 更省心Vue3 用 Node 16 更合适Maven 多模块意味着你要先install基础模块才能跑起来。看清结构之后先按顺序做三件事创建数据库、改后端配置、起后端然后再起前端。这个顺序别打乱——前端启动后要请求后端接口后端没起来前端页面就会刷出一片请求报错。2.2 后端启动改配置、建库、跑 spring-boot:run先建库执行根目录 SQL 脚本mysql -uroot -p -e CREATE DATABASE IF NOT EXISTS mall DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; mysql -uroot -p mall sql/mall.sql第一行创建mall库指定 utf8mb4 字符集避免商品描述里的特殊字符存出乱码第二行把脚本导入库中生成商品、订单、用户、购物车这些表。执行完用mysql -uroot -p -e USE mall; SHOW TABLES;确认表数量。如果脚本报错多半是版本兼容问题脚本里用了 MySQL 8 的utf8mb4_0900_ai_ci但本地库是 5.7这时要么换到 8.0要么把脚本里的排序规则统一替换成utf8mb4_general_ci。然后改后端配置。用 IDE 打开 backend 模块找到src/main/resources/application.yml重点改数据源、端口、以及项目里可能用到的 Redis。常见片段server: port: 8080 servlet: context-path: /api spring: datasource: url: jdbc:mysql://localhost:3306/mall?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 redis: host: localhost port: 6379这里的context-path: /api很关键。它给所有 Controller 路径加了/api前缀。如果前端是按这个前缀请求的而你把它去掉接口就会 404去掉不难但前端所有请求路径也要跟着改。我一般保留源码里的前缀前端环境变量直接配http://localhost:8080/api最省事。改完配置在 backend 目录下执行mvn spring-boot:run如果项目是多模块需要先到根 pom 目录执行mvn clean install -DskipTests再进到含SpringBootApplication的模块启动。启动日志里出现Tomcat started on port(s): 8080才算成功。此时先用浏览器或 Postman 调一个公开接口验证比如GET http://localhost:8080/api/product/page?pageNum1pageSize10能返回 JSON 就说明后端已就绪。启动过程最容易翻车的点有三个端口被占用、MySQL 连接被拒、Redis 没起。端口被占用就改server.portMySQL 连接问题重点看spring.datasource.url里的serverTimezone不写会报时区异常Redis 如果连接不上看后台是否启动了redis-server。另外很多商城源码会在启动时初始化 admin 账号日志里会打印初始密码别忽略。如果启动报Failed to configure a DataSource九成是数据源配置问题回去检查 url、用户名、密码。2.3 前端启动装依赖、配上接口地址、npm run dev前端是 Vue 项目进入 frontend 目录先确认 Node 版本node -v然后安装依赖npm install这个命令很容易卡在个别包上最典型的是node-sass编译失败。解决方案是把node-sass换成sass和sass-loader或者把 Node 版本降到项目要求的版本。我遇到过一份源码要求 Node 14 sass 4.x用 Node 16 装怎么都报错降到 14 一次过。安装成功后先找到环境变量配置文件。vue-cli 项目一般在.env.developmentvite 项目也可以在vite.config.js里配置server.proxy。在.env.development里把接口地址指向后端VUE_APP_BASE_URLhttp://localhost:8080/api然后代码里请求工具会读取process.env.VUE_APP_BASE_URL。比如 axios 封装里常见这一行axios.defaults.baseURL process.env.VUE_APP_BASE_URL这里有个容易忽视的点如果后端没开 CORS前端直接请求不同端口的接口会被浏览器拦截。很多源码在后端已经加了全局 CORS 配置但只允许了某一组来源比如allowCredentials: true时allowedOrigins不能写成*需要明确列出http://localhost:8081。这一点在下一章的避坑里会展开。启动命令npm run dev启动成功后访问前端页面地址Vite 默认可能在http://localhost:5173vue-cli 常见8080或9527。用源码里提供的管理员账号登录后台能看到商品管理、订单管理界面就算跑通了。此时别急着改业务先登录、翻商品、下一单把整个流程点一遍确认没有拦路虎再开始改造。3. 拆核心业务商品、购物车、订单这三条线的表结构和接口设计3.1 商品线SPU/SKU 与库存扣减商城源码里商品表通常不止一张。简单的是product单表商品规格多一点的会拆成spu和sku两张表SPU 表示一件商品SKU 表示这个商品的一种具体规格。比如手机是 SPU黑色 256G是 SKU。订单明细关联的其实是 SKU而不是 SPU因为下单时要知道用户买的是哪个颜色哪个版本。核心字段大致是这样表名关键字段说明spuid, name, category_id, main_image, detail_html, status商品基本信息status 控制上下架skuid, spu_id, spec_info, price, stock, original_price规格信息可以用 JSON 存也可以拆成多字段stock_logid, sku_id, order_sn, change_type, quantity, created_time记录库存变动方便对账和排查商品列表接口通常是一个带分页的查询常见请求参数是pageNum、pageSize、categoryId、keyword、sort。后端用 MyBatis-Plus 的LambdaQueryWrapper就能拼条件但要注意排序字段的映射前端传sortpriceDesc后端要把这个字符串翻译成price DESC不能直接拼进 order by 造成 SQL 注入。我见过不少源码这么写安全隐患就在这。库存扣减是商品线的难点。如果只是下单后UPDATE sku SET stock stock - 1并发一高就会出现超卖。常见做法是乐观锁执行更新时带上当前库存条件。UPDATE sku SET stock stock - #{quantity} WHERE id #{skuId} AND stock #{quantity}受影响行数为 0 就说明库存不足或已被改过业务层要抛异常回滚事务。好的源码会在stock_log里记录每一次扣减一旦订单取消还能从这里溯源而不是直接改stock字段拍脑袋。3.2 购物车前端 Session 还是后端表购物车的实现有两条路线只存前端本地localStorage或者前后端各存一份。演示性质的商城源码很多是纯前端存本地好处是后端省事坏处是清浏览器缓存就丢稍微完整一点的会做后端购物车表用户登录后把购物车数据同步到服务端。后端购物车常见表结构字段说明id主键user_id用户 idsku_idSKU idquantity数量checked是否勾选下单时只结算勾选项created_time / updated_time时间戳购物车接口没什么难的无非是add、list、updateQuantity、delete、check。值得关注的是合并购物车这个功能用户未登录时加了几件商品登录后要把本地购物车合并到服务器端。合并逻辑要按sku_id做 upsert已存在的累加数量而不是重复插入。我见过一种很糙的写法登录后直接DELETE后端购物车再插入本地数据这样用户之前登录加的东西全丢了。正确做法是循环合并每条记录做存在性检查。另外购物车数量在商品详情页会有个角标很多源码用 Redis 缓存计数这样每次add后不用请求数据库。如果没有 Redis直接查询购物车表COUNT也没问题只是压力大一点。看源码时留意它是怎么处理的能判断作者的工程素养。3.3 订单线状态机、防重和事务边界订单是商城源码里最容易出问题的部分因为涉及多张表写入。核心表有三张表名字段要点ordersid, order_sn, user_id, total_amount, status, receiver_info, create_timeorder_itemid, order_id, sku_id, item_name, item_image, price, quantitypaymentid, order_sn, pay_no, pay_type, amount, status, pay_time订单状态常用status字段表示一般有这些0 待支付、1 已支付、2 已发货、3 已完成、4 已取消。前后端分离项目里前端根据状态值显示按钮后端负责状态流转。这里要注意源码是否做了状态约束比如已取消的订单不允许支付已发货的订单不允许取消。如果没有任何校验任意接口都能把订单改到任意状态那订单模块就是摆设。下单接口的常规步骤是校验购物车、用户地址、商品上下架状态。生成订单号order_sn格式通常含时间戳和随机位保证唯一。扣减库存同时写stock_log。插入订单主表和订单明细。清空购物车中已下单的 SKU。这五步必须在一个事务里完成后端的Transactional要加在 Service 层方法上。我见过新手把这个注解加到 Controller 的方法上事务其实不生效因为 Spring 代理默认只拦截 Service 层。还有个防重问题用户连续点两次提交订单如果没有幂等控制会生成两笔订单。常见做法是前端按钮提交前禁用同时后端接收一个防重令牌token在 Redis 里以订单号或用户 id 做标识设置短过期时间同一个 token 第二次请求直接返回请勿重复提交。看源码时重点查这块如果没有改造时一定要补上。4. 前后端分离商城源码的踩坑记录从开发到部署的五个高频问题4.1 接口 404 还是 401路径、上下文和登录态一起查现象前端登录请求发出去控制台报404或者401页面一直停在登录页。原因404 往往是路径前缀不对。前端baseURL配的是http://localhost:8080但后端设置了context-path: /api实际接口是/api/user/login于是打到了不存在的/user/login上。401 则说明请求到了但后端没拿到Authorization头常见是前端拦截器没把 token 塞进请求头或者 token 过期。解决先把浏览器 Network 面板打开看最终请求的 URL 是不是和 Controller 的映射一致。404 就去改.env.development的VUE_APP_BASE_URL401 就去查 axios 请求拦截器确认是否每次请求都加了 tokenaxios.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] token } return config })有些源码后端拦截器要求请求头是token而不是Authorization两处不一致也会导致拿到了 token 却不认账。4.2 跨域配置不生效CORS 的先后顺序和 allowCredentials 的坑现象前端axios请求后端浏览器报CORS policy: No Access-Control-Allow-Origin header后端也写了 CORS 配置但前端还是过不去。原因写 CORS 配置的位置不对或者被其他过滤器拦截了。SpringBoot 里最常见的写法是注册一个CorsFilter或者实现WebMvcConfigurer#addCorsMappings。如果项目里还有自定义的Filter且没有在过滤器链里放行 OPTIONS 预检请求浏览器发的OPTIONS请求会在到达 CORS 处理之前被拦截返回的响应头不完整浏览器就会报错。解决先确认 CORS 配置类被 Spring 扫描到。然后看自定义过滤器里是否对OPTIONS请求直接放行。推荐的配置片段Component 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); } }注意点当allowCredentials(true)时allowedOrigins不能写*但可以用allowedOriginPatterns(*)。这个细节不少人翻车前端带 cookie 时尤其明显。4.3 上传图片返回本地路径生产环境一换域名就裂现象后台商品管理里上传图片本地能看到前端也回显正常一部署到服务器所有商品图片都是裂的。原因上传接口把文件保存到了本机磁盘返回的 URL 是http://localhost:8080/upload/xxx.png。前端静默把地址存进数据库换台机器访问这个地址当然指向了别人的 localhost。严格说这是源码里写死了本机地址的坏习惯。解决改造上传接口把图片 URL 改成可配置的域名前缀。在application.yml里加一项upload: base-url: http://images.example.com local-path: /data/upload/返回给前端的时候拼接base-url 文件名。如果团队有对象存储直接把local-path换成 OSS 或 MinIO 的 SDK业务代码不用动。关于 MinIO 接入 SpringBoot 是另一个话题这里只需要记住一个原则代码里永远不要暴露localhost给前端这个前缀必须来自配置文件。4.4 用 Tomcat 部署前后端分离项目静态资源托管与打包姿势现象本地npm run dev一切正常把前端打包后扔进 Tomcat 的webapps访问一堆 404刷新页面直接变成空白。原因前后端分离项目的坑在于前端打包出来是纯静态文件需要放到一个静态资源服务器上而后端是 Tomcat 启动的 war 包两者不是同一个服务。有人直接把前端静态文件塞进 Tomcat 的 ROOT 目录刷新路由时又因为 Vue Router 是 history 模式Tomcat 找不到对应的真实文件于是 404。解决常见方案是让 Tomcat 同时托管静态资源和 API。把 Vue 打包后的dist目录改名为ROOT放到 Tomcat 的webapps下后端 war 包也部署在同一个 Tomcat然后用server.servlet.context-path区分 API 前缀。这样http://ip:8080/是前端页面http://ip:8080/api是后端接口。前端打包时VUE_APP_BASE_URL要配成/api这样所有请求都走相对路径不再写死 IP。再省心一点的做法是直接用 Nginx 托管前端静态文件接口请求转发到后端的 8080Vue Router 的 history 模式需要通过try_files配置重写。我一般会提醒学员部署前后端分离项目时最忌把前后端接口地址写死在代码里尽量用环境变量区分开发、测试、生产。4.5 全局过滤器处理上传 PDF 时的 XSS 攻击白名单别只做一条现象后台系统全局加了一个过滤器把所有请求参数里的script标签替换掉之后上传 PDF 文件就报错上传失败。原因很多前后端分离项目会用全局过滤器处理 XSS 攻击做法是对请求体里的字符串做正则替换。这个过滤器如果对所有请求都生效上传 PDF 时会去读二进制流把里面的字节按文本处理极容易把文件字节流弄坏。或者因为过滤器读取了输入流后面的 MultipartFile 解析拿不到流导致上传失败。解决过滤器要做白名单放行凡是上传接口和带文件的请求直接跳过参数清洗。常见做法是在过滤器中判断请求路径if (request.getRequestURI().contains(/upload/) || request.getContentType() ! null request.getContentType().startsWith(multipart/form-data)) { chain.doFilter(request, response); return; }这不是免责的偷懒上传文件本来就应该走专门的白名单文本参数才需要做转义。处理 XSS 的正确切入点是参数节点值而不是整段输入流。每次看到全局过滤器这个词都要确认它对大数据流和文件上传是安全的。5. 四个必须读完的关键代码点登录鉴权、分页、下单事务、支付回调5.1 登录鉴权与 token 拦截前后端分离商城几乎都是 token 鉴权登录成功后后端生成一段 token前端存到 localStorage 或 Cookie后续请求通过请求头携带。后端最常见的实现是继承 HandlerInterceptorAdapter在preHandle里解析 token。Component public class AuthInterceptor implements HandlerInterceptor { Autowired private RedisTemplateString, String redisTemplate; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || token.isEmpty()) { response.setStatus(401); return false; } String userId redisTemplate.opsForValue().get(token: token); if (userId null) { response.setStatus(401); return false; } request.setAttribute(userId, userId); return true; } }这里的逻辑很直接Redis 里存了 token 和用户 id 的映射每次请求从请求头取 token查不到就回应 401。查到了就放进 request 属性后面的 Controller 方法通过RequestAttribute(userId)拿到当前用户。要注意的是很多源码只拦截了部分路径。登录接口、商品查询、图片访问必须放行否则用户没登录就看不了商品列表。放行方式常见两种在preHandle里判断路径或者在注册拦截器时用excludePathPatterns精确排除。看源码时重点看排除列表里有没有/api/login、/api/product/**、/api/upload/**。看到一个小小的遗漏就能判断这份代码靠不靠谱。5.2 商品分页的一个通用 query 层写法商城列表页基本都有分页、筛选和排序。好的源码会把分页参数封装成一个 PageQuery 对象而不是在 Controller 里直接写RequestParam Integer pageNum。Data public class PageQuery { Min(value 1, message 页码不能小于1) private Integer pageNum 1; Min(value 1, message 每页条数不能小于1) Max(value 100, message 每页最多100条) private Integer pageSize 10; }Controller 方法接收这个对象后用 MyBatis-Plus 的Page对象传参GetMapping(/page) public ResultIPageProductVO page(ProductQuery query) { PageProductDO page new Page(query.getPageNum(), query.getPageSize()); LambdaQueryWrapperProductDO wrapper new LambdaQueryWrapper(); wrapper.eq(StringUtils.hasText(query.getCategoryId()), ProductDO::getCategoryId, query.getCategoryId()) .like(StringUtils.hasText(query.getKeyword()), ProductDO::getName, query.getKeyword()); if (priceDesc.equals(query.getSort())) { wrapper.orderByDesc(ProductDO::getPrice); } IPageProductDO result productMapper.selectPage(page, wrapper); return Result.success(result); }这里把分页参数的校验交给了Valid排序没有拼到 SQL 字符串里而是用 MyBatis-Plus 的orderByDesc生成安全的 order by。这是值得照抄的写法。更完整的项目会额外转成 ProductVO 返回前端隐藏掉库存、状态这些后端字段。5.3 下单事务和库存乐观锁下单接口是事务最集中的地方也最容易看出源码水平。一个合格的下单 Service 方法长这样Transactional(rollbackFor Exception.class) public Long createOrder(OrderRequest request) { String orderSn generateOrderSn(); // 1. 校验库存并扣减 int rows skuMapper.reduceStock(request.getSkuId(), request.getQuantity()); if (rows 0) { throw new BizException(库存不足); } // 2. 插入订单主表 OrderDO order buildOrder(request, orderSn); orderMapper.insert(order); // 3. 插入订单明细 OrderItemDO item buildItem(order.getId(), request); orderItemMapper.insert(item); // 4. 清购物车 cartMapper.deleteByUserSku(request.getUserId(), request.getSkuId()); return order.getId(); }reduceStock对应的 SQL 就是前面写的UPDATE sku SET stock stock - #{quantity} WHERE id #{skuId} AND stock #{quantity}。受影响行数是 0 说明库存已经被别人抢了此时抛出业务异常。由于方法上有Transactional库存更新、订单插入、购物车清理会一起回滚不会出现库存扣了但订单没建出来的局面。还要注意Transactional默认只处理运行时异常。如果源码里把库存不足定义为受检异常事务就不会回滚这是一个隐蔽的坑。排查时可以看异常类是否继承RuntimeException或者代码里有没有手动TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。5.4 支付回调幂等与订单状态扭转商城源码里的支付通常是个模拟接口但回调逻辑值得认真读。真实回调场景是第三方支付平台把支付结果 POST 到后端接口后端要保证重复通知不会把订单状态改坏。PostMapping(/callback/pay) public String payCallback(RequestBody PayNotifyData data) { OrderDO order orderMapper.selectByOrderSn(data.getOrderSn()); if (order null) { return fail; } // 状态机校验只有待支付的订单才能被支付成功 if (order.getStatus() ! ORDER_STATUS_WAIT_PAY) { return success; } int rows orderMapper.updateStatus(order.getId(), ORDER_STATUS_PAID, ORDER_STATUS_WAIT_PAY); if (rows 0) { return success; } // 幂等记录 paymentMapper.confirmPay(data); return success; }这段代码的精髓在updateStatus的乐观更新更新时带上了当前状态条件WHERE status 待支付。这样即使两个回调同时进来也只有一个能把状态从待支付改成已支付。第二个请求发现不满足条件直接返回 success因为支付平台需要的是应答成功不是业务处理成功。看源码时我会特别找支付回调有没有写确认记录比如幂等表或者 payment 表里的状态位。如果只有简单的if判断换一批重复回调就会把订单状态搞乱这属于需要第一时间补上的缺陷。6. 从演示项目到可上线的商城多环境、统一返回体、日志与权限收敛演示源码跑通了真正的投入其实从改造才开始。我拿到这类 SpringBootVue 商城源码后第一个习惯是先把application.yml拆成多环境配置application-dev.yml、application-test.yml、application-prod.yml主文件里用spring.profiles.active切换。前端同步用.env.development和.env.production把接口地址按环境分开这样换一台服务器部署时不用改代码。第二个习惯是统一后端返回体。很多源码的 Controller 返回值东一个Map、西一个Object前端根本没法统一解析。我会定义一个ResultT包括code、message和data三个字段所有 Controller 都返回它同时加一个全局异常处理器把业务异常、参数校验异常统一转换成Result。三天后你会发现前端所有人都在谢你。第三个习惯和权限有关。商城源码里的管理员往往只是一个字段真正的上线项目需要角色和菜单权限表后端按角色限制接口。用 Spring Security 或 Shiro 做权限收敛对新手来说成本不低但如果只是给课设兜底至少要把接口和页面分开控制后端对敏感操作加角色校验前端只隐藏按钮并不能挡住恶意请求。最后讲一个我在排查支付模块时留下的教训改订单状态永远要用UPDATE orders SET status ? WHERE id ? AND status ?这种乐观方式不要先 SELECT 再 UPDATE。前者在并发和重复请求下是安全的后者一定会在真实环境翻车。看完这份源码把这一条原则刻进肌肉记忆比你照着它多写两个 CRUD 有用得多。希望这些在前后端分离商城源码上踩过的坑能帮你省下一整周的排查时间。本文还有配套的精品资源点击获取