SpringBoot+Vue+MySQL家电销售平台管理系统源码解析

最近整理了一套家电销售展示平台信息管理系统源码，SpringBoot 做后端接口，Vue 写前端页面，MySQL 存数据，解压之后按步骤配置就能直接跑起来。这套东西我前后完整测了两轮，把里面容易卡壳的地方全摸了一遍，今天从架构设计、数据库表结构、后端核心链路、前端页面交互，一直到从零启动项目的完整步骤，全部拆开讲清楚。不管你是准备拿它当课程设计、毕业设计，还是想给某家线下家电门店搭一个线上展示加订单管理的小系统，这篇内容都能帮你省下不少弯路。

先说结论：这种项目的定位非常典型，就是一个以前后端分离为骨架的电商型管理系统。前台面向普通用户，负责商品浏览、分类检索、购物车、下单这整条交易链路；后台面向商家运营人员，负责商品上架、分类维护、订单处理、库存变更。它的复杂度控制得比较合适，没有引入微服务、消息队列这类重型组件，胜在结构干净、链路完整，特别适合用来理解一个带真实业务场景的 Web 系统，是怎么从数据库表一路写到页面交互的。下面我按实际开发顺序来复盘。

1. 项目核心拆解：这套系统到底做了什么

1.1 前台展示与后台管理的职能分工

很多第一次接触这类系统的人，容易被“前台”和“后台”两个词搞混。这里的前台不是指某个管理界面，而是普通用户直接看到的购物网站。用户打开系统首页，能看到滚动 banner、推荐商品、分类导航，点击商品卡片进入详情页，查看多张商品图片、价格、规格参数和库存状态，然后加入购物车，填写收货地址，生成订单。这整条体验链路就是前台的核心职责。

后台则是给门店运营人员使用的管理界面。运营人员登录之后，可以维护商品分类，比如空调、冰箱、洗衣机、厨卫电器这些；可以编辑商品信息，包括上下架、修改价格、调整库存、上传主图；还可以在订单列表里处理用户提交的订单，修改订单状态，从待付款改成已付款、已发货、已收货。前台和后台操作的是同一套数据库，数据能实时联动，这才是信息管理系统最重要的部分。

这套源码里，前后台共用同一个后端服务，通过接口路径前缀区分，比如/api/user开头的是前台接口，/api/admin开头的是后台管理接口。前端工程里也有两套页面区域，普通用户路由和后台管理路由分开配置，管理员登录之后才能看到后台入口。这种划分方式在实际项目中非常常见，既保证用户和运营各看各的，又不用维护两套独立系统。

1.2 家电品类在销售场景里的特殊要求

家电销售平台跟普通服饰、日用品电商有些不太一样的地方，这也是我当初拿到项目源码后重点审视的部分。首先是商品信息密度高，一台空调的参数包括品牌、型号、能效等级、匹数、制冷量、噪音值、保修年限，展示上不能只放一张图和一行价格，否则用户根本无法决策。这套系统在商品详情页做了富文本详情区域，支持大段图文混排，能把参数表格和安装说明完整放进去。

其次是价格和库存的变动频率。家电行业促销节点多，价格可能经常调整，所以商品价格字段不能写死，要有原价和现价的区分，同时促销阶段要能批量调整。库存方面，实体店和线上展示共用库存是很常见的场景，下单时必须做库存校验，防止超卖。另外就是图片处理，家电商品对实拍图、场景图的要求极高，一张高清大图往往决定转化率，所以商品图片需要支持多图存储。

这套系统的设计刚好覆盖了这些点，七张核心表把用户、商品、分类、购物车、订单、订单明细串成完整闭环。我在复测过程中认真过了一遍所有字段，没有发现明显的表结构硬伤，扩展空间也足够，后续如果想加评论、加规格参数、加优惠券，直接按现有逻辑堆表就行，改动量并不大。

2. 技术选型逻辑：为什么固定为 SpringBoot + Vue + MySQL

2.1 后端选 SpringBoot，图的是快速落地

现阶段的 Java Web 项目里，SpringBoot 基本是事实标准。为什么不用传统的 SpringMVC 加 XML 配置？因为太繁琐，一个工程光配置文件就要写好几种，新手上手成本高。SpringBoot 的自动配置机制把大部分重复劳动省掉了，内置 Tomcat 让应用可以直接用java -jar启动，同时生态成熟，整合 MyBatis、MySQL、JWT、文件上传都能在五分钟内完成。

这套系统采用的还是经典的三层架构：Controller 层接收请求、Service 层处理业务逻辑、Mapper 层操作数据库。Controller 保持轻量，不写具体业务，只负责参数校验和结果封装；Service 是核心，下单时的事务控制、库存扣减都在这一层写；Mapper 就是简单的接口加 XML 或者注解 SQL。这种分层方式看起来老套，但最大的好处是职责清晰、好排查问题，出了问题你能直接定位到是哪一层的锅。

我在使用过程中比较满意的是它对 MyBatis-Plus 的整合。MyBatis-Plus 提供了通用 CRUD 方法，单表查询几乎不用手写 SQL，分页可以直接用Page对象完成。当初如果用的是纯 MyBatis，分页查询还要手写LIMIT并计算总条数，代码量会明显增加。对于这样一个体量适中的系统，MyBatis-Plus 能节省大量时间。

2.2 前端选 Vue，界面组件化是最大优势

Vue 这套前端的核心价值在于组件化开发。电商页面里有大量重复结构，比如商品卡片、分类导航、分页栏、订单状态标签。如果按照传统 jQuery 那种写法和思路，每个页面都要复制粘贴大片 HTML，后面想统一改样式就得一个文件一个文件翻。Vue 里把这些封装成独立组件，一处定义，全站复用，维护成本一下降下来了。

这个项目的前端还用了 Element UI 组件库，这个选择很实际。Element UI 专门面向后台管理系统和电商中后台场景，表格、表单、弹窗、消息提示、分页组件都很齐全，前端工程师不需要从零去写复杂的交互。比如后台的商品列表页，直接放一个el-table绑定数据源，再配一个el-pagination做分页，几十行代码就能支撑起一个完整的管理页面。

关于 Vue 版本，这套源码使用的是 Vue 2 和 Element UI 的组合，版本虽然没有 Vue 3 新，但稳定性极好。直到现在仍有大量存量项目跑在这个组合上，对新人和参考者来说，Vue 2 的生态资料更全，遇到问题搜索解决方案相对容易，不容易卡死。

2.3 MySQL 作为数据存储的合理性

选 MySQL 基本不需要犹豫。中小型信息管理系统最怕搞出过度复杂的数据架构，比如上来就引分布式数据库或者 NoSQL，最后发现自己根本没有那么多数据和并发。MySQL 作为关系型数据库，对本项目里这种强关联数据模型是天然匹配的。用户和订单、订单和商品、商品和分类，这些关系用外键或者逻辑关联表达都非常直观，事务支持也能保证下单流程不会出现数据不一致。

数据库版本选型上有一个细节要注意，这套源码默认连接 MySQL 5.7，但你在 MySQL 8.0 环境里跑也完全没问题，只要把 JDBC 驱动改成com.mysql.cj.jdbc.Driver，并在连接串上加时区参数serverTimezone=Asia/Shanghai即可。很多同学第一次启动报错都是因为忽略了 MySQL 8.0 的时区问题。

整个项目的数据库设计保持在合理粒度，没有过度设计。字段命名清晰，类型选择也规范，金额用decimal(10,2)而不是float，状态值用tinyint并配合注释说明，时间字段统一用datetime。这些细节看似不起眼，实际决定了一个项目在后续维护时是否省心。

3. 数据库设计：七张核心表怎么串成完整业务闭环

3.1 核心表关系与设计思路

这套系统的数据库我梳理了一下，核心业务表一共七张：用户表、分类表、商品表、商品图片表、购物车表、订单表、订单明细表。它们之间的关系并不复杂，用户对购物车是一对多，对订单是一对多；分类对商品是一对多；商品对图片是一对多；订单对订单明细是一对多。一句话概括就是：用户是交易主体，分类和商品是交易对象，购物车是下单前的中转站，订单和明细是交易结果。

这样的设计在电商系统里属于最标准的范式。购物车为何单独建表而不是直接把商品挂到用户下？因为购物车有数量字段，用户可能加购多件同一商品，如果只存一个商品 ID 就丢失了数量信息。订单为何一定要拆分成订单表和订单明细表？因为一个订单可以包含多种商品，如果把商品快照直接塞进订单表，一行就会塞很多东西，既难查询又难统计，拆成两张表则天然支持一个订单多商品的结构。

表结构设计的一个好处是订单明细里冗余了商品名称、商品图片、成交价格这些信息。很多人会觉得，既然订单和商品有关联，直接查商品表不就行了吗？但商品价格和名称是可以变的，如果用户在 3 月份下单，商家在 5 月份修改了商品名或价格，订单历史就应该保留成交那一刻的快照。订单明细表承载这部分历史数据，这是一种很关键的业务考虑。

3.2 商品与分类表设计的关键细节

分类表category的核心字段是分类名称、父级 ID 和排序号。有父级 ID 就能支持二级分类结构，比如一级是大家电，二级是空调、冰箱、洗衣机。虽然实际前端展示可能只用一级分类，但有父级字段意味着将来扩展层级结构时无需改表结构。

商品表product是整套系统的核心，字段相对多。主键 ID、分类 ID、商品名称、副标题、主图、详情富文本、价格、原价、库存、销量、状态（上下架）、创建时间。这里有一个容易忽略的设计点，就是库存和销量字段放在同一张表。每次用户下单扣库存时同步增加销量，商品列表页可以直接按销量排序，而不需要再用COUNT去统计订单表，性能会好很多。

商品图片为什么要单独一张表product_image？因为商品图数量不固定，大多数商品放四五张图，但有些家电可能要放七八张。如果只在商品表里放一个主图字段，多图就无法存储。单独的图片表记录每个商品的多张图片 URL，按商品 ID 查询返回列表，展示层就能循环渲染出商品相册。这个设计体现了电商领域常见的主表加子表模式。

3.3 订单与订单明细的关联设计

订单表orders包含了订单编号、用户 ID、总金额、支付金额、支付方式、状态、收货人姓名、电话、地址、下单时间、支付时间、发货时间。订单编号选择了独立生成而不是依赖于自增 ID，这是在实际业务场景下的合理考虑。自增 ID 暴露给用户容易猜测和遍历，且多表关联时不具备业务含义。常见做法是取系统时间戳加上随机数再拼接上用户 ID，生成一个唯一的业务编码。

订单状态字段是典型的整型状态机，一般定义 0 为待付款、1 为已付款、2 为已发货、3 为已收货、4 为已完成，负数表示已取消。前端拿到状态值之后通过映射关系显示对应中文标签。这里想特别提醒的是，不要直接在数据库里存状态中文词，不要用varchar存“待付款”这种字符串。一旦前端文案要改，或者要加一个状态，字符串方案就非常难受，整数枚举配合代码里的常量定义可以随时调整展示。

订单明细表order_item记录了商品 ID、商品名称、商品图片、购买单价、购买数量、小计金额。这里冗余商品名称和图片，是因为订单生成之后商品可能下架甚至被删除，但历史订单仍然需要展示商品信息，单纯关联商品表会让查询落到一个可能不存在的记录上。我在审这套源码时特意看了下单逻辑，确认订单明细插入时确实是从商品表读取信息并快照写入，这属于比较严谨的做法。

3.4 初始化 SQL 脚本中的常见坑点

导入 SQL 之前最好先检查三件事：字符集、存储引擎、时间字段默认值。字符集选择上，建库语句最好使用utf8mb4而不是utf8，因为 utf8 在 MySQL 里最多只支持三个字节，遇到生僻字或 emoji 符号就会出现乱码和存储报错。家电商品描述里完全可能出现品牌方的特殊符号，用 utf8mb4 可以彻底避免这个隐患。

时间字段的处理也很重要，create_time这类字段建表时直接设置默认值CURRENT_TIMESTAMP，插入记录时就不用手动维护时间了。订单表的支付时间、发货时间这类业务时间不能设置默认值，因为它们在订单生命周期里是后续才产生的，需要程序显式写入。

最后还要提醒一下外键和索引的问题。这套源码在设计上刻意没有使用物理外键，而是通过逻辑关联来维护关系，这是很多实际项目的做法。物理外键在删除或更新时会触发数据库层面的约束校验，容易导致操作失败，也让代码里处理数据变得麻烦。逻辑关联配合代码里的业务判断，运行时效率更高，灵活性也更大。但索引一定要建，订单表的用户 ID 字段、商品表的分类 ID 字段是高频查询条件，应该建立普通索引，否则数据量上来后查询会明显变慢。

4. 后端核心链路：SpringBoot 的关键实现细节

4.1 统一返回体与全局异常处理

前后端分离项目里，后端只返回 JSON 数据，前端拿到之后自行渲染。如果每个接口返回的数据格式都不一样，前端就得针对每个接口单独处理返回逻辑，这显然不可维护。这套源码里定义了一个统一的返回体Result，字段包含 code、msg、data 三部分。code 为 200 表示成功，500 表示业务失败，401 表示未登录或登录过期。所有接口统一返回这个结构，前端封装请求层后就能在同一个位置处理弹窗提示和跳转。

代码大概是下面这种结构：

public class Result<T> { private Integer code; private String msg; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMsg("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(String msg) { Result<T> result = new Result<>(); result.setCode(500); result.setMsg(msg); return result; } }

全局异常处理则用@RestControllerAdvice是标配做法。业务代码里抛出异常时，不需要在每一个 Controller 里都写 try-catch，统一异常处理器会捕获异常并转换为Result.error返回。这里有一个实际工作中的小经验：全局异常处理里专门捕获MethodArgumentNotValidException，把参数校验失败的详细消息返回给前端。如果不做这一步，前端拿到的将是一长串异常堆栈，既不好看也不好解析。

4.2 商品分页查询接口的完整链路

商品列表页是前台访问量最大的页面，承载分类筛选、关键词搜索、排序、分页功能。这个接口的 Controller 只做了很薄的一层：

@GetMapping("/api/product/list") public Result<Page<Product>> list( @RequestParam(required = false) Long categoryId, @RequestParam(required = false) String keyword, @RequestParam(defaultValue = "1") Integer pageNum, @RequestParam(defaultValue = "8") Integer pageSize, @RequestParam(defaultValue = "sale") String sort) { return Result.success(productService.pageQuery(categoryId, keyword, pageNum, pageSize, sort)); }

Service 层拿到参数之后，构造 MyBatis-Plus 的查询条件构造器LambdaQueryWrapper，按 categoryId 做等值匹配，关键词对商品名称做LIKE模糊查询，排序字段根据 sort 参数切换，默认按销量倒序，也可以切到价格排序或者新品时间排序。分页通过 MyBatis-Plus 的Page对象完成，它返回总记录数和当前页数据，前端拿到后就能驱动分页组件。

这个接口看似简单，但它是前端首页、列表页、搜索结果页共用的一个接口，后续如果想加价格区间筛选或者品牌筛选，只需要在 Controller 里新增两个可选参数，然后在查询条件里增加判断即可。接口设计的好坏不在于一上来写得多复杂，而在于参数是否灵活、能否覆盖多个页面场景。

4.3 下单事务与库存扣减的实现

订单流程是整个系统业务复杂度最高的地方，也是事务一致性要求最严格的环节。用户点击提交订单后，后端要完成四件事：校验商品是否存在并且处于上架状态、校验购买数量是否超过库存、生成订单主记录、生成订单明细记录、扣减库存并增加销量。这四步任何一步失败都不能让数据库停留在中间状态，所以整个方法必须用@Transactional注解包住。

库存扣减是这里最值得关注的核心逻辑。常见的错误做法是先查一次库存，判断库存是否大于购买数量，然后执行更新。这种做法在并发量稍高的场景下会出问题，两个请求同时查到库存为 10，都通过了判断，然后各自扣减，最终库存可能变成负数，这就是超卖。正确做法是利用数据库的行锁能力，在更新语句里写条件：

int rows = productMapper.deductStock(productId, quantity); if (rows == 0) { throw new RuntimeException("库存不足"); }

对应的 SQL 是：

UPDATE product SET stock = stock - #{quantity}, sales = sales + #{quantity} WHERE id = #{id} AND stock >= #{quantity}

核心思路是让数据库在更新时判断库存是否足够，如果不够，受影响行数为 0，代码再抛出业务异常触发事务回滚。这一行 SQL 解决并发问题，比锁代码块、锁方法都稳妥。下单成功后，需要把购物车里对应的商品项删除，避免用户重复提交同样的订单。这套源码在这一段的实现是完整的，事务边界也划分得比较清楚。

4.4 登录校验与 Token 方案

用户登录之后，后端需要一种方式识别请求身份。这套系统采用 Token 方案，用户登录成功后，后端生成一个唯一的 token 字符，存储到数据库的 token 表里，同时把 userId 也存进去。前端拿到 token 后放入请求头，一般来说约定放在Authorization这个 header 里。后端用一个拦截器统一处理，校验请求头里的 token 是否存在、是否过期。

这种用数据库表存 token 的落地方案在小型系统里非常常见，胜在实现简单、可控性强。不需要额外引入 Redis，也不需要引入复杂的 JWT 依赖。缺点是每次请求都要查一次库，性能上有一定损耗，但对于这种体量的管理系统完全够用。

为了提升拦截效率，拦截器需要排除登录、注册、商品列表、商品详情这些公开接口。如果全部拦截，用户没登录就无法浏览商品了，这不符合普通电商的浏览逻辑。后台管理接口则要额外加一层角色判断，只允许管理员访问。很多这类源码的一个通病是前端隐藏了管理入口，但后端接口没有做角色校验，导致有人直接拼接口路径也能访问后台。我特别查看了一下这套系统的后台拦截配置，确认了管理员校验是放在后端实现的，这一步是加分项。

4.5 配置文件里的跨域与上传路径

前后端分离之后，前端运行在 8080 端口，后端运行在 8081 端口，浏览器默认会拦截跨源请求，所以必须处理跨域。这套源码在 WebConfig 里实现了跨域配置：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

allowedOriginPatterns("*")表示允许任意来源访问，开发阶段这样配置最省事。但上线的时候建议把它改成具体的前端域名，否则容易被恶意站点跨域调用接口。这一点我在读源码时特别标注出来，属于“开发可以、上生产必须收紧”的典型配置。

文件上传路径也是这套源码里容易踩坑的地方。商品图片上传接口需要把图片文件保存到服务器磁盘，代码里配置了一个上传根路径。Windows 环境路径分隔符是反斜杠，Linux 是斜杠，如果代码里写死路径格式，部署到服务器后就会加载不到图片。这套源码用的是相对路径拼接加 File 对象处理，兼容性没问题。图片上传到本地磁盘后，还需要一个静态资源映射，把/upload/**路径映射到磁盘目录，这样前端才能通过 URL 访问到图片文件。

5. 前端 Vue 页面与交互逻辑实现

5.1 页面路由规划与页面框架搭建

前端页面规划得比较规整，路由主要分为用户端和管理端两大块。用户端包括首页、商品列表、商品详情、购物车、订单列表、订单详情、登录注册；管理端包括仪表盘、商品管理、分类管理、订单管理。前端使用 Vue Router 的 history 模式，页面跳转不刷新整个页面，交互体验更接近原生应用。

这里有一个实际经验想分享给大家。开发环境用 history 模式没有任何问题，因为开发服务器会对不存在的路由自动回退到 index.html。但部署上线时，如果 Web 服务器没有配置对应的 URL 重写规则，刷新详情页就会直接 404。为了避免这个问题，很多类似的源码会在部署阶段改成 hash 模式。如果你只是本地运行测试，history 模式保持不动即可；如果将来要部署上线，记得先测试刷新页面是否正常。

导航守卫是前端一个重要的控制点。用户访问购物车、订单这些需要登录的页面时，路由守卫会检查本地是否存在 token，不存在就跳转登录页。后台管理路由也走导航守卫，额外判断本地存储的 role 字段是否为管理员。这个判断只是控制页面入口的展示，后端接口的角色校验才是真正的安全防线。

5.2 axios 封装与请求拦截处理

前端与后端通信统一走 axios，但不会在每个页面重复调用 axios 实例，而是封装成一个模块。这套源码的封装方式很标准，创建 axios 实例后设置基础路径和超时时间，然后在请求拦截器里做统一逻辑：

service.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers['Authorization'] = token; } return config; });

响应拦截器同时做了统一处理：后端返回 code 为 200 时直接返回 data 字段，页面代码里就不需要每次都解包一层；返回 401 时清除本地登录信息并跳转登录页；返回 500 时用 Element UI 的 Message 组件弹出错误提示。这层封装的好处是，页面里写接口调用时，代码会非常清爽，重新定向和报错提示都不用管，统一在拦截器里完成。

在实际联调时我遇到过一个问题，就是登录接口返回的 token 后端用的是data字段传递，而封装后的响应拦截器会把data再解一层，导致页面里取 token 时拿到的是 undefined。排查后确认是响应拦截器和服务端返回结构的问题。这类问题在前后端分离项目里非常容易出现，排查技巧是先看浏览器 Network 面板里原始响应内容，再看 axios 封装层做了哪些处理，逐层核对就很清晰。

5.3 商品列表和详情页的实现要点

商品列表页使用了 Element UI 的栅格布局，一行展示四个商品卡片，每个卡片包含商品主图、名称、价格和销量。卡片标题超出两行时用 CSS 省略号截断，保证界面整齐。这块看起来简单，其实涉及的细节不少，比如价格显示上，设计方案会将原价用删除线展示、现价用醒目颜色突出，并配合“促销”之类的角标。

商品详情页的信息展示则更丰富，上面是商品相册和核心信息，下面是详情富文本。商品相册使用 Element UI 的走马灯组件，通过循环渲染多张图片，支持左右切换。右侧是价格、库存、销量和购买数量控件，底部是“加入购物车”和“立即购买”按钮。加入购物车功能调用购物车接口，传入商品 ID 和数量。这一整套交互在这个源码里都做了完整配置。

这里我建议拿到源码后可以自己手动改一个点：在详情页增加一个参数表格区域，用el-table把商品参数渲染成两列的键值表格。对家电商品来说，参数表是决策的关键信息，默认的商品详情页有富文本区域，但富文本里的参数排版往往不够规整。顺手把参数结构化，会让页面体验提升一个档次。

5.4 购物车结算与订单状态交互

购物车页面通常是一张表格，每一行包含商品图片、名称、单价、数量、小计，行首勾选框用于选中，顶部有全选功能，底部固定显示已选商品的总金额和结算按钮。购物车数量改变时，前端会调用更新接口同步到后端，这里要注意的一个点是数量必须限制在商品库存范围内，前端和后端都要做校验，前端做校验是为了快速反馈，后端做校验才是真正保证数据安全。

结算页面提交订单时，前端把收货人姓名、电话、地址、订单备注、商品项列表、总金额一起传给后端。后端生成订单成功后返回订单号，前端跳转到订单列表页。订单列表页根据状态值渲染不同的标签颜色，比如待付款用橙色、已发货用蓝色、已完成用绿色，并附带相应的操作按钮。

我在实测这套系统时发现一个用户体验上可以优化的点：订单列表页没有筛选功能。实际运营过程中，用户订单多起来以后，没有筛选就要翻很多页才能找到特定状态的订单。优化方案也不复杂，前端在订单列表页加一个状态标签页切换，点击不同状态时请求携带 status 参数即可，后端接口本来就是支持按状态查询的。

6. 项目从零到跑通：完整部署实录与问题排查

6.1 环境版本选择与踩坑记录

要从零把项目跑起来，环境版本一定要选对。经过测试，这套源码最稳的配置是 JDK 1.8、SpringBoot 2.7、MySQL 5.7 或 8.0、Node 14 以上、npm 使用镜像源。JDK 不要一上来就装最新的 JDK 21，因为 SpringBoot 2.x 对高版本 JDK 的兼容性并不完美，特别是 CGLIB 代理这类底层机制，在 JDK 17 以上版本偶尔会报出一些奇怪的反射异常。如果你本地已经装了多个 JDK 版本，用 IDEA 在 Project Structure 里面单独指定 1.8 即可。

前端部分，由于这套源码使用 Vue 2 和 Element UI，Node 版本不建议装太新。Node 17 以上版本在一些老项目中会出现digital envelope routines::unsupported的报错，这是因为新版 OpenSSL 与旧版 Webpack 不兼容。解决办法是降低 Node 版本，或者在 package.json 里调整 script 脚本，在vue-cli-service serve前加上NODE_OPTIONS=--openssl-legacy-provider。我推荐直接用 Node 14，省心很多。

数据库版本选择上，MySQL 5.7 和 8.0 实测都能跑通。区别只在 JDBC 驱动名称和连接串参数。如果用 8.0，application.yml里的驱动类要写成com.mysql.cj.jdbc.Driver，URL 要追加serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=utf8。这个配置如果不写全，启动时大概率会报时区相关的错误。

6.2 数据库初始化与后端启动的具体步骤

先把数据库准备好。用 Navicat 或者命令行工具新建一个数据库，名称建议和源码里配置一致，比如appliance_mall，字符集选utf8mb4。然后执行源码里自带的sale.sql脚本，把建表和初始化数据一次性导入。导入完成之后检查一下各表的数据量，确认商品表和分类表有数据，再进入下一步。

然后修改配置文件。打开application.yml，把数据源地址、用户名、密码改成自己本机的实际配置。很多同学在这里只是改密码，忘记改数据库名称，导致启动时找不到表。核对连接串里的数据库名和脚本建出来的库名一致，这个位置最花时间的小坑。

后端启动比较简单，用 IDEA 打开源码根目录，等待 Maven 依赖下载完毕。这里第一次加载会很慢，如果卡在下载阶段，建议检查 Maven 的镜像仓库设置。下载完成后启动主类，观察控制台日志，看到Started Application就代表后端启动成功。启动后先在浏览器访问一个公开接口，比如商品列表接口，如果能正常返回 JSON 数据，后端就没问题了。

6.3 前端安装依赖与前后端联调

前端启动前需要安装 npm 依赖。在项目前端目录下执行npm install，这个过程受网络环境影响较大，如果依赖下载中途失败，最常见的原因是某个包版本被源仓库临时移除。切换到国内镜像源能大幅提升成功率，执行npm config set registry https://registry.npmmirror.com然后再重新安装即可。

依赖安装完成后执行npm run serve，启动 Vue 开发服务器。启动后访问前端地址，页面能打开，但数据可能加载不出来。这是正常的，因为前端的接口地址可能还在指向某个远程服务器。需要找到前端的请求封装配配置文件，把baseURL改为后端实际地址，一般默认是http://localhost:8081。改完保存，前端就会自动重新编译，刷新页面后数据就能正常显示了。

联调过程中最常见的现象是页面可以打开，但所有列表都是空的，并且浏览器 Console 里有红色报错。这时候先用浏览器 Network 面板看接口请求是否真的发出去了，再看接口返回的状态码是多少。如果是 404，说明后端的接口路径和前端的请求路径不一致，查看后端 Controller 里的完整路径做对比；如果是 401，说明请求头里的 token 没有成功携带，检查前端请求拦截器。

6.4 高频启动报错与解决方案整理

我把测试过程中遇到的高频问题整理成了一张排查表，基本都是新手必踩的坑：

这里有一条经验值得单独提一下。排查后端问题时，不要只看前端报错，先看后端控制台日志。很多新手遇到接口报错，习惯性从前端疯狂调试，浪费大量时间。前后端分离项目里，前端报错信息往往比较笼统，后端的堆栈日志才是第一手信息，直接定位到具体代码行。

我自己在测试这套源码时，还发现了一个关于图片上传的小细节。上传接口保存图片到本地磁盘时，如果不注意目录是否存在，会直接报文件路径不存在的错误。源码里在保存前做了目录创建判断，但如果目录名包含中文或者空格，部分操作系统下也会出现读取异常。稳妥的做法是将上传目录设置为纯英文路径。

还有一个容易忽略的细节是时区问题。后端启动时配置了 MySQL 连接的时区，但服务器系统自身的时区可能不是东八区，导致订单表里插入的时间差 8 个小时。这个问题在本地 Windows 测试时不容易出现，但部署到云服务器上就经常发生。解决办法是在应用主类或者配置文件中设置默认时区为Asia/Shanghai，确保生成时间字段时使用的是东八区时间。

最后再说说我对这套源码的整体评价。它的定位很准确，就是一个结构清晰、可运行、适合学习二次改造的全栈电商管理系统。比起那些动辄引入一堆新技术但实际逻辑混乱的项目，这套代码的功力体现在“克制”二字：技术栈用得扎实，表设计不复杂，接口链路完整，每个模块都能找到对应的学习切入点。你现在要做的不是急着改代码，而是先把项目原封不动跑起来，从前台点一圈、从后台操作一遍，对整体数据流有了体感，再考虑在哪个模块上做你的二次开发。比如给商品加一个参数表，或者给订单加一个导出 Excel 的功能，用这套基础打底，实现起来都不会太难。