SpringBoot+Vue+MySQL实战：构建可应对并发的水果电商系统

在动手做这个系统之前，我其实挺纠结的。市面上电商系统教程一抓一大把，随便搜都是"XX商城"，但大部分都停留在玩具级别——写几个 CRUD 接口、套个前端模板就算完事。真正做一套能卖给果农合作社、能在芒果成熟季扛住并发下单的系统，完全是另一码事。

攀枝花这个地方的水果很有意思，芒果、石榴、枇杷、樱桃都是地域名片，但销售模式一直比较原始。很多果园还是靠微信接单、Excel 记账，遇到预售季集中爆单的时候，人工处理订单根本忙不过来。我这次接到的需求，就是给一家做产地直销的果品合作社搭建一套在线销售系统，最终技术路线定为 Java + SpringBoot + Vue + MySQL 这套经典组合。整篇文章我会按照一个完整项目的推进顺序来写，从需求分析、技术选型、数据库设计，到前后端核心实现、部署上线和踩坑复盘，全程记录真实决策过程，希望能给正在做类似毕设或小型电商项目的朋友提供一些可以照抄的实操参考。

1. 先想清楚业务逻辑：水果电商和普通电商差在哪

1.1 生鲜非标品带来的三个核心难题

做系统之前，我先跟果农和运营聊了一圈，发现水果销售和卖标准工业品完全不一样。普通商品SKU明确、库存稳定、发货流程固定，水果则处处都是"非标"。

第一个难题是规格描述复杂。一箱芒果可能按"5斤装""10斤装"区分，也可以按"特大果""中果""小果"分级，加上不同品种、不同产地批次，一个"芒果"的背后其实是多层规格参数。数据库表如果按单一商品表去设计，后面改价格、改库存会非常痛苦。

第二个难题是库存和批次强绑定。水果不像手机，同一型号可以无差别补货，水果每一批的成熟度不同，实际可售数量是跟着采果计划走的。也就是说系统里的"库存表"不能只存一个总量，还要能追溯到具体批次。

第三个难题是订单状态流转更复杂。从用户下单到收到货，要经过待付款、已付款、待采摘、已发货、运输中、已签收这些环节，中间还有退款、理赔等异常分支。订单表的状态机设计含糊的话，后端接口会越写越乱。

1.2 从业务场景推导出技术需求清单

和用户确认完业务流程后，我把需求整理成明确的模块清单：

• 用户端：注册登录、商品浏览与分类筛选、加入购物车、下单支付、订单跟踪、个人中心、收货地址管理。
• 管理端：商品分类管理、商品与规格维护、库存批次管理、订单处理（发货/退款）、销售数据看板。
• 基础能力：图片上传、统一鉴权、接口幂等、异常处理。

由此得出的技术需求也很明确：前端要支持两个独立界面（用户端+管理后台），后端要提供 RESTful API，数据库要支撑订单和库存的高并发一致性。这个阶段不引入分布式事务、消息队列，因为业务规模和团队维护能力都达不到，单体架构加本地事务已经够用。

2. 技术选型的思考过程：为什么是 SpringBoot + Vue + MySQL

2.1 后端选型的取舍

对于这类中小型业务系统，SpringBoot 几乎是最稳妥的选择。它的生态成熟度极高，Spring Security、MyBatis-Plus、Redis、MinIO 这些组件都有现成集成方案，出问题随便一搜就有答案。

我这次用的是 SpringBoot 3.2 + Java 17，持久层 MyBatis-Plus，数据库 MySQL 8.0。为什么不用 MyBatis 原生？因为项目里大量简单 CRUD，手写 SQL 效率太低，MyBatis-Plus 的 LambdaQueryWrapper 能省掉大概 30% 的样板代码。复杂报表统计的 SQL 仍然手写，放在自定义 Mapper 里，两种方式混合使用效率最高。

JWT 做登录态管理，令牌无状态、支持跨域，前端部署在 Nginx、API 在后端服务，二者分离得比较干净。实际开发中 JWT 也比 Session 更适合前后端分离架构，因为不需要额外维护 Session 同步。

2.2 前端选型的取舍

前端用 Vue 3 + Vite + Element Plus + Pinia。选择 Vue 的核心理由是组件生态丰富、中文文档友好、上手曲线平滑。淘宝、美团这类电商场景对页面交互要求不算极端复杂，Vue 的响应式数据绑定和组件复用机制完全能覆盖需求，没必要上 React。

Element Plus 负责后台管理界面非常合适，表格、表单、弹窗、日期选择器都是现成的组件。用户端商城页面我需要更高自由度，所以是自定义组件 + 少量 Element Plus 穿插使用。状态管理用 Pinia 替代 Vuex，语法更简洁，TypeScript 支持也更自然。

UI 上用户端做一个偏温暖、水果风格的设计，主色调可以用芒果黄搭配绿色，整体页面要给人新鲜、自然的感觉。这一块虽然不直接影响功能，但作为电商系统对用户信任感的建立非常重要。

2.3 项目整体结构规划

项目采用前后端分离仓库，后端是一个标准 Maven 单模块项目，目录如下：

fruit-sale-server/ ├── src/main/java/com/example/fruitsale/ │ ├── controller/ # 接口层，只做参数接收和结果返回 │ ├── service/ # 业务逻辑层，事务边界在这里 │ ├── mapper/ # MyBatis-Plus 数据访问层 │ ├── entity/ # 数据库实体 │ ├── vo/ # 视图对象，接口返回数据结构 │ ├── dto/ # 数据传输对象，接收前端入参 │ ├── config/ # 配置类：跨域、拦截器、文件上传等 │ ├── common/ # 统一返回结果、异常处理、常量类 │ └── utils/ # 工具类：JWT、日期等 └── src/main/resources/ ├── application.yml # 公共配置 ├── application-dev.yml # 开发环境配置 ├── application-prod.yml # 生产环境配置 └── mapper/ # 自定义 SQL XML

前端分成两个入口，用户端和管理后台，通过路由区分，构建时统一打包成单页应用。用户端路由有首页、商品列表、商品详情、购物车、订单确认、个人中心等，管理端路由有数据看板、商品管理、订单管理等。

3. 数据库设计：把商品、库存、订单整合进 MySQL

数据库设计是整个系统里最重要的一步，后面所有接口逻辑顺畅不顺畅，百分之八十取决于建表设计合理不合理。这个项目我一共设计了 11 张核心表，重点讲一下设计思路。

3.1 商品与库存的表结构设计

商品信息拆成两张主表和一张关联表。产品表product存储商品公共信息，规格表product_specification存储具体规格，一张产品对应多个规格。

CREATE TABLE `product` ( `id` bigint NOT NULL AUTO_INCREMENT, `category_id` bigint NOT NULL COMMENT '分类ID', `name` varchar(100) NOT NULL COMMENT '商品名称', `main_image` varchar(255) DEFAULT NULL COMMENT '主图地址', `description` text COMMENT '商品详情描述', `status` tinyint NOT NULL DEFAULT '1' COMMENT '1上架 0下架', `sort` int DEFAULT '0' COMMENT '排序权重', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里有个细节务必注意：name、description这些字段要设置成utf8mb4字符集，不要用utf8。因为 MySQL 的utf8实际上不支持完整的四字节字符，用户或者运营在描述里塞几个 emoji 表情，接口就会报Incorrect string value错误，非常坑。

规格表里商品价格保留两位小数，这是电商系统遇到的最经典问题之一：金额必须用DECIMAL类型，严禁使用DOUBLE或FLOAT。浮点数在二进制里无法精确表示，后台计算订单总价会出现类似 19.39 + 5.99 算出来 25.370000000000002 这种诡异结果。

库存字段stock加了一个version字段，这是为乐观锁准备的。芒果成熟季预售活动开始的时候，很多人同时下单抢购，version字段能帮我实现并发安全扣库存。这个场景在电商里属于超卖问题的重灾区，后面下单流程会详细说。

3.2 订单相关的四张表

订单拆成order主表和order_item明细表，这是标准的电商做法。为什么必须拆？因为一个订单可能包含多件商品，比如用户同时买了一箱芒果和一箱石榴，订单主表存用户信息和总金额，明细表一行存一种商品。如果不拆表，要么字段冗余，要么统计商品销量的时候极其困难。

用户地址单独拆一张address表，没有直接存在订单表。因为用户可能多个地址，下单时候选择收货地址，订单只需要冗余一份地址快照。注意是"快照"——用户的地址信息将来可能修改，历史订单必须保留下单时的地址原文，这个细节很容易被忽略。

支付记录用payment_record表记录，它和订单表是 1 对 1 关系。为什么要有这张表？因为实际生产环境对账需要，即使你是模拟支付，也要把支付流水记录下来，将来接微信支付、支付宝的时候才能对接第三方的回调数据和账单明细。

订单状态字段我用的是status整型，枚举值如下：

状态流转在代码里不应该被随意修改，我写了一个订单状态机，每个状态只允许特定的下一个状态，防止接口被人直接改数据库。

3.3 统计报表与购物车

销售数据看板需要按天维度统计订单量、销售额、热销商品。可以直接在查询的时候用GROUP BY实时聚合，数据量不大的时候完全没压力。不过如果将来订单量大，我更建议建一张每日销售汇总表，用定时任务在每天凌晨汇总前一天数据，查询报表会快一个量级。

购物车表设计成cart_item，关联用户 ID 和商品规格 ID。不过后来我发现一个问题，前端购物车如果依赖后端表，用户每次加购都要发一次请求，改数量、勾选、计算金额响应不及时。所以这个项目里购物车主要状态存在前端 localStorage，后端购物车表只是用于登录态同步。这样切换设备跨端的时候数据不会丢，平时操作又极其流畅。

4. 后端核心模块实现：从用户登录到订单完成

后端是整套系统的发动机，核心模块包括认证授权、商品服务、购物车、订单交易。这块涉及的并发和事务问题最多，我把踩过坑的细节逐一展开。

4.1 JWT 认证机制与拦截器设计

认证能力我用 JWT 做了无状态登录。用户提交用户名密码，后端校验成功后生成一个 token 返回，前端把 token 存进 localStorage，每次请求在Authorization头里带着。后端通过拦截器统一解析 token，把用户信息放进ThreadLocal里，Controller 层直接取用。

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录、注册、商品查询等公开接口 if (request.getRequestURI().startsWith("/api/auth")) { return true; } String token = request.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { throw new BusinessException(401, "未登录或登录已过期"); } // 解析 token 拿到用户 ID，放入 ThreadLocal Long userId = JwtUtil.parseToken(token.substring(7)); UserContext.set(userId); return true; } }

实际开发中有个细节值得提醒：拦截器要放行哪些路径一定要梳理清楚。用户浏览商品、搜索、查看详情是允许匿名访问的，下单、支付、查看订单才需要登录。如果一刀切全部要求登录，用户访问首页都跳到登录页，体验会非常差。放行规则我用一个白名单数组集中管理，新增公开接口只改一处。

密码存储用 BCrypt 加密，千万不能用 MD5。MD5 现在跑字典非常快，用户密码很容易被反查出来。Spring Security 自带的BCryptPasswordEncoder就能直接使用，每个用户密码哈希加盐，即使两个用户密码相同，加密后的字符串也不一样。

4.2 商品查询接口的实用设计

商品列表接口除了基础的 CRUD，我增加了三个维度的筛选能力：分类、价格区间、关键词搜索，排序支持综合排序和价格排序。分页用 MyBatis-Plus 的Page对象实现，注意返回给前端的数据结构里，除了当前页数据，还必须包含总记录数，前端分页组件才渲染得对。

商品详情页返回的数据是综合的，除了商品基础信息、规格列表、库存量，还需要返回当前登录用户是否在购物车加过这件商品。因此商品详情接口内部做了三次数据库查询后组装，这就是VO（视图对象）发挥作用的地方：

public class ProductDetailVO { private ProductVO product; // 商品信息 private List<SpecVO> specs; // 规格列表 private Boolean inCart; // 是否已加入购物车 private Integer cartCount; // 购物车中的数量 }

4.3 下单流程：事务、乐观锁和防重提交

下单是整个系统里最容易出问题的环节，也是面试中经常被问到的高频考点。一个标准的用户下单动作涉及 5 步：

1. 校验商品规格是否存在、是否上架。
2. 校验库存是否充足。
3. 锁定库存。
4. 创建订单主表和明细表。
5. 清理购物车对应商品。

第 3 步锁定库存要特别小心。假设两个用户同时购买同一商品，如果先 SELECT 库存，发现还有货，然后 UPDATE 扣库存，在高并发下就可能出现"超卖"——两个人看到库存都是 5，同时买 5 箱，实际只剩 5 箱，数据库却生成了 10 箱订单。

解决办法是用乐观锁更新：

@Transactional(rollbackFor = Exception.class) public Long createOrder(OrderCreateDTO dto, Long userId) { // 1. 校验商品 ProductSpecification spec = specMapper.selectById(dto.getSpecId()); if (spec == null || spec.getStatus() != 1) { throw new BusinessException("商品不存在或已下架"); } // 2. 乐观锁扣减库存，带 version 条件 int rows = specMapper.deductStock(dto.getSpecId(), dto.getQuantity(), spec.getVersion()); if (rows == 0) { throw new BusinessException("库存不足或商品信息已变化"); } // 3. 创建订单主表 // 4. 创建订单明细表 // 5. 清空购物车中对应商品 }

对应的 Mapper SQL 是：

UPDATE product_specification SET stock = stock - #{quantity}, version = version + 1 WHERE id = #{specId} AND version = #{version} AND stock >= #{quantity}

当UPDATE影响行数为 0 时，说明库存不够或者有并发修改发生，服务端抛出异常，事务回滚，订单也不会落库。前面加@Transactional(rollbackFor = Exception.class)，保证业务中间任何一步抛错，前面的扣库存、建单都会回滚，不会留下脏数据。

下单接口还需要考虑幂等。用户手抖点了两次提交按钮，如果不做控制会产生重复订单。解决方式是在前端提交后把按钮置灰，后端再配合一个"防重令牌"机制：进入订单确认页时后端返回一个orderToken，下单时必须携带这个 token，订单表添加唯一索引，重复提交只有一个成功。

还有一种常见处理方案是检查 Redis 里的用户下单锁，但当前项目没有引入 Redis，所以用订单号加唯一索引的方式处理。

4.4 模拟支付回调与订单状态流转

真实电商系统里支付这块要接微信支付、支付宝，但本地开发可以直接做模拟支付。我在测试环境实现了一套"支付受理"逻辑：用户点击支付，前端请求后端pay接口，后端生成支付流水记录（状态为待支付），然后前端跳转到模拟收银台，点击"模拟支付成功"，后端再次调用payCallback接口把订单状态改为已付款。

@Transactional(rollbackFor = Exception.class) public void payCallback(String orderNo, BigDecimal amount) { Order order = orderMapper.selectByOrderNo(orderNo); if (order.getStatus() != OrderStatus.PENDING_PAYMENT) { throw new BusinessException("订单状态不正确"); } order.setStatus(OrderStatus.PAID); order.setPayTime(LocalDateTime.now()); orderMapper.updateById(order); // 记录支付流水 }

这个模拟支付的好处是后续接真实支付渠道的时候，前端只需替换支付页面的跳转逻辑，后端把模拟成功的位置换成第三方异步回调/notify接口，业务逻辑完全不用动。

订单状态机是整个下单流程的灵魂。用户点击取消订单只能在"待付款"状态执行，管理员发货只能在"已付款"状态执行，用户确认收货只能在"已发货"状态执行。我在每次状态变更前检查当前状态，不满足条件直接抛异常。这一层保护虽然让代码多几行，但真的能避免很多生产事故。

5. 前端 Vue 实战：用户端与后台管理页面的落地

5.1 路由与权限控制

前端用户端与管理后台拆分表现为两套路由，所有管理端路径带有/admin前缀。路由守卫是前端权限控制的关键：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.meta.requiresAuth && !token) { next({ path: '/login', query: { redirect: to.fullPath } }) return } if (to.path.startsWith('/admin')) { // 管理员角色校验，不通过跳回首页 } next() })

用户登录成功后存的 token 同时包含角色信息（普通用户或管理员），前端根据角色判断是否能进入后台页面。这只是前端层面的路由保护，后端接口也要有对应的权限校验，不能只靠前端隐藏按钮来保证安全。

5.2 商品展示与购物车状态管理

用户端首页由顶部轮播图、分类导航和商品卡片列表组成。商品卡片点击加入购物车时，交互逻辑是这样的：

function addToCart(spec) { if (spec.stock <= 0) { ElMessage.warning('该规格暂时缺货') return } cartStore.addItem({ specId: spec.id, name: spec.name, price: spec.price, quantity: 1 }) ElMessage.success('已加入购物车') }

购物车状态用 Pinia 管理，数据结构是Map<specId, { specId, name, price, quantity, checked }>，操作购物车加减、勾选、全选、删除都是本地即时响应，只有提交订单时同步到后端。

购物车页顶部会实时计算出"已选商品件数和总金额"，实现上是用 Vue 的computed对 checked 为 true 的条目做累加。这里有一个小技巧：价格计算用Math.round(price * 100) / 100处理浮点数精度问题，避免前端展示出 88.30000000000001 这种数字，影响用户信任感。

5.3 订单确认页与支付页的交互细节

从购物车点击"去结算"后，跳转到订单确认页。页面分三个区域：收货地址选择、商品清单、金额汇总。地址选择做成弹窗列表，用户点击某个地址后，高亮显示并记住选中项。如果没有地址，引导用户先去新增。

订单金额计算公式：

订单总金额 = 商品金额小计 - 优惠金额 + 运费

我的项目初期没有做复杂的满减和优惠券系统，所以运费规则很简单：满 99 包邮，不满加收 8 元。这个规则集中放在后端OrderAmountService里计算，前端只负责展示。

提交订单后跳转支付页，用户点击"模拟支付"按钮，支付成功后页面上会显示成功状态，并自动跳转到订单列表页。这里前端需要注意：支付回调结果也要在后端验证订单状态，前端不能只凭pay接口返回成功就认为支付完成。

5.4 管理后台的核心页面

管理后台使用 Element Plus 搭建，页面相对简单但功能实用。

商品管理页面用一个表格展示所有商品，支持分页、关键词搜索、上下架状态切换。编辑商品采用抽屉式弹窗（Drawer），左侧是表单，点击保存调用更新接口。商品的多规格编辑要用一个嵌套表格，每行一个规格，动态增删一行，提交时批量更新。

订单管理页面是最复杂的。表格展示订单列表，默认展示待发货订单。每一行有一个"查看详情"按钮，弹窗展示订单完整信息（收货地址、商品明细、金额组成）。管理员点击"发货"，弹出输入框填写快递公司和单号，提交后调用后端接口更新订单状态。这个功能在生产环境要对接快递查询接口，顺丰、中通这些都有开放 API，但需要申请，开发阶段先用文字记录。

数据看板页面展示三项核心指标：今日订单数、今日销售额、待处理订单数。下面再放一个热销商品 Top10 表格，按销量统计排序。图表推荐用 ECharts，折线图展示近 7 天销售趋势。接口从后端拿统计数据，前端只需传入正确的格式。

6. 部署上线的完整过程与踩坑复盘

本地跑通项目只是第一步，真正上线部署才是考验的开始。项目部署环境我采用最简单的单机方案：MySQL + 后端 Jar 包 + 前端静态文件 + Nginx。

6.1 环境配置分离与打包部署

开发环境与生产环境一定要分离配置。SpringBoot 使用application-{profile}.yml文件区分，application.yml里只放公共配置：

spring: profiles: active: ${SPRING_PROFILES_ACTIVE:dev}

生产环境单独配置数据库连接、文件上传路径、日志级别等信息。部署时通过启动参数指定 prod profile。

后端构建产物是一个可执行 jar 包，我用 Maven 打包后在服务器上直接用该文件启动。为了统一管理进程，我写了 systemd service 文件：

[Unit] Description=Fruit Sale Server After=syslog.target network.target [Service] Type=simple User=admin ExecStart=/usr/bin/java -jar /home/admin/app/fruit-sale-server.jar --spring.profiles.active=prod SuccessExitStatus=143 Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

6.2 Nginx 配置前后端联动

Nginx 在这里扮演两个角色：一是托管前端打包产物（dist 目录），二是反向代理后端 API。配置思路如下：

server { listen 80; server_name your-domain.com; # 前端页面 root /home/admin/www/fruit-sale-web/dist; index index.html; # 前端路由为 history 模式，必须加这条 location / { try_files $uri $uri/ /index.html; } # 后端 API 反向代理 location /api/ { proxy_pass http://127.0.0.1:8080; 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;这一行必须写。Vue 路由用 history 模式时，前端地址刷新后如果 Nginx 没有这行配置，会返回 404。加了这个配置后，任意深度的前端路由都回退到 index.html，由前端路由接管解析。

第二，后端接口都在/api/前缀下，Nginx 把这一部分代理给后端服务，proxy_pass末尾的斜杠处理要注意。如果后端 Controller 的 RequestMapping 本来就是/api/...，那么proxy_pass http://127.0.0.1:8080;保持原样就行。

第三，图片上传后通过 URL 访问，Nginx 需要映射上传目录：

location /uploads/ { alias /home/admin/app/uploads/; }

6.3 我在这个项目里踩过的四个高频坑

坑一：时区问题

线上部署后，订单时间比真实时间早 8 个小时。原因是 MySQL 连接串里没有指定时区，默认使用服务器时区，而服务器时区又是 UTC。解决方案是在 JDBC 连接串中显式指定：

jdbc:mysql://localhost:3306/fruit_sale?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

Linux 服务器本身也可以统一时区，执行timedatectl set-timezone Asia/Shanghai就能解决。

坑二：跨域问题

本地开发时前端跑在 5173 端口，后端跑在 8080 端口，直接请求会触发跨域拦截。我用两种方式解决：开发环境用 Vite 的 proxy 配置把/api代理到后端，生产环境由 Nginx 代理，所以不必完全依赖后端 CORS。但为了保险起见，后端还是加了一个全局 CORS 配置类，允许指定来源跨域。

坑三：图片上传之后的访问地址失效

开发时我把图片直接存放在本地磁盘的临时目录，结果上传后刷新页面图片就 404。原因是临时目录被系统定期清理，而且路径是绝对路径，换到服务器后找不到。正确做法是配置一个独立的上传目录，SpringBoot 通过静态资源映射把/uploads/**映射到该目录：

@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/uploads/**") .addResourceHandler("file:" + uploadPath + "/"); }

坑四：并发扣库存实战验证

代码写完后我用 JMeter 模拟 200 个并发用户同时抢购同一芒果规格，库存设置为 50，最终跑完订单数量 50 个，库存归零，没有超卖也没有负库存。这个测试建议每个电商项目上线前都跑一遍。如果发现依然超卖，可以先排查 UPDATE 语句的stock >= #{quantity}条件是否写全，再看是不是用了SELECT ... FOR UPDATE但事务没生效。

7. 系统上线后的收尾体会与扩展建议

项目上线运行一个多月后，我复盘了整个过程。很多人在做这类系统时，容易把精力全花在页面好不好看上，而真正考验系统能力的问题几乎都在后半程：数据一致性能不能保证、接口能不能扛住集中流量、出现异常订单能不能快速定位原因。这些是靠扎实的数据库设计、清晰的事务边界和完整的日志记录支撑起来的。我做接口联调时发现，日志里加上"方法入参、核心判断分支、关键数据变化"这三个层面的输出，排查问题效率翻倍。

关于未来扩展，我的建议是走"小步快跑"的路线：可以先接上真实的微信支付和物流查询，把支付体验和物流跟踪补全；然后增加促销模块，例如满减和优惠券；再往后可以做库存预警，芒果成熟季之前根据历史销量预测需要采摘的量。这些扩展的共同基础是当前的表设计保留的字段充分，比如订单表里有冗余的规格名称快照、支付流水表和订单表分离，这样新增需求时基本不需要动老的表结构。

文章写到这，这套基于 Java + SpringBoot + Vue + MySQL 的攀枝花水果在线销售系统的核心内容都梳理完了。最后留一句个人的心得体会：做全栈项目不要追求一步到位，先把主流程跑通，再逐步加固细节，这个系统从能够下单到能够稳定扛住成熟季流量，中间迭代了整整三周。希望我的记录能帮你少走一些弯路。