做家电类销售平台的项目这几年一直挺多但真正把前后端分离、数据建模、业务闭环都讲明白的源码系统其实不多见。最近梳理了一个基于SpringBootVue的家电销售展示平台管理系统核心用JavaMySQLMyBatis这一套经典组合来实现正好适合正在做课程设计、毕业设计或者想快速搭建一个电商类演示项目的开发者参考。这个系统覆盖的不只是简单的商品增删改查而是包括了家电商品的分类展示、购物车管理、订单状态流转、后台数据看板等功能前端走Vue单页应用后端用SpringBoot提供接口我把整个设计思路、数据库表结构、核心接口逻辑、以及我在实测过程中踩过的坑都整理到了这篇文章里。内容比较适合有一定Java基础、想了解完整项目怎么落地的读者最后我会把部署运行和问题排查部分单独拿出来讲清楚。1. 项目整体设计与技术选型思路1.1 为什么选SpringBootVue这套组合现在做这类展示类管理平台前后端分离基本是起步标准。SpringBoot负责提供RESTful接口前端Vue通过axios请求数据渲染页面两边互不干扰开发和调试效率明显更高。选SpringBoot而不是传统SSH框架核心原因在于它开箱即用、内置Tomcat、自动配置能力强一个内嵌容器就能把项目跑起来省去了大量XML配置的工作量。对于课程设计或毕业设计来说这意味着可以把更多精力放在业务逻辑本身而不是环境折腾上。MyBatis在这个项目里的定位是半自动ORM框架。它不像JPA那样全自动帮你生成SQL但也正因为这样复杂查询、多表关联、动态条件筛选这些场景反而更可控。家电销售平台里商品按品类、品牌、价格区间筛选是很常见的需求MyBatis的动态SQL写起来非常顺手拼接条件逻辑一目了然调试时直接把日志里的SQL拿出来执行就知道问题在哪。前端选Vue的理由更直接组件化开发让商品卡片、搜索栏、购物车这些UI模块可以独立维护配合Vue Router做页面路由Vuex管理用户登录状态和购物车数据整个前端代码结构清楚后续改起来也方便。1.2 系统功能模块梳理这个系统从功能上划分为两个端前台展示端和后台管理端。前台展示端面向普通用户核心功能包括用户注册登录、家电商品分类浏览、商品搜索与筛选、商品详情查看、购物车管理、订单提交与支付状态模拟、个人中心订单查询。这里的支付是模拟实现不会真正接入第三方支付网关主要演示订单状态从“待支付”到“已支付”再到“已完成”的流转过程。后台管理端面向管理员核心功能包括商品类别管理添加分类、上下级分类结构、商品信息管理新增商品、编辑库存、上下架操作、价格调整、订单管理查看订单明细、修改订单状态、用户管理用户列表、禁用/启用账号、数据统计销量统计、商品数量统计、分类占比展示。这些模块组合起来基本把家电销售平台的主线业务全部覆盖到了。业务逻辑上商品、订单、用户这三块是核心其他功能都是围绕这三块展开的辅助性模块。1.3 项目目录结构规划建议拿到源码之后先看目录结构这个项目在结构上做得比较规范src/main/java/com/example/homappliance ├── controller控制层接收前端请求 ├── service业务层处理业务逻辑 ├── mapper数据访问层接口 ├── entity实体类对应数据库表 ├── dto数据传输对象接收前端参数 ├── config配置类如跨域配置、拦截器配置 ├── common公共类如统一返回结果封装 ├── utils工具类如JWT工具、日期处理前端部分src ├── api封装axios请求 ├── assets静态资源 ├── components公共组件 ├── router路由配置 ├── storeVuex状态管理 ├── views页面组件按功能划分 │ ├── home首页 │ ├── product商品 │ ├── cart购物车 │ ├── order订单 │ ├── user个人中心 │ └── admin后台管理这种分层方式的核心思想是“各层只做自己该做的事”Controller只负责参数接收和结果返回不写业务Service专职处理业务规则Mapper只做数据库的增删改查。代码量上来之后这种职责清晰的分层会让排错容易很多。2. 数据库建模与核心表结构设计2.1 家电销售场景下的实体关系梳理数据库设计是整个系统里最不应该赶工的部分。家电商品有别于普通日用品它有品牌、型号、能耗等级、尺寸、颜色、库存量、销量等多个维度信息需要记录而且一个商品一定属于某个分类比如电视、冰箱、洗衣机、空调、小家电。用户下单后会产生订单主表和订单明细表订单明细表要记录下单时商品的快照价格而不是实时去查商品表因为商品价格会调整一旦调价历史订单里的价格不应该跟着变。结合这个场景核心的数据表包括user用户表ID、用户名、密码存加密后的哈希值、昵称、手机号、地址、角色、创建时间product_category商品分类表ID、分类名称、父级ID支持两级分类、排序号product_info商品表ID、分类ID、商品名称、品牌、型号、价格、库存、销量、状态上架/下架、图片地址、详情描述、创建时间cart_item购物车表ID、用户ID、商品ID、加入数量、选中状态、加入时间order_info订单主表ID、订单号、用户ID、总金额、订单状态、收货人信息、下单时间、支付时间order_item订单明细表ID、订单ID、商品ID、商品快照名称、商品快照图片、商品快照价格、购买数量admin_user管理员表ID、登录账号、密码、最后登录时间2.2 关键表字段设计的细节说明订单状态这个字段值得单独拎出来说。不要用字符串硬存比如“待发货”、“已发货”建议用整型或者枚举值0代表待支付1代表已支付2代表已发货如果是实体商品配送场景3代表已完成4代表已取消。存数字的好处是枚举扩展方便查询条件也能用范围查询。前后端同时维护一张状态枚举对照表状态含义发生变化时只改一处。商品表里有一点容易踩坑价格字段建议用DECIMAL(10, 2)绝不要用FLOAT或DOUBLE。浮点数在计算金额时会出现精度丢失比如 19.9 存进去再读出来可能变成 19.900000000000002累计几件后金额就变成 59.70000000000001到时候用户看到购物车金额多了1分钱还得质疑你系统算错了。用户密码字段一定要存加密后的值不要明文入库。项目里用的 BCrypt 加密Spring Security 里可以直接适配即使没有引入 Spring Security单独引入spring-security-crypto依赖调用 BCryptPasswordEncoder 也很方便。2.3 外键关联与索引规划家电销售平台在数据量不大的场景下外键约束可以用但在实际开发中更常见的做法是逻辑关联表之间不建物理外键通过业务代码保证数据一致性。原因很简单物理外键会在插入、更新、删除时增加约束检查影响并发写入性能而且一旦数据需要做分库分表物理外键就完全没法用了。这个项目里我用的是逻辑外键表设计时在关联字段上加上索引查询时通过JOIN或者多次查询来组装数据。索引规划上商品表的分类ID和状态字段要建联合索引因为用户浏览商品列表时的核心查询条件是WHERE category_id ? AND status 1订单表的下单时间加索引后台按时间范围统计销量会用到订单明细表的订单ID必须有索引查询订单详情时会频繁根据订单ID检索明细。SQL语句统一放在MyBatis的Mapper XML里管理用代码生成器生成了实体类和基础Mapper之后直接在这些基础上扩展业务SQL。这样改查询条件时打开XML一眼就能看到完整SQL逻辑不用满Java文件里翻注解。3. 后端核心接口设计与业务逻辑实现3.1 统一返回结构与接口规范前后端分离项目中接口返回的数据格式非常重要。这个项目统一采用了以下结构{ code: 200, message: success, data: { ... } }对应的Java封装类大概是这样的public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }前端axios封装时统一做拦截处理code为200时直接取data返回非200时弹错误提示。这样大部分页面的异步请求逻辑可以复用同一套处理方式新增接口时不用重复写异常提示逻辑。3.2 商品分页查询与动态条件筛选商品列表页是整个平台访问量最高的接口用户会在这里按关键词搜索、按分类筛选、按价格区间筛选、按销量排序。对应的后端接口设计为GET请求GET /api/product/list?pageNum1pageSize12categoryId1keyword电视minPrice1000maxPrice5000sortTypesalesService层最终调用Mapper里的一个动态SQL查询方法核心SQL如下SELECT * FROM product_info WHERE status 1 if testcategoryId ! null AND category_id #{categoryId} /if if testkeyword ! null and keyword ! AND (product_name LIKE CONCAT(%, #{keyword}, %) OR brand LIKE CONCAT(%, #{keyword}, %)) /if if testminPrice ! null AND price gt; #{minPrice} /if if testmaxPrice ! null AND price lt; #{maxPrice} /if ORDER BY choose when testsortType salessales DESC/when when testsortType price_ascprice ASC/when when testsortType price_descprice DESC/when otherwisecreate_time DESC/otherwise /choose LIMIT #{offset}, #{pageSize}分页这里没有引入PageHelper插件而是手动计算offset传入这样依赖更少也方便理解分页原理。LIMIT #{offset}, #{pageSize}里offset的计算是(pageNum - 1) * pageSize。页面上显示“共X条共Y页”需要另一个COUNT查询MyBatis里单独定义一个countByCondition方法和列表查询共用同一组动态SQL条件。3.3 商品快照机制与订单提交逻辑下单接口是整个项目里业务逻辑最密集的地方处理流程有五个关键步骤第一步接收前端传来的商品ID列表和数量列表。这部分参数用DTO接收校验参数合法性数量必须大于0。第二步根据商品ID批量查询商品信息锁定价格。注意这里查的是实时价格用于计算订单总额。第三步校验库存判断商品库存是否足够。库存不足时返回错误信息比如“商品xxx库存不足当前仅剩2件”。第四步生成订单。先生成订单主表记录订单号用时间戳加随机数生成然后把商品快照信息插入订单明细表。所谓快照就是把商品名称、图片、单价原样复制到订单明细表里这样哪怕后续商品改价或者删除用户的历史订单依然保留了下单时刻的商品信息。第五步扣减库存。扣减库存的SQL必须带上库存充足的条件UPDATE product_info SET stock stock - #{quantity}, sales sales #{quantity} WHERE id #{productId} AND stock #{quantity}这条SQL返回的影响行数如果为0说明并发下库存已经被扣完了此时需要抛出异常回滚整个下单事务。用这种方式做库存扣减比先查库存再判断再更新的方式更能防止“超卖”问题。下单操作整体用Transactional事务注解包裹任何一步出现异常都会整体回滚不会出现订单生成了但库存没扣的脏数据情况。3.4 JWT登录鉴权与拦截器设计用户登录成功后后端返回一个JWT令牌String token JwtUtil.createToken(userId, username, role);令牌里包含了用户ID、用户名、角色USER/ADMIN和过期时间密钥保存在配置文件中不硬编码在代码里。前端拿到token后存到localStorage每次axios请求在请求拦截器里加上Authorization: token请求头。后端这边使用HandlerInterceptor实现登录拦截public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || !JwtUtil.validateToken(token)) { response.setStatus(401); return false; } return true; } }拦截器注册时通过配置类指定拦截路径/api/admin/**下的所有请求要求管理员身份/api/cart/**和/api/order/**要求用户登录身份。登录注册接口和商品列表详情接口则放行因为游客也要能浏览商品。4. 前端页面流程与核心交互实现4.1 路由划分与页面结构前端使用Vue CLI构建配合Vue Router做路由管理。路由划分上前台页面和后台页面分开组织const routes [ { path: /, component: Home, meta: { title: 首页 } }, { path: /product/:id, component: ProductDetail, meta: { title: 商品详情 } }, { path: /cart, component: Cart, meta: { requiresAuth: true } }, { path: /order/list, component: OrderList, meta: { requiresAuth: true } }, { path: /login, component: Login }, { path: /register, component: Register }, { path: /admin, component: AdminLayout, meta: { requiresAdmin: true }, children: [ { path: products, component: AdminProduct }, { path: orders, component: AdminOrder }, { path: categories, component: AdminCategory }, { path: users, component: AdminUser }, { path: statistics, component: AdminStatistics } ] } ];路由守卫里判断requiresAuth和requiresAdmin未登录时跳转登录页非管理员访问后台时提示无权限。这样前端先做一层兜底后端拦截器再做一层校验双重保障。4.2 首页商品展示与搜索交互首页采用大图轮播分类导航商品列表的经典电商布局。轮播图的数据来源是后端配置的轮播图表商品列表默认显示新品推荐也就是创建时间倒序排列的前12件商品。用户点击左侧分类导航时前端根据分类ID重新请求商品列表接口同时更新URL的query参数刷新页面后依然保持选中状态。搜索框支持回车触发搜索同时做了简单的防抖处理用户停止输入800毫秒后才发送实际请求避免每敲一个字符都打一次接口。实现方式是在监听器里用setTimeout配合clearTimeout处理。商品卡片组件接收商品对象作为prop传入点击卡片跳转商品详情页。卡片上高亮展示价格、品牌、销量如果商品库存为0则显示灰色“已售罄”标签并禁止点击加入购物车按钮。4.3 购物车状态管理与数量修改购物车页面的实时性要求比商品列表更高用户修改数量、勾选商品、删除商品后总价都要立即变化。这里用Vuex统一管理购物车状态页面操作先修改本地Vuex数据作为“乐观更新”同时调用后端接口持久化修改结果。一旦接口报错把本地数据回滚到操作前的值并弹出错误提示。这样用户体验和鲁棒性兼顾。加入购物车的接口逻辑是把商品ID传过去数量默认传1。后端处理时先查购物车表里是否已有相同用户加相同商品记录如果存在则将数量累加否则插入一条新记录。购物车列表的整体流程进入购物车页面 → 请求 /api/cart/list 获取购物车数据 → 同时请求 /api/product/list?idxxx 获取每个商品的最新价格和库存状态 → 前端计算总价并渲染这里有个细节不直接存购物车表里的价格字段来展示而是每次根据商品ID重新查商品表。因为购物车本质是“未确认的意向”价格应该以当前商品实时价格为准。只有订单形成时才锁定快照价格。4.4 后台管理页面的基础布局与表格数据流后台管理页面用侧边栏内容区的基础布局侧边栏放导航菜单内容区根据路由渲染对应组件。商品管理页的核心是一个可编辑的商品表格加载时调用GET /api/admin/product/list拿到商品数据表格里可以点击“上架/下架”按钮切换商品状态弹窗表单添加或编辑商品信息。编辑表单里分类下拉框的数据来自分类接口两级分类用级联选择器实现。图片上传功能是本地演示版本直接传图片字节流到后端映射到/static/upload/目录下并返回可访问的图片URL。这个方案在单机部署的演示项目里够用了但如果要做生产级系统还是要考虑用对象存储服务。5. 部署运行全流程与踩坑记录5.1 本地环境准备与初始化步骤整个系统需要以下环境JDK 1.8或以上推荐JDK 8SpringBoot 2.x完全兼容Maven 3.6MySQL 5.7或8.0Node.js 14前端构建IDE推荐IDEA后端和VS Code前端数据库初始化分两步执行先运行/sql/schema.sql建库建表再运行/sql/data.sql导入演示数据包括管理员账号、测试用户、商品分类、商品样例数据。这比手工一条条插入省事太多演示数据里我准备了20件左右的常见家电商品覆盖电视、冰箱、洗衣机、空调、微波炉、电饭煲、吸尘器、吹风机等分类前后台都能直接看到效果。后端配置在application.yml里spring: datasource: url: jdbc:mysql://localhost:3306/home_appliance?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: yourpassword redis: host: localhost port: 6379 server: port: 8080 jwt: secret: your-secret-key expire-hours: 24如果你的项目没用Redis做缓存就把redis配置整段注释掉。启动后端时IDEA里直接运行启动类看到“Tomcat started on port(s): 8080”的日志就说明后端已经起来了。前端启动则是在Vue项目根目录执行两句命令npm install npm run dev默认端口为8080所以后端和前端在一个本机上会有端口冲突风险Vue CLI会提示你换个端口运行或者你在vue.config.js里把devServer端口改成8090再配上代理把/api前缀转发到后端8080端口。推荐方案是用代理这样前端代码里不需要写死后端地址后续部署到不同环境也不用改代码。5.2 跨域问题与请求代理配置前后端分离项目第一个绕不开的问题就是跨域。前端运行在8090端口后端在8080端口浏览器默认禁止跨端口请求。解决办法我推荐用Vue CLI的proxy配置而不是在后端代码里开启CORS// vue.config.js module.exports { devServer: { port: 8090, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这样浏览器发起/api/product/list请求时代理会转发到8080端口的后端服务从浏览器视角看请求是同源的不会出现跨域报错。如果后端也需要开放给外部域名访问那就得在后端配置CORS这个项目主要做本地演示代理方案就够了。5.3 常见问题排查与解决方案速查下面列几个实际开发中遇到频率最高的问题都是源码运行阶段容易出的问题现象可能原因解决办法后端启动失败报数据库连接错误数据库密码不匹配或数据库服务未启动检查application.yml里用户名密码确认MySQL服务已启动前端请求返回401token缺失或已过期重新登录获取新的token检查axios拦截器是否正确添加Authorization头商品图片不显示图片路径配置错误检查图片是否上传到后端静态资源目录配置了资源映射路径下单失败提示库存不足数据库中商品正好卖空换一个库存充足的商品测试或者在后台把库存改大中文乱码数据库连接字符集设置错误URL后面加characterEncodingutf8确认建表时用的utf8mb4端口占用上次启动没关干净用netstat -ano查看端口占用进程并结束还有一个很容易忽略的问题很多同学以为把MySQL的密码写在代码里是正常的但实际项目里推荐把数据库密码通过环境变量注入application.yml里用${MYSQL_PASSWORD}代替明文密码。这样源码公开时不需要担心密码泄露本地跑的时候再配置环境变量就行。5.4 MyBatis字段映射与SQL细节坑首次运行项目时最容易报的一个错是数据库表字段有下划线比如category_id而Java实体类是驼峰命名categoryId结果查询出来的对象属性全是null。解决方式是MyBatis全局配置开启驼峰映射mybatis: configuration: map-underscore-to-camel-case: true这是在application.yml里加的配置一键解决字段映射问题省得手写几百个resultMap。另一个常见问题是传参类型不匹配导致的SQL执行异常。比如前端传过来的排序类型是字符串price_asc后端接收后在SQL的ORDER BY中不能直接拼接这个字符串要像第三章里那样用choose标签做白名单判断确保只有符合条件的值才拼接进SQL。直接拼接前端参数会引入SQL注入风险这是项目里绝对不能出现的安全漏洞。MyBatis的#{}语法已经帮我们很好处理了参数注入的问题但ORDER BY后面的排序列名和排序方式这类关键字是不能用#{}占位的只能靠代码层做白名单过滤后再拼接。5.5 项目扩展方向与后续优化建议这个系统跑通之后可以往几个方向继续扩展。第一加Redis缓存把商品列表页的查询结果缓存起来设置5分钟过期时间能显著减少数据库压力第二引入ElasticSearch做商品搜索支持更复杂的搜索逻辑和更快的响应时间第三支付模块对接真实的第三方支付沙箱环境很多支付平台都提供测试账号可以模拟真实支付流程第四把后台管理的数据统计做成图表可视化接入ECharts展示销量趋势图和分类占比饼图。这些扩展方向本质上都是围绕同一个主线让系统的业务闭环更完整、数据更有价值。对于课程设计来说做到现有程度已经足够完整了但如果你想把它写进简历作为项目经历加上一个缓存优化和性能压测的数据说服力会强很多。6. 写在最后我个人实际测试这套系统的过程中最大的感受就是“能跑通全部流程”和“看起来功能齐全”之间是有本质区别的。很多演示项目停留在CRUD层面用户注册完不能下单下单完看不到订单状态后台改完数据前台没变化整体产品逻辑链是断的。而这个项目的优势在于从注册登录、浏览商品、加入购物车、提交订单、管理员处理订单到前台查看状态整条链路是完整打通的。代码量不算大但麻雀虽小五脏俱全。最后再分享一个小技巧如果你也是在做类似的项目拿到源码后不要急着改功能先把项目完整跑一遍用测试账号从前台到后台走一遍流程把每个接口的请求参数和返回结构用浏览器的开发者工具观察一遍再对照Mapper XML里的SQL去理解每一步操作背后做了什么。这种方式理一遍之后整个系统在你脑子里就是一张清晰的地图后续改代码或者写论文的研究内容部分都会轻松很多。