这一套「Java SpringBoot Vue3 MyBatis MySQL」的在线商城系统源码算是这几年Java后端很主流、也最适合练手的一类全栈项目了。前后端分离、RESTful接口、JWT鉴权、商品订单流转、后台管理覆盖了一个中型Web系统的大部分核心知识点。不管是拿来做毕业设计、个人作品集还是想系统性理解一套真实电商业务怎么落地都值得好好拆一遍。我从开发者的视角把这套系统的架构设计、数据库建模、后端核心实现、前端工程化、联调部署这些环节逐个说清楚顺便把实际开发中容易踩的坑和常用的排查思路也整理出来希望能帮你少走一些弯路。1. 一个在线商城系统到底包含什么1.1 为什么是这套技术组合先说技术选型。Java SpringBoot是当前企业级后端最主流的组合之一SpringBoot简化了Spring的配置内嵌Tomcat打一个Jar包就能跑非常适合快速交付业务接口。MyBatis作为持久层框架SQL由开发者自己控制调优空间大尤其适合电商这种查询条件复杂、报表类的SQL比较多的场景。MySQL则是开源关系型数据库里的常青树事务、索引、主从复制能力都足够支撑中小型商城的业务量。前端选Vue3配合Vite构建工具、Pinia状态管理、Vue Router路由和Element Plus组件库算是目前Vue生态里最标准的一套组合。用它来做后台管理界面和用户端页面开发效率很高组件复用也方便。前后端分离是这个项目最值得关注的地方。后端只提供JSON格式的API接口前端通过HTTP请求调用两者之间通过接口文档或TypeScript类型定义来约定数据格式。好处是前后端可以并行开发后端不关心页面长什么样前端不关心SQL怎么查部署时也可以分开扩容。1.2 系统功能模块划分一套可用的商城系统从用户角色角度能拆成两块。用户端前台商城包含用户注册、登录、个人信息维护商品分类浏览、关键词搜索、商品详情查看购物车管理添加、修改数量、删除、选中结算下单结算、订单支付一般用模拟支付订单列表、订单详情、确认收货、取消订单收货地址管理管理端后台管理包含管理员登录与权限校验商品管理上架、下架、新增、编辑、库存维护分类管理树形结构订单管理查看订单、发货、退款处理用户管理查看用户列表、禁用账号数据统计订单量、销售额、热门商品这套前后端分离架构下所有功能都走API接口所以接口设计是否规范直接决定系统的可维护性。一般的做法是用RESTful风格资源用名词复数表示操作通过HTTP方法区分。比如GET /api/products表示商品列表POST /api/orders表示创建订单。1.3 前后端分离的代价与收益前后端分离不是银弹它解决了“代码纠缠”的问题同时也引入了新的问题跨域配置、Token传递、接口联调成本、部署时需要分别处理静态资源和后端服务。我把它的收益和代价都列一下。收益方面第一是职责清晰后端只关心业务和数据处理前端只关心交互和渲染第二是开发和部署灵活后端用Docker、前端用Nginx各自扩容第三是天然适合多端复用同一套API可以同时服务Web端、小程序端和App端。代价方面第一是开发初期需要定义清晰的接口规范否则联调阶段会很痛苦第二是前端需要处理CORS跨域、Token刷新、错误码统一解析这些额外逻辑第三是调试成本会高一些查一个问题往往要在浏览器Network面板、后端日志、数据库三个地方来回跳。所以如果你刚接触这类项目建议不要一上来就追求微服务、分布式那一套先把这个“单体SpringBoot 独立Vue前端”的结构吃透后面再逐步引入Redis、MQ、ES这些组件反而是更接地气的成长路径。2. 数据库设计决定商城能走多远2.1 核心表结构与关系数据库设计是整个项目的地基这块搞不好后面写接口时会非常难受。一个最小可用的商城数据库至少需要这几张表。用户表sys_user存用户与管理员账号共用或分表都可以建议至少包含id、username、password加密后的密文、nickname、avatar、role、status、create_time这些字段。商品表goods包含id、category_id、name、subtitle、main_image、detail富文本、price、stock、sales、status上下架、create_time。price建议用decimal(10,2)不要用float否则金额会出现精度问题。分类表category做两级分类就够了id、parent_id、name、sort_order用自关联来处理父子层级。购物车表cart_item包含id、user_id、goods_id、quantity、checked前端在用户不登录时也可以用localStorage存购物车登录后同步到后端。订单表orders是核心中的核心字段至少要有id、order_no订单编号、user_id、total_amount、pay_amount、freight_amount、status、receiver_name、receiver_phone、receiver_address、pay_time、deliver_time、finish_time、create_time。订单编号建议用时间戳 随机数生成唯一值不要直接使用数据库自增id暴露给用户。订单明细表order_item包含id、order_id、goods_id、goods_name、goods_image、goods_price、quantity、total_price。为什么订单要冗余商品名称和图片因为商品信息是易变的用户下单之后商家改了商品名你总不能把历史订单里的名字也改了吧。冗余字段是电商系统的常规操作。各表之间的关系用外键也可以但实际开发中更常见的做法是不建物理外键靠业务逻辑保证数据一致性。理由也很简单高并发场景下外键约束会影响写入性能而且分库分表之后外键根本没法跨库生效。所以字段关系体现在SQL的JOIN查询里而不是数据库约束上。2.2 订单状态机设计订单状态是整个系统里最需要理清楚的业务规则。常见的状态用整数或字符串表示都可以我习惯用整数比如0待付款1待发货已付款2待收货已发货3已完成确认收货4已取消付款前取消或超时未付5退款中 / 已退款这个状态机最关键的一点是状态流转是单向且有条件的。待付款可以取消或变成待发货待发货可以变成已取消商家取消但不能跳回待付款待收货只能变成已完成或进入售后流程。后端在更新状态时要有校验逻辑不能出现“已发货的订单被改成待付款”这种脏数据。一个实际的例子用户提交订单后状态是0支付回调成功后改成1。如果你之前没有定义好状态机的流转规则后面做后台“订单导出”功能时就会发现状态字段查出来一堆无法理解的数字还得维护一套映射关系。2.3 库存扣减的姿势库存扣减是商城系统的高频考点也是最容易出并发问题的地方。最简单的错误示范是先查询库存判断库存充足再执行更新这个流程在高并发下必然超卖。实际的解决方案有两种常用方案。第一种是使用数据库的乐观锁/条件更新UPDATE goods SET stock stock - #{quantity} WHERE id #{goodsId} AND stock #{quantity}这条SQL同时完成了“检查库存”和“扣减库存”两个动作通过受影响行数判断是否扣减成功。如果返回0说明库存不足或商品不存在业务层再抛出异常。这种方式不需要额外引入分布式锁在单体应用场景下完全够用。第二种是使用Redis预扣库存下单时在Redis里扣减异步同步到MySQL适合高并发秒杀场景。这套系统如果定位是学习用掌握第一种方案就够了。实际写业务的时候还会有个小细节用户下单通常有“锁定库存—支付—扣减库存”或者“支付即扣减”两种流程。简化版本可以直接在创建订单时扣减库存取消订单/超时未付时回补库存。这要求事务边界一定要清晰扣库存和创建订单必须放在同一个事务里否则会出现订单建了但库存没了或者库存扣了但订单失败的情况。3. 后端核心逻辑与实现细节3.1 用户的登录认证怎么做这套系统是前后端分离的Session这种方案天然不友好因为前端和后端可能不在同一台服务器上而且跨域请求默认不带Cookie。业界主流的替代方案就是JWTJSON Web Token。JWT的核心流程是用户提交用户名密码后端校验通过后生成一个Token返回给前端。前端把Token存到localStorage或Pinia里每次请求在请求头加上Authorization: Bearer 。后端通过拦截器或过滤器解析Token把用户信息放入请求上下文方便后续业务逻辑获取当前登录用户。实际开发中我建议JWT的过期时间设置在2小时左右同时做一个简单的“续签”策略当Token剩余有效期低于一半时后端在响应头里返回新的Token前端拦截器收到后自动更新本地存储。这样用户长时间操作时不会突然掉线。要注意的是JWT的密钥不要硬编码在代码里应该放在配置文件或者环境变量中否则源码泄露后攻击者可以任意伪造Token。后端的过滤器链上也建议加上统一的跨域配置允许前端域名携带Authorization头Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedHeader(*); config.addAllowedMethod(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }注意allowedOriginPattern不要写固定域名开发环境下前端跑在8080或者5173端口生产环境又有可能挂别的域名用通配符更省心。3.2 商品与订单的关键代码商品列表接口是典型的列表业务核心是分页 条件筛选。Controller层接收pageNum、pageSize、keyword、categoryId、sort等参数Service层组装查询条件Mapper层写动态SQL。这里直接给一个商品查询的Mapper示例select idselectProductList resultTypecom.example.entity.Goods SELECT id, category_id, name, subtitle, main_image, price, sales, status FROM goods where if testkeyword ! null and keyword ! AND name LIKE CONCAT(%, #{keyword}, %) /if if testcategoryId ! null AND category_id #{categoryId} /if AND status 1 /where ORDER BY ${sort} LIMIT #{offset}, #{pageSize} /select这里有个细节ORDER BY后面的字段不能直接用#{}拼接因为JDBC预编译参数会被当作字符串值处理导致排序失效甚至报错。所以要保证传入的sort值在白名单里比如在代码里先判断一下。创建订单的Service方法是整个后端业务里逻辑最紧凑的地方一般步骤是校验收货地址、用户状态。根据购物车选中的商品加锁或条件更新扣减库存。计算订单金额建议价格以数据库为准不要信前端传的金额。生成订单号和订单明细。清空购物车中已下单的商品。事务提交返回订单ID。每一步失败都要抛异常触发整体回滚不能让“商品扣了但订单没建”这种状态出现。3.3 MyBatis分页与缓存MyBatis的分页插件PageHelper是Java后端的老朋友了用法很简单PageHelper.startPage(pageNum, pageSize); ListGoods list goodsMapper.selectList(); PageInfoGoods pageInfo new PageInfo(list);这里有个需要特别注意的坑PageHelper.startPage()会让紧跟其后的第一条SQL查询自动分页如果你在调Mapper之前先执行了其他查询分页就串了。所以startPage和第一次Mapper查询之间不要插入任何DB操作。电商后台列表很多会同时返回分类树和商品列表这时候一定要检查“分页失效”的情况是不是因为前面先查了分类。MyBatis本身自带一级缓存和二级缓存但实际开发中不要过于依赖它。一级缓存是SqlSession级别的Spring管理的事务里多次查询同一个Mapper方法可以命中缓存但一旦中间有增删改操作缓存就被清掉了。二级缓存默认不开启且配置不慎还容易读到脏数据。业务缓存我依然建议交给Redis一个是缓存生命周期可控一个是可以做更细粒度的缓存更新策略。比如首页的商品推荐列表可以把接口结果缓存到Redis设置5分钟过期这比每次打MySQL查询快得多而且能显著减轻数据库压力。4. 前端Vue3怎么把商城撑起来4.1 项目初始化与路由设计前端工程使用Vite创建Vue3项目是最省事的npm create vitelatest mall-web -- --template vue装好依赖后安装Vue Router、Pinia、Axios和Element Plusnpm install vue-router4 pinia axios element-plus路由设计建议用两种布局用户端布局和后台布局各配一套嵌套路由。比如用户端是首页/分类/购物车/我的后台是商品管理/订单管理/用户管理/数据统计。路由守卫要做登录校验访问需要登录的页面时检查本地Token是否存在不存在就重定向到登录页。我个人的习惯是把路由表拆成静态路由和动态路由两部分用户端全部静态配置后台管理页面根据用户的role字段在登录后动态注入进来。这样管理员和普通用户看到的东西天然隔离不用在页面里老写v-if判断角色。4.2 状态管理与接口封装Pinia是Vue3官方推荐的状态管理库用它来存用户信息、Token、购物车数量、全局Loading状态都很顺手。接口请求封装的重点是Axios实例的拦截器。我在请求拦截器里统一加Token在响应拦截器里统一处理错误码、Token过期跳转和“后端返回二进制文件流”等特殊情况。一个简化版的Axios封装大概是这样的const service axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL, 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( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res }, error { if (error.response?.status 401) { localStorage.removeItem(token) router.push(/login) } return Promise.reject(error) } )这套封装的思路很直接让页面里的业务代码只关心数据不需要反复处理Token和错误提示。4.3 后端管理界面的落地管理端直接用Element Plus的表格、表单、弹窗、菜单组件就可以快速搭出来。商品管理的典型页面就是顶部搜索栏、中间表格、右侧分页器。搜索栏绑定表单数据点击查询时重新拉接口。购物车页面有一处交互细节很容易被忽略修改商品数量后要同时重新计算总价。建议把购物车的勾选状态和数量统一存到Pinia里用getter派生总价这样UI上任何变更都会自动更新结算金额不需要在多个组件里同步状态。另一个容易被忽视的是图片上传。商品图片上传接口一般由后端提供接收MultipartFile保存到服务器或对象存储返回可访问的URL。前端用Element Plus的Upload组件时注意把action属性指到后端接口同时带上Token请求头否则上传会401。5. 前后端联调与部署上线的坑5.1 跨域、JWT、时间格式联调最常见的三个问题我一个个说。跨域问题。如果后端配置了CORS前端代理一般就不用配了。开发时Vite的proxy也可以解决跨域// vite.config.js server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }但要注意使用proxy时前端请求的URL是相对路径生产环境就不能依赖Vite的代理了得靠Nginx把/api路径转发到后端服务。JWT过期问题。很多初学者会把Token过期时间设置得很长比如7天图省事。但这样安全性很差其实更好的做法是刷新机制请求时如果发现Token快过期了刷新接口返回新Token前端统一替换。时间格式问题。后端返回的LocalDateTime默认序列化成数组或者带T的字符串前端显示很怪。正确做法是在后端的application.yml里配置全局时间格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8这样前端直接拿到的是可读性很好的字符串不用自己做格式化。5.2 部署方案与服务器配置前后端分离项目的部署我的推荐方案是后端用Maven打包成Jar包服务器上使用systemd或Docker守护进程跑起来监听8080端口。前端用npm run build打包成dist静态目录用Nginx托管。Nginx里同时做两件事静态资源服务和API反向代理。一个基础但完整的Nginx配置示例server { listen 80; server_name your-domain.com; root /var/www/mall-web/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location / { try_files $uri $uri/ /index.html; } }注意try_files那一行它是Vue Router的history模式能正常刷新的关键。不写这一行用户访问首页时好好的一刷新或者直接访问二级路径就404。数据库部署MySQL 8.0安装后要注意字符集设置成utf8mb4否则存储emoji或者一些特殊符号会失败。5.3 常见错误排查速查我把实际开发里见过频率最高的错误和排查方向整理成一个速查表。待排查现象可能原因排查方式前端请求跨域报错后端CORS未配置或配置错误查看响应头是否有Access-Control-Allow-Origin登录后请求401Token失效、请求头没带Authorization打开Network面板确认请求头前端列表不分页PageHelper.startPage被其他查询消费检查startPage与Mapper查询之间是否有额外DB操作MySQL中文乱码表或连接字符集不是utf8mb4检查数据库连接参数characterEncodingutf8上传图片后无法访问静态资源映射未配置后端配置WebMvcConfigurer添加资源映射或用Nginx托管上传目录页面刷新404前端history路由未做try_files回退修改Nginx配置并reload商品库存超卖扣库存SQL没有条件判断改成UPDATE ... WHERE stock ?的方式排查问题时养成“从底层往上查”的习惯先看数据库里数据对不对再看后端接口返回了什么最后看前端渲染逻辑。很多联调问题其实都是后端返回的数据结构跟前端预期不一致造成的。6. 这套源码能拿来干什么6.1 学习路径建议如果你的目标是学技术我建议按下面这条路径去用这套源码第一步是把项目跑起来前后端都启动浏览器里过一遍完整流程注册、下单、后台发货感受一个完整系统长什么样。第二步是断点调试后端比如跟着创建订单的接口把Controller、Service、Mapper的调用链看一遍理解事务在哪里开启、库存什么时候扣、购物车什么时候清。第三步是尝试改需求。比如给商品表加一个“是否推荐”的字段从数据库、后端接口、前端页面一路改下来。这个过程能帮你把零散的知识点串联成一个完整的技能图谱。如果是为了面试准备重点关注三个方面的题目JWT认证原理和刷新机制、MyBatis分页插件的原理、订单超卖如何处理。这三块能讲清楚说明你真的理解了这套系统而不是只写过CRUD。6.2 扩展方向这套系统是一个很好的起点但离生产级别还有距离。如果你有时间可以在它基础上扩展以下几个方向引入Redis。把首页数据、商品详情、验证码、Token黑名单放到Redis里顺便学一下缓存穿透、缓存击穿、缓存雪崩的应对思路。引入消息队列。比如下单成功后发一条MQ消息异步更新商品的销量统计或者做一个延迟队列来处理“超过30分钟未支付自动关单”。引入Elasticsearch。把商品搜索从MySQL的LIKE查询换成ES的全文检索顺便学习一下倒排索引的原理。加入秒杀功能。用Redis预扣库存 MQ异步下单的方式来抗住瞬时流量这个做完你对高并发的理解会上一个台阶。这些扩展方向每挑一个深入下去都可以再撑起一整个项目的简历篇幅。电商系统的核心就是“人、货、单”三件事的流转。把这套前后端分离的商城源码吃透你不仅能掌握SpringBoot Vue3这套主流技术栈的日常用法还能理解一个真实业务系统从数据库设计到接口实现、从前端交互到部署上线的完整链路。后面无论你是打算找一份Java开发的工作还是想基于这个项目二次开发成自己作品的Demo这条路都算是踩在了一个非常正确且扎实的起点上。 Java SpringBoot Vue3全栈商城系统设计与实现解析
这一套「Java SpringBoot Vue3 MyBatis MySQL」的在线商城系统源码算是这几年Java后端很主流、也最适合练手的一类全栈项目了。前后端分离、RESTful接口、JWT鉴权、商品订单流转、后台管理覆盖了一个中型Web系统的大部分核心知识点。不管是拿来做毕业设计、个人作品集还是想系统性理解一套真实电商业务怎么落地都值得好好拆一遍。我从开发者的视角把这套系统的架构设计、数据库建模、后端核心实现、前端工程化、联调部署这些环节逐个说清楚顺便把实际开发中容易踩的坑和常用的排查思路也整理出来希望能帮你少走一些弯路。1. 一个在线商城系统到底包含什么1.1 为什么是这套技术组合先说技术选型。Java SpringBoot是当前企业级后端最主流的组合之一SpringBoot简化了Spring的配置内嵌Tomcat打一个Jar包就能跑非常适合快速交付业务接口。MyBatis作为持久层框架SQL由开发者自己控制调优空间大尤其适合电商这种查询条件复杂、报表类的SQL比较多的场景。MySQL则是开源关系型数据库里的常青树事务、索引、主从复制能力都足够支撑中小型商城的业务量。前端选Vue3配合Vite构建工具、Pinia状态管理、Vue Router路由和Element Plus组件库算是目前Vue生态里最标准的一套组合。用它来做后台管理界面和用户端页面开发效率很高组件复用也方便。前后端分离是这个项目最值得关注的地方。后端只提供JSON格式的API接口前端通过HTTP请求调用两者之间通过接口文档或TypeScript类型定义来约定数据格式。好处是前后端可以并行开发后端不关心页面长什么样前端不关心SQL怎么查部署时也可以分开扩容。1.2 系统功能模块划分一套可用的商城系统从用户角色角度能拆成两块。用户端前台商城包含用户注册、登录、个人信息维护商品分类浏览、关键词搜索、商品详情查看购物车管理添加、修改数量、删除、选中结算下单结算、订单支付一般用模拟支付订单列表、订单详情、确认收货、取消订单收货地址管理管理端后台管理包含管理员登录与权限校验商品管理上架、下架、新增、编辑、库存维护分类管理树形结构订单管理查看订单、发货、退款处理用户管理查看用户列表、禁用账号数据统计订单量、销售额、热门商品这套前后端分离架构下所有功能都走API接口所以接口设计是否规范直接决定系统的可维护性。一般的做法是用RESTful风格资源用名词复数表示操作通过HTTP方法区分。比如GET /api/products表示商品列表POST /api/orders表示创建订单。1.3 前后端分离的代价与收益前后端分离不是银弹它解决了“代码纠缠”的问题同时也引入了新的问题跨域配置、Token传递、接口联调成本、部署时需要分别处理静态资源和后端服务。我把它的收益和代价都列一下。收益方面第一是职责清晰后端只关心业务和数据处理前端只关心交互和渲染第二是开发和部署灵活后端用Docker、前端用Nginx各自扩容第三是天然适合多端复用同一套API可以同时服务Web端、小程序端和App端。代价方面第一是开发初期需要定义清晰的接口规范否则联调阶段会很痛苦第二是前端需要处理CORS跨域、Token刷新、错误码统一解析这些额外逻辑第三是调试成本会高一些查一个问题往往要在浏览器Network面板、后端日志、数据库三个地方来回跳。所以如果你刚接触这类项目建议不要一上来就追求微服务、分布式那一套先把这个“单体SpringBoot 独立Vue前端”的结构吃透后面再逐步引入Redis、MQ、ES这些组件反而是更接地气的成长路径。2. 数据库设计决定商城能走多远2.1 核心表结构与关系数据库设计是整个项目的地基这块搞不好后面写接口时会非常难受。一个最小可用的商城数据库至少需要这几张表。用户表sys_user存用户与管理员账号共用或分表都可以建议至少包含id、username、password加密后的密文、nickname、avatar、role、status、create_time这些字段。商品表goods包含id、category_id、name、subtitle、main_image、detail富文本、price、stock、sales、status上下架、create_time。price建议用decimal(10,2)不要用float否则金额会出现精度问题。分类表category做两级分类就够了id、parent_id、name、sort_order用自关联来处理父子层级。购物车表cart_item包含id、user_id、goods_id、quantity、checked前端在用户不登录时也可以用localStorage存购物车登录后同步到后端。订单表orders是核心中的核心字段至少要有id、order_no订单编号、user_id、total_amount、pay_amount、freight_amount、status、receiver_name、receiver_phone、receiver_address、pay_time、deliver_time、finish_time、create_time。订单编号建议用时间戳 随机数生成唯一值不要直接使用数据库自增id暴露给用户。订单明细表order_item包含id、order_id、goods_id、goods_name、goods_image、goods_price、quantity、total_price。为什么订单要冗余商品名称和图片因为商品信息是易变的用户下单之后商家改了商品名你总不能把历史订单里的名字也改了吧。冗余字段是电商系统的常规操作。各表之间的关系用外键也可以但实际开发中更常见的做法是不建物理外键靠业务逻辑保证数据一致性。理由也很简单高并发场景下外键约束会影响写入性能而且分库分表之后外键根本没法跨库生效。所以字段关系体现在SQL的JOIN查询里而不是数据库约束上。2.2 订单状态机设计订单状态是整个系统里最需要理清楚的业务规则。常见的状态用整数或字符串表示都可以我习惯用整数比如0待付款1待发货已付款2待收货已发货3已完成确认收货4已取消付款前取消或超时未付5退款中 / 已退款这个状态机最关键的一点是状态流转是单向且有条件的。待付款可以取消或变成待发货待发货可以变成已取消商家取消但不能跳回待付款待收货只能变成已完成或进入售后流程。后端在更新状态时要有校验逻辑不能出现“已发货的订单被改成待付款”这种脏数据。一个实际的例子用户提交订单后状态是0支付回调成功后改成1。如果你之前没有定义好状态机的流转规则后面做后台“订单导出”功能时就会发现状态字段查出来一堆无法理解的数字还得维护一套映射关系。2.3 库存扣减的姿势库存扣减是商城系统的高频考点也是最容易出并发问题的地方。最简单的错误示范是先查询库存判断库存充足再执行更新这个流程在高并发下必然超卖。实际的解决方案有两种常用方案。第一种是使用数据库的乐观锁/条件更新UPDATE goods SET stock stock - #{quantity} WHERE id #{goodsId} AND stock #{quantity}这条SQL同时完成了“检查库存”和“扣减库存”两个动作通过受影响行数判断是否扣减成功。如果返回0说明库存不足或商品不存在业务层再抛出异常。这种方式不需要额外引入分布式锁在单体应用场景下完全够用。第二种是使用Redis预扣库存下单时在Redis里扣减异步同步到MySQL适合高并发秒杀场景。这套系统如果定位是学习用掌握第一种方案就够了。实际写业务的时候还会有个小细节用户下单通常有“锁定库存—支付—扣减库存”或者“支付即扣减”两种流程。简化版本可以直接在创建订单时扣减库存取消订单/超时未付时回补库存。这要求事务边界一定要清晰扣库存和创建订单必须放在同一个事务里否则会出现订单建了但库存没了或者库存扣了但订单失败的情况。3. 后端核心逻辑与实现细节3.1 用户的登录认证怎么做这套系统是前后端分离的Session这种方案天然不友好因为前端和后端可能不在同一台服务器上而且跨域请求默认不带Cookie。业界主流的替代方案就是JWTJSON Web Token。JWT的核心流程是用户提交用户名密码后端校验通过后生成一个Token返回给前端。前端把Token存到localStorage或Pinia里每次请求在请求头加上Authorization: Bearer 。后端通过拦截器或过滤器解析Token把用户信息放入请求上下文方便后续业务逻辑获取当前登录用户。实际开发中我建议JWT的过期时间设置在2小时左右同时做一个简单的“续签”策略当Token剩余有效期低于一半时后端在响应头里返回新的Token前端拦截器收到后自动更新本地存储。这样用户长时间操作时不会突然掉线。要注意的是JWT的密钥不要硬编码在代码里应该放在配置文件或者环境变量中否则源码泄露后攻击者可以任意伪造Token。后端的过滤器链上也建议加上统一的跨域配置允许前端域名携带Authorization头Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedHeader(*); config.addAllowedMethod(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }注意allowedOriginPattern不要写固定域名开发环境下前端跑在8080或者5173端口生产环境又有可能挂别的域名用通配符更省心。3.2 商品与订单的关键代码商品列表接口是典型的列表业务核心是分页 条件筛选。Controller层接收pageNum、pageSize、keyword、categoryId、sort等参数Service层组装查询条件Mapper层写动态SQL。这里直接给一个商品查询的Mapper示例select idselectProductList resultTypecom.example.entity.Goods SELECT id, category_id, name, subtitle, main_image, price, sales, status FROM goods where if testkeyword ! null and keyword ! AND name LIKE CONCAT(%, #{keyword}, %) /if if testcategoryId ! null AND category_id #{categoryId} /if AND status 1 /where ORDER BY ${sort} LIMIT #{offset}, #{pageSize} /select这里有个细节ORDER BY后面的字段不能直接用#{}拼接因为JDBC预编译参数会被当作字符串值处理导致排序失效甚至报错。所以要保证传入的sort值在白名单里比如在代码里先判断一下。创建订单的Service方法是整个后端业务里逻辑最紧凑的地方一般步骤是校验收货地址、用户状态。根据购物车选中的商品加锁或条件更新扣减库存。计算订单金额建议价格以数据库为准不要信前端传的金额。生成订单号和订单明细。清空购物车中已下单的商品。事务提交返回订单ID。每一步失败都要抛异常触发整体回滚不能让“商品扣了但订单没建”这种状态出现。3.3 MyBatis分页与缓存MyBatis的分页插件PageHelper是Java后端的老朋友了用法很简单PageHelper.startPage(pageNum, pageSize); ListGoods list goodsMapper.selectList(); PageInfoGoods pageInfo new PageInfo(list);这里有个需要特别注意的坑PageHelper.startPage()会让紧跟其后的第一条SQL查询自动分页如果你在调Mapper之前先执行了其他查询分页就串了。所以startPage和第一次Mapper查询之间不要插入任何DB操作。电商后台列表很多会同时返回分类树和商品列表这时候一定要检查“分页失效”的情况是不是因为前面先查了分类。MyBatis本身自带一级缓存和二级缓存但实际开发中不要过于依赖它。一级缓存是SqlSession级别的Spring管理的事务里多次查询同一个Mapper方法可以命中缓存但一旦中间有增删改操作缓存就被清掉了。二级缓存默认不开启且配置不慎还容易读到脏数据。业务缓存我依然建议交给Redis一个是缓存生命周期可控一个是可以做更细粒度的缓存更新策略。比如首页的商品推荐列表可以把接口结果缓存到Redis设置5分钟过期这比每次打MySQL查询快得多而且能显著减轻数据库压力。4. 前端Vue3怎么把商城撑起来4.1 项目初始化与路由设计前端工程使用Vite创建Vue3项目是最省事的npm create vitelatest mall-web -- --template vue装好依赖后安装Vue Router、Pinia、Axios和Element Plusnpm install vue-router4 pinia axios element-plus路由设计建议用两种布局用户端布局和后台布局各配一套嵌套路由。比如用户端是首页/分类/购物车/我的后台是商品管理/订单管理/用户管理/数据统计。路由守卫要做登录校验访问需要登录的页面时检查本地Token是否存在不存在就重定向到登录页。我个人的习惯是把路由表拆成静态路由和动态路由两部分用户端全部静态配置后台管理页面根据用户的role字段在登录后动态注入进来。这样管理员和普通用户看到的东西天然隔离不用在页面里老写v-if判断角色。4.2 状态管理与接口封装Pinia是Vue3官方推荐的状态管理库用它来存用户信息、Token、购物车数量、全局Loading状态都很顺手。接口请求封装的重点是Axios实例的拦截器。我在请求拦截器里统一加Token在响应拦截器里统一处理错误码、Token过期跳转和“后端返回二进制文件流”等特殊情况。一个简化版的Axios封装大概是这样的const service axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL, 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( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res }, error { if (error.response?.status 401) { localStorage.removeItem(token) router.push(/login) } return Promise.reject(error) } )这套封装的思路很直接让页面里的业务代码只关心数据不需要反复处理Token和错误提示。4.3 后端管理界面的落地管理端直接用Element Plus的表格、表单、弹窗、菜单组件就可以快速搭出来。商品管理的典型页面就是顶部搜索栏、中间表格、右侧分页器。搜索栏绑定表单数据点击查询时重新拉接口。购物车页面有一处交互细节很容易被忽略修改商品数量后要同时重新计算总价。建议把购物车的勾选状态和数量统一存到Pinia里用getter派生总价这样UI上任何变更都会自动更新结算金额不需要在多个组件里同步状态。另一个容易被忽视的是图片上传。商品图片上传接口一般由后端提供接收MultipartFile保存到服务器或对象存储返回可访问的URL。前端用Element Plus的Upload组件时注意把action属性指到后端接口同时带上Token请求头否则上传会401。5. 前后端联调与部署上线的坑5.1 跨域、JWT、时间格式联调最常见的三个问题我一个个说。跨域问题。如果后端配置了CORS前端代理一般就不用配了。开发时Vite的proxy也可以解决跨域// vite.config.js server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }但要注意使用proxy时前端请求的URL是相对路径生产环境就不能依赖Vite的代理了得靠Nginx把/api路径转发到后端服务。JWT过期问题。很多初学者会把Token过期时间设置得很长比如7天图省事。但这样安全性很差其实更好的做法是刷新机制请求时如果发现Token快过期了刷新接口返回新Token前端统一替换。时间格式问题。后端返回的LocalDateTime默认序列化成数组或者带T的字符串前端显示很怪。正确做法是在后端的application.yml里配置全局时间格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8这样前端直接拿到的是可读性很好的字符串不用自己做格式化。5.2 部署方案与服务器配置前后端分离项目的部署我的推荐方案是后端用Maven打包成Jar包服务器上使用systemd或Docker守护进程跑起来监听8080端口。前端用npm run build打包成dist静态目录用Nginx托管。Nginx里同时做两件事静态资源服务和API反向代理。一个基础但完整的Nginx配置示例server { listen 80; server_name your-domain.com; root /var/www/mall-web/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location / { try_files $uri $uri/ /index.html; } }注意try_files那一行它是Vue Router的history模式能正常刷新的关键。不写这一行用户访问首页时好好的一刷新或者直接访问二级路径就404。数据库部署MySQL 8.0安装后要注意字符集设置成utf8mb4否则存储emoji或者一些特殊符号会失败。5.3 常见错误排查速查我把实际开发里见过频率最高的错误和排查方向整理成一个速查表。待排查现象可能原因排查方式前端请求跨域报错后端CORS未配置或配置错误查看响应头是否有Access-Control-Allow-Origin登录后请求401Token失效、请求头没带Authorization打开Network面板确认请求头前端列表不分页PageHelper.startPage被其他查询消费检查startPage与Mapper查询之间是否有额外DB操作MySQL中文乱码表或连接字符集不是utf8mb4检查数据库连接参数characterEncodingutf8上传图片后无法访问静态资源映射未配置后端配置WebMvcConfigurer添加资源映射或用Nginx托管上传目录页面刷新404前端history路由未做try_files回退修改Nginx配置并reload商品库存超卖扣库存SQL没有条件判断改成UPDATE ... WHERE stock ?的方式排查问题时养成“从底层往上查”的习惯先看数据库里数据对不对再看后端接口返回了什么最后看前端渲染逻辑。很多联调问题其实都是后端返回的数据结构跟前端预期不一致造成的。6. 这套源码能拿来干什么6.1 学习路径建议如果你的目标是学技术我建议按下面这条路径去用这套源码第一步是把项目跑起来前后端都启动浏览器里过一遍完整流程注册、下单、后台发货感受一个完整系统长什么样。第二步是断点调试后端比如跟着创建订单的接口把Controller、Service、Mapper的调用链看一遍理解事务在哪里开启、库存什么时候扣、购物车什么时候清。第三步是尝试改需求。比如给商品表加一个“是否推荐”的字段从数据库、后端接口、前端页面一路改下来。这个过程能帮你把零散的知识点串联成一个完整的技能图谱。如果是为了面试准备重点关注三个方面的题目JWT认证原理和刷新机制、MyBatis分页插件的原理、订单超卖如何处理。这三块能讲清楚说明你真的理解了这套系统而不是只写过CRUD。6.2 扩展方向这套系统是一个很好的起点但离生产级别还有距离。如果你有时间可以在它基础上扩展以下几个方向引入Redis。把首页数据、商品详情、验证码、Token黑名单放到Redis里顺便学一下缓存穿透、缓存击穿、缓存雪崩的应对思路。引入消息队列。比如下单成功后发一条MQ消息异步更新商品的销量统计或者做一个延迟队列来处理“超过30分钟未支付自动关单”。引入Elasticsearch。把商品搜索从MySQL的LIKE查询换成ES的全文检索顺便学习一下倒排索引的原理。加入秒杀功能。用Redis预扣库存 MQ异步下单的方式来抗住瞬时流量这个做完你对高并发的理解会上一个台阶。这些扩展方向每挑一个深入下去都可以再撑起一整个项目的简历篇幅。电商系统的核心就是“人、货、单”三件事的流转。把这套前后端分离的商城源码吃透你不仅能掌握SpringBoot Vue3这套主流技术栈的日常用法还能理解一个真实业务系统从数据库设计到接口实现、从前端交互到部署上线的完整链路。后面无论你是打算找一份Java开发的工作还是想基于这个项目二次开发成自己作品的Demo这条路都算是踩在了一个非常正确且扎实的起点上。