企业官网建设流程全解析

1. 这个项目为什么值得做：精品水果电商的“非典型”需求

先说结论：如果你正在找一套能直接拿去二次开发的电商系统，又恰好对 SpringBoot + Vue 这套主流技术栈比较熟，那精品水果线上销售管理系统是一个很值得花时间研究的样本。它不只是简单的“增删改查”，而是把生鲜电商特有的一些业务难题浓缩进了一个完整项目里。

市面上开源的商城系统不少，但大多数偏向标品零售——比如服装、数码产品，订单履约链路相对简单。水果这个品类很特殊：第一，时效性极强，从下单到配送经常以小时计算；第二，损耗率敏感，库存、批次、临期管理都要精算；第三，规格复杂，同一款水果可能有“5斤装”“8斤装”“礼盒装”之别，价格和库存完全不同。这些细节让水果电商系统的设计思路和通用商城拉开了明显差距。

这个项目采用前后端分离架构，后端是 SpringBoot + MyBatis + MySQL，前端是 Vue。它解决的问题可以概括为三点：

• 让运营人员能快速上架、改价、配置促销活动，不必依赖开发人员；
• 让顾客在小程序/H5/网页端有顺畅的浏览、下单、支付体验；
• 让管理员能实时掌握订单、库存、会员数据，支撑日常经营决策。

从学习角度看，这套系统的价值在于它覆盖了电商业务的主链路：用户端商品展示 → 购物车 → 下单 → 库存扣减 → 订单流转 → 售后处理，同时也有后台管理的完整闭环。无论你是准备找工作拿项目经验、接私活做外包，还是想给自己或者朋友的实体水果店搭一套线上销售渠道，这套源码都有很高的复现价值。

我建议你在动手看代码之前，先花一天时间把下面这篇文章读透，我会从技术选型到数据库设计，从核心接口到部署上线，把这套系统的设计思路和实现细节一次性讲清楚。

2. 技术选型背后的权衡：SpringBoot + MyBatis + MySQL + Vue 到底强在哪

2.1 后端框架：为什么不用 Spring Cloud，而选单体重型 SpringBoot

很多初学者一上来就问“为什么不做微服务”，这个问题在水果电商场景下其实不太成立。一个区域性的水果电商平台，初期并发量可能一天就几千单，用单体重型架构完全够用。SpringBoot 的优势在于上手门槛低、生态成熟、部署简单，一个 fat jar 直接跑起来，不需要引入注册中心、配置中心、网关那一套东西。

但“单体”不意味着“单块”。这个项目的代码分层做得很规范：Controller 只负责参数接收和响应封装，Service 层写业务逻辑，Mapper 层通过 MyBatis 与数据库交互，实体类和 VO/DTO 严格分离。这种分层带来的直接好处是可以单独对 Service 层做单元测试，也可以随时把某个模块（比如订单模块）拆分出去演进成独立服务。

2.2 持久层：MyBatis 这把“双刃剑”

MyBatis 在这类项目中几乎是标配，因为它让开发者对 SQL 有完全的控制权。举个例子，后台订单列表需要按“订单状态 + 用户手机号 + 下单时间范围”三个条件动态筛选，用 MyBatis 的动态 SQL 很容易拼接；但如果用 Spring Data JPA，这种多条件动态查询通常会写成 Specification 或 QueryDSL，不够直观。

这里要提醒一句：MyBatis 的灵活是建立在你自己能写好 SQL的前提上的。我见过不少项目因为 Mapper XML 里写了性能极差的关联查询，导致列表接口响应时间到了好几秒。实践中有个原则：能用单表查询解决的，不要用 JOIN；能用索引覆盖的，不要回表。这套水果系统的订单查询就遵循了这个原则，订单主表、订单明细表、商品表分开查，然后在 Service 层组装，实测响应时间稳定在 200ms 以内。

2.3 数据库设计：MySQL 8.0 + InnoDB + utf8mb4

数据库选型没什么悬念：MySQL 8.0，InnoDB 引擎，字符集 utf8mb4。utf8mb4 必须强调一下，因为水果商品名里经常出现生僻字，比如“𦙍果”，如果用了 utf8 字符集，这些字符会直接变成问号，数据写入后就再也查不回来了。

商品表、SKU 表、订单表这些核心表都用的是 InnoDB，因为 InnoDB 支持行级锁 + 事务，这是库存扣减正确性的基础。MyISAM 虽然有“查询快”的说法，但它不支持事务，并发下单时会出现严重的超卖问题。

2.4 前端技术栈：Vue 2 还是 Vue 3？这里有个务实的选择

很多刚接触这个项目的人会问：为什么不用最新版？答案很现实——稳定、生态兼容、参考资料多。Vue 2 配合 Element UI 的这套组合太成熟了，无论是管理后台的表格、表单、弹窗，还是用户端的列表、购物车组件，都有大量现成的组件和范例代码可以直接抄。对于拿源码二次开发的人而言，少踩坑就是最高效的路径。

必要性说明一下：如果你自己新起一个项目，完全可以上 Vue 3 + Vite + Element Plus；但如果是在这套源码基础上做适配，贸然升级前端框架会牵扯到大量组件重写，成本和风险都比较高，不如先让业务跑起来再逐步优化。

3. 数据库设计核心拆解：从商品表到订单表的“精打细算”

3.1 商品与 SKU 分离设计：同一颗苹果也要有多个“身份”

水果电商和图书、数码产品最大的差异在于同一个商品有多种售卖规格。以“烟台红富士苹果”为例，后台可以配置三条 SKU 记录：

数据库设计上，product表存商品公共信息（标题、主图、详情描述、是否上架、排序权重），sku表存每个规格的独立信息（规格名、价格、库存、SKU 编码）。这种分离的好处是显而易见的：查询商品列表时只查product表，不需要关心它有几个 SKU；进入商品详情页时再查sku表，加载所有规格供用户选择。

这里有一个设计细节很多人忽略：SKU 编码的生成规则一定要稳定且唯一。在这个项目里，SKU 编码采用“类别前缀 + 日期 + 随机数”的规则，比如AP-20240115-0023，这样既方便人工识别品类，又不会出现重复。

3.2 库存字段类型：别再用 INT 了，踩过坑的都懂

库存字段建议用DECIMAL(10,2)，而不是INT。为什么？水果的库存单位是“斤”，但运营人员在实际操作中经常需要按“半斤”“1.5斤”来调整库存。如果用 INT，就会出现“库存显示 100 斤，但实际还剩 99.5 斤”的尴尬情况。

更关键的场景是按重量购买的水果。用户选“3.5斤香蕉”，库存记录的是剩余可售重量，如果库存只有 INT 类型，系统只能存“4斤”或者“3斤”，要么导致超卖，要么导致库存不准确。用 DECIMAL 类型配合乐观锁版本号（version 字段），就不会出现这类问题。

3.3 订单表设计：状态机思维比字段堆砌更重要

订单表orders是这个系统里最核心的表，字段不算很多，但每个字段都有讲究：

订单状态我用的是 TINYINT 而不是字符串枚举。原因很简单：字符串状态可读性好，但存储空间大，遍历和索引效率也不如整数。实际开发中用整数 + 状态机统一管理，前后端约定好对应关系（0-5），香得很。

还有一个容易忽略的字段是address_snapshot。为什么要把收货地址冗余到订单表里？因为用户的收货地址是可能变更的——今天下单填的是公司地址，明天用户可能就改成家庭地址。如果订单表只存地址 ID，后续查询历史订单就要关联地址表，一旦地址被修改，历史订单的物流信息就错乱了。所以下单那一刻必须把地址快照保存到订单表。

3.4 购物车表：轻量设计 + 有效期策略

购物车不需要搞得很复杂，核心三个字段就够：user_id、sku_id、quantity，再加一个更新时间字段用于清理过期数据。很多初学者会把购物车设计成复杂的树形结构（分组、收藏、凑单），初期真没必要。

水果购物车有个特殊之处：水果保质期短，购物车里的商品可能过几天就下架了。因此系统在做购物车列表展示时，会实时校验 SKU 的上下架状态和库存量，如果 SKU 已失效，前端会置灰显示，并提示“该商品已失效，请移除后重新下单”。

3.5 促销活动表：秒杀、满减、优惠券，三张表搞定

水果是高频促销品类，动不动就是“今日秒杀”“第二件半价”“新人满 99 减 30”。这套系统的促销设计用了三张表：

• promotion：活动主体表，记录活动名称、类型（秒杀/满减/拼团）、开始时间、结束时间、状态；
• promotion_item：参与活动的商品列表，关联 SKU，记录活动价或参与折扣；
• coupon：优惠券表，记录面额、使用门槛、有效期、发放数量、已领取数量。

设计上的关键点是：优惠计算放在后端，不信任前端传参。下单接口接收的是“优惠券 ID + 商品 SKU 列表”，服务端根据当前用户的领取记录、优惠券门槛、时间有效性统一计算最终优惠金额。这样做能防止一个最简单但是极具破坏力的攻击：篡改支付金额。

4. 后端核心接口实现：登录、商品、下单和库存扣减的完整链路

4.1 用户认证与登录态管理：JWT 的实战用法

用户模块虽然理性层是“注册/登录/个人信息”，但实际实现中有几个决策值得单独梳理。

密码存储用的是 BCrypt 加密算法，不推荐用 MD5/SHA。BCrypt 是自带盐值的哈希算法，相同密码每次生成的哈希值都不同，这能有效抵御彩虹表攻击。用户注册时只把 BCrypt 哈希结果存到数据库，登录验证时用BCryptPasswordEncoder.matches(rawPassword, encodedPassword)做校验。

登录成功后，服务端签发 JWT（JSON Web Token），有效期设置为 7 天。前端每次请求在 Header 里带Authorization: Bearer <token>，后端通过拦截器统一校验和解析用户身份。注意一个细节：JWT 里只放用户 ID 和过期时间，不放心敏感信息。用户的手机号、收货地址等信息要从数据库实时查询，别一股脑塞进 Token，否则 Token 泄露的代价会非常大。

提示：JWT 有个天然的缺陷是“无法主动失效”。用户修改密码后，旧 Token 仍然有效，直到过期。这个问题在水果商城里影响不大，因为系统对持久的敏感操作（如退款）会额外做身份校验，不单单依赖 Token。

4.2 商品列表与详情接口：千万注意“下架商品”的过滤

商品列表接口（GET/api/product/list）是用户端压力最大的接口之一，必须做到只返回上架状态的商品，并且按排序权重倒序、上架时间倒序排列。以下几个点很容易踩坑：

• 下架商品的过滤不能放在前端做。如果 List 接口返回了下架商品，前端再过滤，不仅浪费带宽，还容易在拼团活动、秒杀活动中露出已下架的 SKU 让用户点击后报错；
• 分页参数要加上限。pageSize必须限制最大值（比如 100），防止恶意调用者一次拉全量数据打爆接口；
• 列表接口不要返回富文本详情。详情字段是商品描述的 HTML 内容，可能几十 KB，放列表接口里纯属浪费流量，应放进单商品详情接口（GET/api/product/detail/{productId}）。

商品详情的查询逻辑建议优先走 Redis 缓存，缓存 Key 设计成product:detail:{productId}，缓存时间 5 分钟。为什么是 5 分钟而不是 1 小时？因为运营修改商品价格后，用户端如果还看到旧价格，容易产生客诉。缓存时间太长容易产生数据不一致，太短又起不到缓存效果，5 分钟在这个场景下是“性价比最高”的配置。

4.3 下单接口：事务、锁和幂等三重奏

下单是整个后端最复杂的接口，没有之一，因为它至少要完成以下五步：

1. 校验用户登录态（拦截器已经做了）；
2. 校验下单 SKU 是否存在、是否上架、库存是否充足；
3. 计算订单金额（单价 × 数量 - 优惠金额）；
4. 生成订单号、插入订单表和订单明细表；
5. 扣减库存，同时处理优惠券核销、购物车清除。

这两步必须在同一个数据库事务里完成（@Transactional），否则就会出现“订单生成了但库存没扣掉”或“库存扣了但订单创建失败”这种极端不一致问题。

库存扣减的 SQL 写法也很讲究：

UPDATE sku SET stock = stock - #{quantity}, version = version + 1 WHERE sku_id = #{skuId} AND stock >= #{quantity}

这一步使用了乐观锁机制：先判断库存是否充足，充足则扣减，不充足则更新行数为 0。stock >= #{quantity}这个条件本质上就是数据库层面的超卖保护，无论前端的并发请求有多少，数据库层面都会保证同一时刻只有一条更新能成功。

关于幂等性，我花了很久才真正理解它的价值。用户下单时如果网络波动导致前端重试，可能会提交两次相同的下单请求，结果生成了两个订单——这是很糟糕的体验。解法很经典：前端在点击“提交订单”按钮时生成一个 UUID 作为业务幂等号，后端在 Redis 里用SETNX命令做一次性占位。如果 Redis 里已经有相同 key，说明请求重复提交了，直接返回“请勿重复点击”，不进入下单流程。

4.4 订单状态流转：谁能从哪个状态到哪个状态，必须写清楚

订单状态机是后端设计中容易被打补丁打成一团乱麻的地方。这个项目的设计可以在源码的OrderStateMachine类里看到比较清晰的实现。核心规则是：

• 待支付 → 已支付：只有用户完成支付回调才会触发；
• 待支付 → 已取消：只有用户主动取消或超时 30 分钟自动取消；
• 已支付 → 已发货：只有管理员后台操作；
• 已发货 → 已完成：用户点击“确认收货”或系统在发货 7 天后自动确认；
• 已完成 → 售后中：用户发起退款/退货申请。

这里最容易被忽略的是状态变更的可追溯性。每次状态变更都要往order_status_log表里插入一条记录，包含订单号、旧状态、新状态、操作人（用户/管理员/系统）、操作时间。后续售后纠纷时，有这张日志表才有据可查。

5. 前端 Vue 实现细节：从用户端到管理后台的交互设计

5.1 用户端：几个耐人寻味的交互细节

用户端的核心页面包括：首页、分类页、商品列表页、商品详情页、购物车页、确认订单页、订单列表页、订单详情页、个人中心页。Vue Router 全部采用按需路由懒加载，这样首屏加载体积会明显减小。

商品详情页有两个设计细节非常值得借鉴：

SKU 选择的联动处理。前端获取到商品详情后，会拿到 SKU 列表和每个 SKU 的库存量。当用户选择“5斤装”时，界面实时显示该 SKU 的库存和价格；当某个 SKU 库存为 0 时，对应按钮置灰不可点击——这背后就是 Vue 里“计算属性 + 响应式数据”的常规应用，但不亲自实现一遍，很难体会“库存联动+选择默认 SKU”的逻辑需要多仔细。

购物车数量的防抖处理。用户快速点击加减号时，如果每次点击都立即请求后端更新购物车，前后端交互压力会成倍增加。这个项目的处理方式是：先在本地更新数量，用setTimeout做 500ms 防抖，用户停止操作后再统一提交更新请求。实测购物车交互明显顺滑。

5.2 管理后台：技术含量藏在表格和表单的细节里

管理后台用的是 Vue + Element UI，核心功能包括商品管理、SKU 管理、订单管理、用户管理、促销管理、数据统计。

商品管理表单是这个后台里最复杂的组件。因为一个商品必须同时支持“填写基础信息 + 维护多个 SKU + 上传商品图片”，需要用到动态表单（v-for 渲染多个 SKU 子表单）。每次新增或编辑商品后，把提交的数据结构设计成：

{ "productName": "烟台红富士苹果", "categoryId": 12, "mainImage": "https://xxx.com/static/apple_main.jpg", "detailHtml": "<p>商品详情描述</p>", "skuList": [ { "specName": "5斤家庭装", "price": 39.9, "originalPrice": 59.9, "stock": 500 }, { "specName": "8斤实惠装", "price": 59.9, "originalPrice": 89.9, "stock": 300 } ] }

这个数据结构的优点是一口气提交完整商品信息，后端用事务保证“商品主表 + 多 SKU 明细”的一致性，不会出现“商品建好了但 SKU 少了两条”的问题。

订单管理页的查询条件比较复杂，有订单号模糊搜索、用户手机号精确匹配、订单状态下拉、下单时间区间选择。查询表单建议做成折叠式——默认只露出订单号和订单状态两个高频条件，其他高级筛选放在“展开”里，让页面保持简洁。

5.3 前端请求封装：统一 loading 与错误处理

axios 封装是整个前端的“地基工程”，代码量不大，但影响每个接口的调用体验。这个项目的 axios 拦截器处理了以下三件关键的事：

• 请求拦截器：自动从 localStorage 取 token，加到 Header；
• 响应拦截器：HTTP 200 时只提取data字段；HTTP 401 时清空 token 并跳转登录页；
• 业务错误码处理：后端接口返回{ code: 1, message: "库存不足" }这种结构，前端统一弹 Message 提示，不用每个业务方法里写重复的错误分支。

开发时我建议在 axios 拦截器里加一个 console.debug 输出请求方法、URL、耗时，排接口超时的性能问题时非常好用。

6. 部署上线之路：从本地到服务器的完整落地过程

6.1 本地环境搭建：照着做半小时内跑起来

如果从 GitHub 拉下源码想先跑起来，按下面顺序操作，半小时基本能完成：

1. 安装 JDK 8+（推荐 8 或 11），配置 JAVA_HOME 环境变量；
2. 安装 Maven 3.6+，修改settings.xml里的镜像源为阿里云仓库；
3. 安装 MySQL 5.7/8.0，执行init_data.sql初始化数据库；
4. 打开application.yml，修改数据库连接的用户名和密码，Redis 配置也核对一遍；
5. 启动后端：在项目根目录执行mvn spring-boot:run，看到“Started Application in xx seconds”说明启动成功；
6. 启动前端：进入frontend/目录，执行npm install，然后npm run dev；
7. 浏览器访问http://localhost:8081，用脚本里预设的管理员账号登录。

这个过程中最容易出现的三个问题，都是“每个项目都有的通病”：

• npm install卡在某个依赖：把 npm registry 切到淘宝源https://registry.npmmirror.com，再rm -rf node_modules && npm install重新装；
• 后端启动后接口报 401：检查application.yml里 JWT 密钥是否和前端 axios 里配置的一致；
• 图片上传后访问 404：静态资源路径（file.upload-path）没配置成绝对路径，改成服务器上的实际路径即可。

6.2 服务器部署：jar + nginx + systemd 的标准姿势

生产环境部署的推荐方案是：后端 jar 包运行在 systemd 托管下，前端编译后的 dist 目录由 nginx 托管，nginx 再反向代理/api请求到后端进程。

后端打可执行 jar 包：

mvn clean package -DskipTests java -jar fruit-shop-system.jar --spring.profiles.active=prod

注意生产环境的配置应该单独建一个application-prod.yml，数据库、Redis 的地址都指向云服务器实例，日志级别调整为INFO（开发环境可以是DEBUG），同时把 MySQL 连接串加上characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai。

nginx 的关键配置长这样：

server { listen 80; server_name your-domain.com; root /opt/fruit-shop/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

try_files $uri $uri/ /index.html这行是 SPA 应用必须的配置，否则用户在页面内刷新某个子路由（比如/order/detail/1001）会出现 404。

6.3 上线前必须自查的清单

基于实战经验，上线前我通常会过一遍下面这份清单，能规避掉大部分线上事故：

7. 常见业务问题排查实录：库存扣了订单没生成、订单状态卡住、图片上传 500

7.1 问题一：库存扣了，但订单没生成

这是刚接手订单接口时最容易遇到的“灵异事件”。现象是：用户付款成功，但查询订单列表时找不到这笔订单，后台库存却已经减少了。

排查过程是这样的：

1. 先看后端日志，确认用户下单请求有没有打进来；
2. 如果没有日志，确认网关/nginx 是否把请求转发到了正确后端；
3. 如果有日志且下单逻辑执行到了库存扣减，再看事务有没有正常提交。

最后发现根因是下单方法里抛了异常，但库存扣减的 SQL 在事务提交边界外执行了。比如把库存更新放在@Transactional方法里，但调用的是另一个类的self.invoke()方法，导致事务失效。修复方式很简单：把库存扣减和订单插入放到同一个事务方法里，且通过 Spring 代理调用（注入自身对象的代理引用），绝不能直接在内部用this。

7.2 问题二：订单卡在“已支付”状态，一直没变成“已发货”

如果支付回调成功，订单状态应自动变成“已支付”，但管理员在后台看到的状态一直没变，通常是支付回调接口没有正确处理“重复回调”导致的。微信支付的回调至少会通知三次，如果第一次回调处理时抛了异常，通知服务会再次推送，如果接口没有做幂等处理，就会反复报错，状态也迟迟不更新。

解法很简单：支付回调接口先用回调单号查一下是否已处理过，已处理过的直接返回成功，不再重复执行业务逻辑。

7.3 问题三：图片上传 500，UnsupportedOperationException

后台商品管理里上传商品图片时，报UnsupportedOperationException，日志显示FileOutputStream写入失败。排查发现是后端配置的file.upload-path写成了相对路径upload/，而生产环境 jar 包是从/opt/service/启动的，工作目录不同，相对路径解析不一致，导致写入失败。

修复方案是：file.upload-path配置成绝对路径/data/fruit-shop/upload/，并提前用mkdir -p建好目录；大型文件上传（比如高清详情图）还需要修改 nginx 的client_max_body_size，默认 1MB 根本不够用。

8. 性能与优化：这套系统还能再快几倍的进阶思路

8.1 数据库索引优化：从慢查询日志里找痛点

水果商城虽然业务量不算大，但扛不住某一天运营搞了个“满 99 送 10 元券”的活动，瞬间流量上涨。此时数据库的索引设计就显得格外重要。

最常用的几条索引值得检查：

ALTER TABLE orders ADD INDEX idx_user_status (user_id, status); ALTER TABLE orders ADD INDEX idx_create_time (create_time); ALTER TABLE sku ADD INDEX idx_product_id (product_id);

idx_user_status是组合索引，覆盖“用户查看自己的订单列表”这个高频查询场景。注意组合索引有“最左前缀原则”，查询条件里只有user_id或者user_id + status都能命中索引，但只查status时这条索引完全不生效。

8.2 Redis 缓存：从商品热点到全页缓存

在高峰期，商品详情页是使用频率最高的接口。除了在 Redis 缓存商品详情，还可以对首页的楼层数据（分类导航、推荐位、热卖榜单）做 10 分钟级别的缓存，因为这些数据不需要实时更新到秒级，10 分钟以内更新是完全可接受的。

实现方式比较轻：首页接口先去 Redis 取homepage:data:v1，没有则查数据库组装后放入 Redis。运营后台修改首页推荐位后，手动调用一次DELETE删除缓存 Key，实现“脏数据”的即时失效。

8.3 静态资源 CDN：图片分流才能扛住并发

水果商城的商品图片质量普遍较高，详情页大图动辄几百 KB。如果图片全部走业务服务器，在促销活动期间带宽压力会非常大。更优的方案是把图片放到对象存储（比如云服务商提供的 Bucket），并绑定 CDN 加速域名，图片加载路径直接指向 CDN 地址，业务服务器只承担 JSON 数据的传输。

很多新手会忽略一个细节：商品上下架时不要轻易更换图片 URL。客户端 CDN 缓存的资源是有 TTL 的，如果运营替换了商品主图但 URL 没变，CDN 里还是旧图，用户端看到的就是“改了又没改”的诡异效果。处理办法是图片上传时保存的 URL 带上版本号（/product/apple_20240115.jpg?v=20240115），运营改图时自然刷新 CDN。

9. 二次开发的几条实战建议：别在源码上乱堆功能

9.1 先从“复制表结构”开始，别动老表

不管是在这套源码基础上接单，还是给自己店铺做定制，第一条铁律是：不要轻易修改已有核心表的字段结构。订单表、SKU 表、用户表一旦改动，关联代码可能大面积报错，而且历史数据迁移的成本很高。新增字段时尽量做到“加一张扩展表 + 通过外键关联”，降低回归风险。

9.2 尽量用“配置化”实现促销玩法

水果行业的促销玩得特别花：限时秒杀、买一送一、第 2 件半价、新人专享价、会员日折扣、满减券、无门槛券……如果每种活动都硬编码一套新接口，后台代码会迅速膨胀。较优雅的解法是：在promotion表里增加rule_json字段，用 JSON 描述活动规则，后端用策略模式统一处理不同活动类型的优惠计算。这样新增一个活动类型时，只需要加一个策略实现类，不动已有接口。

9.3 做好数据备份和可回滚策略

无论你是在本地学习还是正式商用，每天定时备份数据库都是必须的。最简单有效的方式是 Crontab + mysqldump：

0 2 * * * mysqldump -u root -p'xxx' fruit_shop > /data/backup/fruit_shop_$(date +\%Y\%m\%d).sql

注意备份文件保留期建议至少 7 天，防止某个版本变更后发现问题想回退数据，结果发现备份早就被覆盖了。

10. 写在最后：从“能跑”到“好用”的成长路径

我一直相信一个观点：看十套源码，不如把一套源码彻底吃透。这个 SpringBoot + Vue 的水果商城系统，不夸张地说，覆盖了企业级 Web 应用开发里 80% 的核心知识点：分层架构、数据库设计、事务控制、缓存使用、状态机、鉴权、文件上传、Nginx 部署、系统优化。如果你能独立把这个系统的每个模块从前端到后端完整梳理一遍，再动手改几个真实需求，你的全栈能力一定会上一个台阶。

实际操作中我的建议是：先按运行文档把项目跑起来，然后带着下面这些问题去读源码：

• 购物车加入相同 SKU 时，后端做的是“数量增加”还是“新增一条记录”？
• 下单时优惠券的抵扣比例是怎么算的？和满减活动能叠加吗？
• Redis 的 Key 是怎么命名和隔离的？如果换了 Redis 集群环境还能正常用吗？
• 前端在做金额展示时做了哪些精度处理？直接展示浮点会发生什么问题？

回答完这几个问题，你对这个项目的理解就会从“哦，代码能跑”变成“我清楚它每一步是怎么跑的”。

这套系统唯一需要提醒的一点：它设计上偏“商用最小可行版本”，更复杂的财务对账、多仓库库存同步、冷链物流跟踪这些能力目前是没有的。如果你未来想把业务做大，方向应该是往“拆订单模块为独立服务”和“引入消息队列异步处理支付结果”这两个方向演进——当然，这些是后话，先把手头的系统吃透才是正经事。