SpringBoot+Vue+MyBatis+MySQL的家电销售展示平台实战

做了这么多年管理系统开发SpringBootVue的组合见得太多但专门面向“家电销售展示”场景的完整项目源码反而没那么普及。前阵子刚把一个基于SpringBootVueMyBatisMySQL的家电销售展示平台管理系统从零搭完从需求梳理、数据库建模到前端页面、后端接口再到部署上线整套流程走下来有不少值得记录的东西。这篇博文就把这个项目完整拆开讲适合正在做毕业设计、想转电商类管理系统的初学者也适合准备接家电行业信息化订单的开发者参考。先说清楚这个项目解决的是什么问题。家电行业的销售展示和普通电商不太一样商品参数多、规格复杂既有空调冰箱这种大件也有电饭煲吸尘器这种小家电而且线下门店和线上展示往往需要共用一套库存。单纯的商城或单纯的进销存都搞不定必须有一个同时兼顾“前台展示”和“后台管理”的平台。这个系统就是这样设计的前台给客户浏览家电、查看详情、下单后台给管理员维护商品、处理订单、管理分类和库存前后端分离接口驱动业务链路完整。1. 这类系统为什么需要“展示管理”双端设计1.1 家电销售业务的真实痛点我接到这个项目需求时对方第一句话就是“我们要一个官网一样的展示页面还得能管商品和订单”。这是很典型的口径翻译成技术语言就是前台页面要能展示商品、品牌、分类最好有搜索和筛选后台要能对商品做增删改查能管理订单状态能看库存。如果只做展示页数据维护就得靠开发改数据库运营根本玩不转如果只做管理系统客户又没法自助查看商品销售效率太低。所以展示端和管理端缺一不可。另外一个痛点是家电商品的属性特别杂。一台冰箱有容量、能效等级、制冷方式、面板材质一台电视有屏幕尺寸、分辨率、刷新率、HDMI接口数量。如果按照传统电商那种统一的“规格名-规格值”表去设计查询起来会非常绕。这个项目里我采用了“公共字段扩展参数JSON”的方式既保证了列表页需要的关键字段可以直接检索又照顾了不同品类家电之间的差异性。1.2 展示端与管理端的边界划分这个系统的边界划分原则很简单展示端只做读操作管理端负责写操作。前台所有请求都走查询接口下单也只在用户确认购买时才会触发写库后台则承担了商品管理、分类管理、订单处理、轮播图配置、用户管理这些重活。从工程结构上看一个SpringBoot服务同时提供两套接口路径/api/portal/**是展示端接口/api/admin/**是管理端接口。这样做的好处是前后端分离后同一个后端可以服务多个前端项目将来如果要做小程序端或移动端H5直接复用普通用户接口就行。而且权限拦截也方便管理员接口统一加鉴权普通接口只做基础校验。1.3 适合谁学习和复用如果你是刚学完SpringBoot和Vue、想找一个能写进简历的实战项目这套系统非常合适。它的技术栈主流、业务完整、代码量适中不像那种纯CRUD的demo也不像大型电商平台那样复杂到看不完。如果你是要接家电行业的信息化项目这套源码里关于商品参数、订单状态流转、库存扣减的这些设计可以直接抄作业很多小家电企业的管理需求并不会比这个更复杂。2. 技术栈选型SpringBootVueMyBatisMySQL的适配逻辑2.1 后端为什么选SpringBootSpringBoot在Java生态里已经是事实标准尤其是这类管理系统的首选。它把Spring繁琐的XML配置全部干掉用自动配置和starter机制把依赖管理变得极其简单。这个项目里用到的核心依赖就是Web、MyBatis、MySQL驱动、Lombok再加一个JWT相关的工具包加起来没几行配置就能跑起来。选择SpringBoot还有一个特别现实的理由招人容易、资料多。不管是后续团队接手还是自己做毕业设计找参考资料社区里踩坑记录都非常充足。遇到奇奇怪怪的问题搜一下基本都能找到答案。这是技术选型里很容易被忽视但实际很重要的因素。2.2 前端为什么选VueVue在前端框架里的优势是上手曲线平缓、模板语法直观。这个项目要做的不只是几个静态页面还有商品列表、筛选条件、购物车、后台管理表格这些高频交互组件用原生JS写会非常痛苦用Vue配合Element UI可以极大提升开发效率。Vue的双向绑定在做筛选条件时尤其方便选品牌、选价格区间、选能效等级数据层直接维护一个queryParams对象页面自动响应更新。这里要说明一下我用的Vue版本是Vue 2 Element UI而非Vue 3 Element Plus。选Vue 2的原因很朴素这个系统要求兼容性稳定、组件生态成熟Element UI的文档和示例最多开发时遇到问题好解决。如果是从零开始的新项目上Vue 3 Vite Element Plus也完全可以只是组件API有些差异项目里就不混着写了。基于Vue的组件化机制同一套后端接口可以无缝对接两种前端框架。2.3 持久层为什么选MyBatisMyBatis和JPASpring Data JPA之间我最终选了MyBatis原因是家电商品的查询条件太灵活了。商品名模糊查询、品牌筛选、价格区间、分类筛选、能效等级这些条件用户想怎么组合就怎么组合MyBatis的动态SQL对这种多条件组合查询的支持非常自然where加if标签就能搞定SQL的可控性强性能调优也方便。MySQL作为数据库没有悬念项目体量在中小型应用范围内MySQL足够稳定部署成本低运维资料丰富。家电展示平台往往是读多写少MySQL默认的B树索引结构对这种场景的支撑非常到位配合Redis做缓存是后续优化方向但前期单库单表完全够用。表2-1列出这套选型和常见替代方案的对比方便你判断自己的场景是否适合对比项本方案替代方案选择理由后端框架SpringBootSSM手写整合SpringBoot自动配置省去大量XML开发效率高前端框架Vue 2 Element UIReact / Vue 3Vue模板语法简单Element UI组件齐全持久层MyBatisMyBatis-Plus / JPA动态SQL灵活SQL可调优MyBatis-Plus可后续引入数据库MySQLPostgreSQL部署简单生态成熟学习成本低鉴权方式JWT无状态Session Redis前后端分离下JWT更好扩展支持多端登录2.4 项目整体结构一览后端是标准的Maven多模块不这里我用的是单模块因为项目规模还没到需要拆分的程度。包结构按职责划分很直观controller、service、mapper、entity、dto、vo、config、common、utils。前端的src下按视图划分views/portal放展示端页面views/admin放管理端页面components放公共组件router做路由配置api封装axios请求。我把这种结构叫做“按端分层按业务聚合”。后端按技术层分包前端按业务端分包各管各的互不干扰。前后端通过JSON格式进行数据交换接口文档直接用Swagger生成联调的时候非常省心。3. 数据库设计家电商品特殊属性怎么建模3.1 核心表结构总览这个系统一共设计了8张核心表用户表、分类表、品牌表、商品表、商品参数表、订单表、订单项表、轮播图表。外加一个轮播图配置表虽然简单但实际业务里轮播图经常要改做成表比写死在配置里科学得多。商品表的设计是这个项目的重头戏。我把商品通用信息名称、主图、价格、库存、销量、上架状态、创建时间放到商品表把特殊属性能效等级、制冷方式、屏幕尺寸这些放到商品参数表用商品ID关联。这样列表页查商品时不需要解析JSON详情页读取参数时也只需要一次关联查询兼顾了性能和灵活性。3.2 分类与品牌的设计细节分类设计成两级一级分类大家电、厨卫电器、生活小电和二级分类空调、冰箱、洗衣机、电视、电饭煲、破壁机等。我用了很简单的parent_id自关联方式没有引入嵌套集模型因为这个业务场景下分类层级浅、数量少自关联完全够用查询也直观。品牌表单独建是为了前台筛选方便。家电领域品牌认知度很高用户会在列表页直接按品牌过滤也有按品牌查看全部在售商品的需求。商品表存brand_id外键品牌表有品牌名称和Logo图字段前台品牌筛选就是一次关联查询的事。3.3 商品参数表的JSON vs 关联表这里我犯过选择困难。格力空调参数方案有两种一种是商品参数表每行存一个param_name和param_value完全范式化将来想按参数搜索也行另一种是直接在商品表加一个params字段存JSON。最终我选了折中方案——参数表存JSON但不是一整个大JSON而是拆成basic_params、spec_params这种按组划分的JSON字段。这么做的原因是家电详情的参数展示是“分组式”的基本参数一组、规格参数一组、能效信息一组按组存JSON在读取时天然就能按组取出无需前端再做结构转换。如果将来要做参数级筛选可以再抽一张参数映射表属于演进方向不影响当前设计。商品表的关键字段如表3-1所示字段名类型说明idbigint主键自增category_idbigint二级分类IDbrand_idbigint品牌IDnamevarchar(200)商品名称subtitlevarchar(500)卖点副标题列表页展示main_imagevarchar(500)主图URLpricedecimal(10,2)售价stockint库存数量salesint销量statustinyint1上架 0下架is_hottinyint首页推荐标记3.4 MyBatis映射文件里的两个典型场景第一个是商品列表的多条件查询这是MyBatis动态SQL最精华的场景。where标签自动处理AND前缀每个if判断用户是否传入了对应条件组合起来就形成了“品牌分类价格区间关键字”的联合筛选。select idselectPageList resultTypecom.demo.entity.Product SELECT p.*, b.name AS brand_name, c.name AS category_name FROM product p LEFT JOIN brand b ON p.brand_id b.id LEFT JOIN category c ON p.category_id c.id where if testkeyword ! null and keyword ! AND p.name LIKE CONCAT(%, #{keyword}, %) /if if testbrandId ! null AND p.brand_id #{brandId} /if if testcategoryId ! null AND p.category_id #{categoryId} /if if testminPrice ! null AND p.price gt; #{minPrice} /if if testmaxPrice ! null AND p.price lt; #{maxPrice} /if if teststatus ! null AND p.status #{status} /if /where ORDER BY p.id DESC /select第二个是批量更新库存。订单支付成功后要扣减库存如果逐条循环更新在高并发场景下效率低且容易造成数据不一致。在MySQL的UPDATE语句中把库存值直接写成stock - #{quantity}配合WHERE stock #{quantity}加上库存充足的校验这是最经典的防超卖写法之一。update iddecreaseStock UPDATE product SET stock stock - #{quantity} WHERE id #{productId} AND stock gt; #{quantity} /update4. 后端SpringBoot核心实现从登录鉴权到订单流程4.1 包结构设计与职责划分后端代码的包结构直接决定了后续维护的幸福感。我的划分方式是比较标准的entity是数据库实体类dto是接收前端参数的传输对象vo是返回给前端的视图对象mapper是MyBatis接口service是业务逻辑层controller是接口入口层。common包里放统一返回结果Result、统一异常处理GlobalExceptionHandler和业务异常类。这里的统一返回结果很重要前后端分离后必须约定一个标准的数据包装格式否则前端每个接口都要单独解析非常容易出问题。我的格式很简单{ code: 200, message: success, data: {...} }前端axios拦截器统一判断Code后再决定是走成功逻辑还是弹错误提示。4.2 登录鉴权JWT方案的具体写法这个系统分两种角色普通用户和管理员。普通用户登录后可以在前台下单和管理个人资料管理员登录后进入后台管理界面。我没有用Session方案而是选择了JWT因为前后端分离后JWT天然无状态后端不需要维护Session存储扩容也更方便。登录接口的逻辑是接收用户名密码校验成功后生成一个Token把用户ID和角色写进Token前端拿到Token后存在LocalStorage里每次请求在axios拦截器中加上Authorization: Bearer token头。后端用一个拦截器解析Token解析失败直接返回401。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 { Claims claims JwtUtil.parseToken(token); request.setAttribute(userId, claims.get(userId)); request.setAttribute(role, claims.get(role)); return true; } catch (Exception e) { response.setStatus(401); return false; } } response.setStatus(401); return false; } }这个拦截器需要注册到WebMvcConfigurer中并且做好路径放行。放行规则是/api/portal/**下的商品查询接口全部放行用户登录接口放行/api/admin/**必须校验Token且角色为管理员/api/portal/order/**校验Token但不强制管理员角色。4.3 商品展示接口的设计思路前台商品接口的核心是GET /api/portal/product/page参数是pageNum、pageSize、keyword、brandId、categoryId、minPrice、maxPrice、sort。排序参数我支持了三种默认最新、销量倒序、价格升序/降序。这些排序在SQL层的实现方式不同默认和销量排序可以直接查询价格排序需要单独排序字段但实现起来也都不复杂。详情页接口是GET /api/portal/product/{id}返回的VO里包含了商品基本信息、参数JSON、品牌名、分类名。前端详情页要做的是把参数JSON按组渲染成表格这个逻辑放在前端还是后端我选择放后端在VO里直接定义好basicParams和specParams两个JSON对象前端只需要循环渲染省去前端解析拼接的步骤。首页还需要一个推荐商品接口逻辑很简单查is_hot1且status1的商品按销量排序取前8个。这是典型的读多写少场景后续可以加Redis缓存不过现阶段直接查MySQL也毫无压力。4.4 订单流程与事务处理订单是这个系统业务流程最复杂的部分。用户从购物车提交订单流程是校验购物车商品和库存、计算总价、生成订单主表记录、生成订单项表记录、扣减库存、清空购物车。任何一步失败都应该回滚所以这里必须加Transactional。Transactional(rollbackFor Exception.class) public Long createOrder(OrderCreateDTO dto) { // 1. 校验用户地址信息 // 2. 查询购物车明细校验商品状态和库存 // 3. 计算总价 // 4. 保存订单主表状态为待支付 // 5. 保存订单项列表 // 6. 批量扣减库存 // 7. 清空购物车 return order.getId(); }这里要特别提醒Transactional只对RuntimeException和Error回滚如果方法内有受检异常被捕获后不抛出事务不会回滚。我写的rollbackFor Exception.class就是把回滚范围扩大到所有异常这是实际项目中更安全的写法。订单状态我用整数表示0待支付、1已支付/待发货、2已发货、3已确认收货、4已取消、5已退款。状态流转的规则是待支付可以取消支付后变为待发货发货后用户可以确认收货订单完成后可以申请售后退款/退货。每个状态变化都在订单日志表里记录一条方便后期排查问题。5. 前端Vue页面与交互逻辑拆解5.1 前端整体路由规划Vue Router的路由分了两块/portal下的展示端页面和/admin下的管理端页面。展示端包括首页、商品列表页、商品详情页、购物车页、订单确认页、订单列表页、登录注册页管理端包括商品管理、分类管理、品牌管理、订单管理、轮播图管理、数据统计概览。管理端路由统一加一个meta: { requiresAuth: true, role: admin }配合路由守卫做权限控制。前端守卫判断用户是不是管理员不是就重定向到登录页。我不建议把安全完全交给前端前端守卫只是用户体验层面的拦截真正的权限校验必须以后端的JWT拦截器为准。5.2 商品列表页的组件化设计商品列表页是前端最复杂的页面。顶部是搜索栏左侧是品牌筛选和分类筛选主体是商品卡片网格右下角是分页组件。我把“筛选条件栏”和“商品卡片”拆成了独立组件列表页本身只负责维护筛选状态并刷新数据。筛选栏组件使用了Vue的v-model语法父组件传递queryParams对象子组件修改后触发更新父组件监听变化后重新调用接口。这个交互在Element UI里做起来很顺手表单组件和按钮组件都是现成的。商品卡片组件接收一个product对象展示主图、名称、副标题、价格和销量点击跳转到详情页。卡片组件看起来简单但有细节值得注意主图要用object-fit: cover固定宽高比否则不同尺寸的图片会把页面撑乱价格展示有两段一个小的¥符号加一个大号数字排版效果比直接拼字符串好看很多。5.3 购物车与结算流程的前端实现购物车我用的是后端存储方案购物车记录存在数据库表中用户登录后可以跨设备查看而不是存在LocalStorage里。在前端层面购物车页维护一个选中商品列表用户勾选商品后点击结算前端把选中项的ID列表传给订单确认页。订单确认页是整个前端逻辑最密集的页面展示商品清单、选择收货地址、计算总价、提交订单。这里有个典型问题用户停留时间长了商品价格可能已经变化所以不能直接用前端缓存的价格来提交而是要传商品ID数量由后端重新计算价格。前端只做展示计算权必须在后端。提交订单成功后跳转到一个模拟收银台页面这里没有接第三方支付而是提供一个“模拟支付”按钮用户点击后前端调用订单支付接口后端把订单状态从待支付改为待发货。如果要接入真实支付只需把支付接口里的逻辑替换成调用微信支付或支付宝的统一下单API其余订单流程完全不用改动。5.4 管理后台表格与表单的实现细节管理后台的本质就是一堆表格加表单但写得好不好差别很大。商品管理页的表格我用了Element UI的el-table列包括商品图片、名称、价格、库存、销量、上下架状态、操作按钮。操作按钮包括编辑、上下架切换、删除。删除用的是二次确认弹窗防止误操作。商品编辑表单是后台最复杂的表单。基本信息部分有商品名、副标题、分类、品牌、价格、库存、主图上传、参数配置。分类选择用的是级联选择器因为只有两级数据量很小一次拉全量即可。图片上传走的是后端/api/admin/upload接口后端把文件存到本地磁盘同时返回访问URL。这里关于图片存储的坑我放到下一节踩坑部分专门说。6. 实际开发中踩过的坑完整排查链路还原6.1 MyBatis动态SQL条件全空导致的全表查询开发中第一次遇到的问题是商品列表接口的SQL。原本想的是用户不传任何条件时应该返回空列表或默认显示部分商品但实际运行时发现当所有筛选条件都为空时where标签里一个条件都没有SQL就变成了SELECT * FROM product把下架商品和全部历史数据都查出来了。排查链路是这样的前端列表页第一次加载时没有传任何条件接口返回了所有商品其中包含大量status0的下架商品。我先检查前端的请求参数发现queryParams对象里所有字段都是空字符串和null然后检查后端的ProductQueryDTO发现确实一个条件都没进if。问题定位到SQL本身——where里如果没有条件MyBatis不会自动加WHERE但也不会帮你过滤状态。解决方案是在SQL里加一个强制条件p.status 1因为列表页默认只展示在售商品这个是业务逻辑兜底不能依靠前端传参。6.2 图片上传成功但页面访问404图片上传功能上线后前台商品主图一直加载失败。上传接口本身返回了成功但浏览器访问图片URL时404。排查时发现后端把图片保存到了项目本地磁盘的/upload目录下但SpringBoot默认的静态资源路径是classpath:/static/并没有把/upload映射为可访问的静态资源目录。解决方式是在配置类里加一个资源映射把/images/**请求映射到本地的upload目录。这里有个关键细节开发环境和生产环境的路径不一样不能写死绝对路径我用配置项file.upload-path来指定部署时可以通过启动参数动态设置。Configuration public class WebConfig implements WebMvcConfigurer { Value(${file.upload-path}) private String uploadPath; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/images/**) .addResourceLocations(file: uploadPath /); } }这个问题也提醒我凡是上传类功能一定要先确认静态资源的映射关系再开始写上传逻辑。上传接口的成功只是第一步能访问到才是真正的完成。6.3 事务不生效Service内部方法调用陷阱订单创建功能开发完成后做了一次并发测试结果发现库存被扣成负数还出现脏数据。排查链路比较长先看扣减库存的Mapper方法SQL写法没问题再看createOrder方法上的Transactional注解也加了最后用调试工具看日志发现方法执行中没有事务日志。原因很经典同一个类中A方法调用B方法B方法上的Transactional不生效。我的createOrder方法在Service内部调用了同类的decreaseStock方法decreaseStock上的事务注解被忽略了整个订单创建只有外层方法的事务在起作用。解决办法有两种一是把库存扣减方法拆到单独的Service类中通过Spring代理调用二是保持一个事务方法从入口开始所有数据库操作都放在这个方法内。我选择了后者因为订单创建是一个完整的聚合操作本来就该在一个事务里完成没必要拆成两个事务再合并。6.4 前后端联调时的跨域问题开发环境里前端跑在http://localhost:8080后端跑在http://localhost:9090跨域问题如期而至。浏览器的同源策略会阻止前端访问不同端口的后端接口axios请求直接报CORS error。我的解决方式是在SpringBoot里配置跨域过滤器。有很多人图省事会在Controller上加CrossOrigin但这样每个类都要加一编我选择全局配置。Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedMethod(*); config.addAllowedHeader(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }这里要区分一下开发环境的跨域处理和生产环境的跨域处理。开发环境可以直接放开跨域怎么方便怎么来但生产环境如果前后端部署在不同的域名下建议用Nginx反向代理来统一入口由代理转发后端请求而不是暴露出跨域配置。我实际部署时就是让前端请求同源的/api路径由Nginx把/api转发到后端的9090端口彻底规避了跨域。6.5 前端路由刷新404问题部署完成后又遇到一个问题用户访问/portal/product/12这个地址正常但刷新页面时Nginx返回404。原因是Vue Router用的History模式前端路由是浏览器端管理的Nginx层面没有对应的实际文件刷新时Nginx找不到这个路径就返回404。解决方案是让Nginx把所有非静态文件请求都重写到index.html这样前端路由就能接管的URL。这也是Vue项目部署到Nginx时的标配配置location / { try_files $uri $uri/ /index.html; }同样的问题在管理后台也存在所以我部署时不仅要配前端路由重写还要注意后端接口路径的/api不要被这个规则误伤。实际的Nginx配置是把location /api单独转发到后端服务location /才走前端history回退。7. 打包部署与基于这套系统的扩展思路7.1 开发环境与生产环境配置分离这个项目从开发到部署我一直坚持配置文件按环境拆开application-dev.yml和application-prod.yml通过启动参数--spring.profiles.activeprod来切换。开发环境的数据库连接、图片上传路径、日志级别都跟生产环境不同混在一起迟早会出问题。最典型的就是数据库连接开发时连本地库生产时连服务器库配置一旦混淆打包后启动就会连接失败。还有一个容易忽略的点是前端接口地址。开发时Vue通过Vite代理转发请求解决跨域生产环境打包后我用Nginx反向代理转发/api所以前端代码里只保留相对路径请求。如果你把前端和后端部署在不同域名下就需要在request.js里改为绝对地址但这会引入新的跨域问题不如统一走代理。7.2 Nginx部署前后端的具体步骤部署时我把前端打包后的dist目录放到服务器上的/usr/share/nginx/html目录后端用java -jar启动。Nginx配置的关键点有三个监听80端口、静态文件路径指向dist、/api开头的请求转发到http://localhost:9090。这是一个非常典型的单机部署方案很多中小项目的线上架构都是这么跑的。完整流程记录如下先在本地执行mvn clean package -DskipTests打包后端npm run build打包前端然后把后端jar包传到服务器用nohup java -jar xxx.jar --spring.profiles.activeprod 启动再把前端dist目录传到服务器指定目录最后配置Nginx并nginx -s reload。整个过程半小时内能完成难在首次配置时的细节踩坑。7.3 基于这套系统的后续扩展方向项目做完了但改进空间依然很大。第一个方向是引入Redis做首页推荐商品的缓存减少数据库压力第二个方向是接入真实支付SDK把模拟支付替换为微信或支付宝支付第三个方向是增加商品的评论和评分功能让展示端更像一个完整的电商平台第四个方向是把图片上传迁移到云存储避免本地磁盘容量和访问性能成为瓶颈。如果要做成真正可交付的商业项目我建议在代码里做一次重构把购物车、订单、库存扣减这些核心模块抽离成独立服务。不过对现阶段来说这套系统的意义在于让开发者完整经历从需求分析到系统上线的一个全过程它包含的每个环节——需求拆解、数据库建模、接口设计、前端页面开发、前后端联调、部署上线——都是实际工作中真正常用的技能。实际跑过一遍之后我对这套SpringBootVueMyBatisMySQL组合的认知也更深了一步。最初看各种教程时总觉得框架学习是最难的真正动手做才发现最花时间的永远是业务逻辑的完整性和边界情况的处理比如库存校验、订单状态机、权限控制。框架只是工具清晰的需求分析和严谨的工程实现才是这个项目能顺利交付的根本原因。