做家电类销售平台的项目这几年一直挺多，但真正把前后端分离、数据建模、业务闭环都讲明白的源码系统其实不多见。最近梳理了一个基于SpringBoot+Vue的家电销售展示平台管理系统，核心用Java+MySQL+MyBatis这一套经典组合来实现，正好适合正在做课程设计、毕业设计，或者想快速搭建一个电商类演示项目的开发者参考。

这个系统覆盖的不只是简单的商品增删改查，而是包括了家电商品的分类展示、购物车管理、订单状态流转、后台数据看板等功能，前端走Vue单页应用，后端用SpringBoot提供接口，我把整个设计思路、数据库表结构、核心接口逻辑、以及我在实测过程中踩过的坑，都整理到了这篇文章里。内容比较适合有一定Java基础、想了解完整项目怎么落地的读者，最后我会把部署运行和问题排查部分单独拿出来讲清楚。

1. 项目整体设计与技术选型思路

1.1 为什么选SpringBoot+Vue这套组合

现在做这类展示类管理平台，前后端分离基本是起步标准。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（路由配置） ├── store（Vuex状态管理） ├── 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 Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("success"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }

前端axios封装时统一做拦截处理：code为200时直接取data返回，非200时弹错误提示。这样大部分页面的异步请求逻辑可以复用同一套处理方式，新增接口时不用重复写异常提示逻辑。

3.2 商品分页查询与动态条件筛选

商品列表页是整个平台访问量最高的接口，用户会在这里按关键词搜索、按分类筛选、按价格区间筛选、按销量排序。对应的后端接口设计为GET请求：

GET /api/product/list?pageNum=1&pageSize=12&categoryId=1&keyword=电视&minPrice=1000&maxPrice=5000&sortType=sales

Service层最终调用Mapper里的一个动态SQL查询方法，核心SQL如下：

SELECT * FROM product_info WHERE status = 1 <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="keyword != null and keyword != ''"> AND (product_name LIKE CONCAT('%', #{keyword}, '%') OR brand LIKE CONCAT('%', #{keyword}, '%')) </if> <if test="minPrice != null"> AND price &gt;= #{minPrice} </if> <if test="maxPrice != null"> AND price &lt;= #{maxPrice} </if> ORDER BY <choose> <when test="sortType == 'sales'">sales DESC</when> <when test="sortType == 'price_asc'">price ASC</when> <when test="sortType == 'price_desc'">price DESC</when> <otherwise>create_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?id=xxx 获取每个商品的最新价格和库存状态 → 前端计算总价并渲染

这里有个细节：不直接存购物车表里的价格字段来展示，而是每次根据商品ID重新查商品表。因为购物车本质是“未确认的意向”，价格应该以当前商品实时价格为准。只有订单形成时才锁定快照价格。

4.4 后台管理页面的基础布局与表格数据流

后台管理页面用侧边栏+内容区的基础布局，侧边栏放导航菜单，内容区根据路由渲染对应组件。商品管理页的核心是一个可编辑的商品表格，加载时调用GET /api/admin/product/list拿到商品数据，表格里可以点击“上架/下架”按钮切换商品状态，弹窗表单添加或编辑商品信息。

编辑表单里分类下拉框的数据来自分类接口，两级分类用级联选择器实现。图片上传功能是本地演示版本，直接传图片字节流到后端映射到/static/upload/目录下，并返回可访问的图片URL。这个方案在单机部署的演示项目里够用了，但如果要做生产级系统，还是要考虑用对象存储服务。

5. 部署运行全流程与踩坑记录

5.1 本地环境准备与初始化步骤

整个系统需要以下环境：

• JDK 1.8或以上（推荐JDK 8，SpringBoot 2.x完全兼容）
• Maven 3.6+
• MySQL 5.7或8.0
• Node.js 14+（前端构建）
• IDE推荐IDEA（后端）和VS Code（前端）

数据库初始化分两步执行：先运行/sql/schema.sql建库建表，再运行/sql/data.sql导入演示数据，包括管理员账号、测试用户、商品分类、商品样例数据。这比手工一条条插入省事太多，演示数据里我准备了20件左右的常见家电商品，覆盖电视、冰箱、洗衣机、空调、微波炉、电饭煲、吸尘器、吹风机等分类，前后台都能直接看到效果。

后端配置在application.yml里：

spring: datasource: url: jdbc:mysql://localhost:3306/home_appliance?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/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 常见问题排查与解决方案速查

下面列几个实际开发中遇到频率最高的问题，都是源码运行阶段容易出的：

还有一个很容易忽略的问题：很多同学以为把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去理解每一步操作背后做了什么。这种方式理一遍之后，整个系统在你脑子里就是一张清晰的地图，后续改代码或者写论文的研究内容部分都会轻松很多。