基于Spring Boot与MQTT的无人果蔬售卖系统设计与实现

想直接抄一套能答辩、能演示、能写进论文的完整毕设源码，又怕被导师问倒？这篇整理自“鲜果购无人果蔬售卖系统”的完整复盘，从选题逻辑、技术选型、数据库设计，到硬件接入、支付回调、异常补偿，再到答辩现场的高频追问，全部走一遍。代码可以复刻，但设计背后的“为什么”才是你答辩值钱的地方。

1. 为什么说这是个“性价比极高”的毕设选题

1.1 课题本身自带“物联网+电商”双热点

毕设选题最怕的是什么？一是太偏纯理论，代码量撑不起论文；二是太常见，比如“图书管理系统”“学生选课系统”，答辩老师看都不想看。无人果蔬售卖系统恰好卡在了一个很舒服的位置：它表面上是一个电商交易系统，但内核牵扯到物联网设备交互、库存一致性、支付回调、异常订单补偿。也就是说，它既有传统Web系统的CRUD，又有嵌入式、硬件联动这类加分项。

你想想答辩现场的画面：别人演示的是增删改查页面，你演示的是“用户扫码开门→称重感应→自动扣款→库存同步→异常退款”，这个叙事层级完全不同。导师会默认你具备系统集成思维，而不是只会调接口。

1.2 技术栈选型的自由度与容错空间

这类题目不会把你锁死在某个特定框架里。后端可以选Spring Boot，这是目前Java方向毕业设计的主流选择；前端可以用Vue + UniApp，兼顾PC管理后台和移动端H5；硬件端可以用STM32或ESP32配合称重传感器、舵机锁控模块。协议层通过串口或MQTT与后端通信，这意味着你就算某块硬件没调通，也可以用“模拟设备”的方式兜底，不影响整体演示和论文推进。

最关键的是：这是一个“即使硬件全挂，系统依然能跑”的架构。我见过太多人把硬件依赖做得太重，结果设备一抖动，整个答辩Demo直接翻车。后面我会专门讲怎么把硬件层做“软”，这是实战里非常实用的一招。

1.3 课题来源具备“生活化+商业真实性”

“鲜果购”这个名字本身听起来就像一个小型创业项目，读者和评审老师都不会觉得陌生。无人果蔬售卖在大学宿舍楼下、社区门口确实有真实落地的商业场景，这让你的论文在“研究背景”“市场需求”“可行性分析”这些章节有很大发挥空间，不用生编硬造。尤其当你在论文里写“传统果蔬零售损耗率高、人工成本大，无人化售卖结合智能称重与在线支付可有效降低边际成本”时，这不再是空话，而是有现实商业逻辑支撑的。

所以选这个题目，等于开局就把“创新性、实用性、工作量”三个毕业设计核心指标都占了。接下来要做的，就是怎么把它实现得漂亮且不被问倒。

2. 系统整体架构与业务流转：先画清楚再写代码

2.1 三个端+一个设备的角色拆解

很多同学做毕设时上来就建表写接口，结果写到一半发现角色混乱、权限不清、业务链路不成闭环。我的习惯是：不管代码有多简单，先把系统分为物理端和逻辑端。物理端是“用户手机/Pad端”“管理员PC端”“智能货柜设备端”三块；逻辑端则是围绕“商品、订单、设备、用户、库存”五个核心域展开。

在“鲜果购”系统里，大致的角色边界是：

• 用户端：扫码、浏览商品、下单支付、查看订单、申请售后。
• 管理端：商品上下架、库存管理、价格调整、设备状态监控、补货提醒、销售数据统计。
• 设备端：接收开锁指令、采集称重数据、上报货柜状态、控制锁控模块。

把这三个角色的用例图梳理清楚后，你才会发现，原来“购买流程”并不是从下单开始的，而是从“扫码”开始的；也才能理解为什么订单状态不能只有“待支付/已支付/已取消”，必须引入“待取货/已完成/退款中/已退款”这些状态。

2.2 核心业务时序：一次完整的购买行为

无人果蔬售卖最有意思的地方在于，它与普通电商的购买流程完全不同。普通电商是“先下单，后支付，再发货”，而无人售卖往往是“先开门，再取货，后称重，最后自动支付”。这个时序反转是整个系统的设计灵魂，也是论文和答辩中最重要的亮点之一。

我在系统里定义的购买链路是这样的：

1. 用户扫描柜体二维码，发起“开门请求”。
2. 后端校验用户登录态、账户状态、设备在线状态，通过后下发开门指令。
3. 设备端开门，用户取走商品，关门后触发“称重结算”。
4. 设备将重量变化数据上传，后端根据“重量差→商品SKU匹配”计算出价格。
5. 后端生成待支付订单，调用支付接口完成免密扣款。
6. 支付结果通过回调通知更新订单状态，然后同步扣减库存。

这里有一个很重要的设计点：在第4步里，“重量变化与商品SKU的匹配”是整个系统的核心难点。因为你不可能只靠“少了50克”就准确判断用户拿的是苹果还是梨。所以我在设计中加入了“视觉辅助校验”的预留接口，虽然Demo阶段硬件层面没有真正接入摄像头识别，但在数据库和接口层面预留了字段，答辩的时候可以引导导师往这个方向提问。

2.3 硬件交互方案：称重传感器与扫码模块的接入思路

如果你打算把硬件真实跑通，我会建议按以下最小方案来做：

• 主控板：ESP32或STM32F103C8T6，串口或Wi-Fi与后端通信。
• 称重模块：HX711配合压力传感器，量程选5kg-10kg即可，精度能够达到±1g-±5g，足够识别果蔬级别的重量变化。
• 锁控模块：电磁锁或舵机锁，通过继电器或MOS管驱动。
• 显示模块：不需要大屏，一个0.96寸OLED或数码管即可，显示“已开门/请取货/结算中”等状态。

通信协议我推荐用JSON over MQTT，而不是裸TCP。因为MQTT天然支持心跳、离线消息、遗嘱消息，这对设备状态管理特别友好。后端只要订阅 device/{deviceId}/event 主题，就能收到称重、开门、关门等事件；下发指令时，往 device/{deviceId}/command 发布消息即可。

这里的核心经验是：不要在硬件端做太重的业务逻辑。设备端只负责“采集、上报、执行”，所有判断、计算、校验全部放在后端，这样后期维护和Debug都会轻松很多，也方便你在没有实体硬件的情况下，用模拟设备脚本代替设备端跑通整个流程。

3. 数据库设计与核心表结构：别让数据模型拖后腿

3.1 核心表设计：从用户到设备关联

我在“鲜果购”系统里一共设计了8张核心表，但真正决定系统上限的是这5张：用户表、商品表、设备表、订单表、订单明细表。其余的购物车、售后、补货记录、操作日志，都是锦上添花。

设备表在设计上我特别强调“设备与商品”是多对多关系，因为一台货柜可以放多种商品，而同一商品也可能放在多台货柜里。所以我建了一张 device_stock 关联表，字段包括 device_id、sku_id、stock、capacity，分别表示某台设备上某个SKU的实时库存与最大容量。这个设计有两点好处：一是方便补货时按设备维度查看缺货情况；二是为后续“设备间库存调拨”预留扩展空间。

用户表除了常规字段外，我额外加了 open_id、phone、balance、status 四个字段。open_id 用于小程序免密登录，balance 用于余额支付和退款原路返回，status 管理用户拉黑，比如多次“开门不取货”或者支付失败的用户可以限制使用。

3.2 库存扣减策略：为什么我选了“先冻结后实扣”

这类系统的库存设计有个经典问题：用户把商品从货柜里拿走，库存是在“称重回调”时扣，还是在下单支付后扣？

答案很明确：必须在“称重完成且订单生成”时扣减，而且扣减动作必须是“同步+乐观锁”。我的实现方式是在 device_stock 表增加 version 字段，每次扣减都执行类似 UPDATE device_stock SET stock = stock - 1, version = version + 1 WHERE device_id = ? AND sku_id = ? AND stock > 0 AND version = ? 的SQL。这样即使并发拿同一柜子里的最后一颗橘子，也只会有一个请求成功，不会出现超卖。

有同学可能问：那从“开门”到“称重结算”这中间，库存还算不算？

我们在架构上把这部分定义为“预占冻结”，即开门时锁定该设备的全部SKU库存，结算后按实际取走的数量扣减并解冻剩余。这个方案在数据库里要加一张 device_lock_orders 表，记录设备、用户、过期时间。只是我考虑到毕业设计的复杂度，在简化版本中没有加冻结表，而是用“乐观锁+结算时校验库存”兜底。两种方案在答辩时都能说清逻辑，选哪种取决于你想把复杂度展示到什么程度。

3.3 订单状态机的定义与流转

订单状态定义了系统的生命周期，设计得好，后面写业务逻辑会非常顺。我的状态机定义如下：

注意，在无人售卖的场景里，“待支付”状态是极其短暂的，因为称重完成立即触发免密扣款。那为什么还保留待支付？因为如果用户余额不足或者支付通道异常，订单会落在待支付状态，系统会通过消息推送引导用户补款或申诉。这个状态在答辩时能很自然地体现你的系统完整性。

4. 关键功能实现细节：从下单到售后的完整链路

4.1 三段式门控流程与扫码鉴权

扫码开门这件事看起来简单，实际上有三个隐藏细节：

1. 二维码本身不应该携带设备ID明文，而应该携带一个临时票据 ticket。
2. 票据有效期建议设60秒到120秒，过期作废。
3. 同一时刻，同一用户不能对两台设备发起开门请求。

我在实现中采用的方式是：用户扫到 ticket 后，后端先校验票据是否存在、是否过期、是否已被使用，然后检查用户是否在该设备上存在未完成订单（防止有人开门不取货导致订单悬挂），最后才下发开门指令。这么做的目的非常明确：防止恶意攻击，保证“一票一次”。

4.2 称重回调的数据清洗与金额计算

设备端上报称重数据后，后端不能直接拿这个差值去计算金额，因为称重传感器的数值在设备刚关门的一瞬间是不稳定的，可能存在“余震”。我在代码里做了一个数据清洗流程：

1. 设备连续上报3次重量，每次间隔200ms。
2. 后端取3次数据的中间值，去掉最高和最低。
3. 用稳定后的重量与开门前的基准重量做差，得到“取走重量”。

拿到取走重量后，接下来是“SKU匹配”。最朴素的实现是按商品均价划分，但现实中果蔬的重量区间会有重叠。为了提升匹配准确率，我给每个SKU配置了“参考单重范围”，比如红富士苹果单果约150-220克，香蕉单根约100-150克。系统会先找“重量差与单果范围倍率最接近的SKU”，再结合设备上的库存快照，按置信度排序，取Top3生成待确认订单，推送到用户端。

这套匹配算法虽然不算复杂，但已经很能体现“算法思维+工程落地”的结合了，在论文里可以扩写成一个独立章节，属于高性价比的加分项。

4.3 支付回调与幂等处理

支付这块，毕设里最常见的是接入微信支付Native或支付宝当面付。真正需要写代码的功夫在“回调通知”和“订单更新”的幂等性上。

我遇到过一个很典型的Bug：支付平台回调超时重试了两次，结果订单金额被重复入了两次账。后来我加了一个 payment_callback_log 表，以 transaction_id 作为唯一键，每次回调先尝试插入日志，插入成功（影响行数为1）才继续后续业务逻辑，否则直接返回成功响应，让支付平台不再重试。

这是非常关键的实战经验，也是面试和答辩时体现“生产级思维”的高频考点，建议大家在文档里专门写一节。

4.4 异常订单补偿：支付成功但扣货失败怎么办

这是无人售卖系统里最容易出问题的环节。正常流程下“支付成功→订单完成”，但如果支付成功后，库存扣减失败，或者设备状态显示“未关门”，这时候订单就悬挂了。

我设计了三个补偿机制：

• 定时任务兜底：每5分钟扫描一次超过10分钟仍处于“已支付待取货”的订单，调用设备端“关门查询”接口确认货物状态。如果确认未取货，则自动退款。
• 用户手动申诉入口：用户端提交“未收到货”申诉，后端自动调取该订单对应设备在结算时间段的称重记录，辅助人工判断。
• 超时未支付关单：待支付订单超过15分钟自动关闭，并释放预占库存。

这三个补偿机制，极大提升了系统健壮性，同时也是撰写论文“系统测试与异常验证”章节的绝佳素材。

5. 代码实现与工程结构：别写成一坨“可运行但不可维护”的代码

5.1 后端分层架构：Controller-Service-Mapper之外多了一个Event层

大多数毕业设计都会用三层架构，但“鲜果购”这种设备事件驱动的系统，仅靠三层架构会导致Service层严重膨胀。比如，下单、称重、支付回调、退款这些行为本质上都是事件，而它们的处理逻辑高度相似。

我在实际项目里做了一点点变体：在Service层之上增加一个Event层，专门处理设备上报事件和支付回调事件。这样Service层只负责传统CRUD业务，Event层负责监听、分发、调用Service。虽然只是概念上的抽象，但代码可读性好很多，可以应付一些导师“你如何应对后期需求扩展”的问题。

5.2 关键代码示例：称重结算的Service实现

下面这段代码是整个系统中最有含金量的一段，单件匹配与订单生成逻辑的骨架如下：

java复制public Order createOrderFromWeighing(WeighingEvent event) {
    // 1. 获取设备在开门前的基准重量
    DeviceBaseline baseline = deviceBaselineMapper.selectByDeviceId(event.getDeviceId());

    // 2. 使用净重与基准重量计算取走重量
    int takenWeight = baseline.getBaseWeight() - event.getStableWeight();

    // 3. 基于设备库存快照与单品参考重量进行匹配
    List<DeviceSkuDO> skuList = deviceStockMapper.selectSkuListByDevice(event.getDeviceId());
    SkuMatchResult matchResult = skuMatcher.match(takenWeight, skuList);

    // 4. 构建待支付订单并冻结库存
    String orderNo = OrderNoGenerator.generate();
    OrderDO order = OrderDO.builder()
            .orderNo(orderNo)
            .deviceId(event.getDeviceId())
            .userId(event.getUserId())
            .totalAmount(matchResult.getMatchedAmount())
            .status(OrderStatusEnum.PENDING_PAY)
            .build();
    orderMapper.insert(order);

    // 5. 乐观锁扣减库存，失败则触发异常补偿
    int rows = deviceStockMapper.deductStock(event.getDeviceId(),
            matchResult.getMatchedSkuId(), 1, matchResult.getVersion());
    if (rows == 0) {
        throw new BizException("库存扣减失败，请稍后重试");
    }

    // 6. 触发免密扣款
    paymentClient.deduct(orderNo, matchResult.getMatchedAmount());
    return order;
}

这段代码的逻辑本身很直白，但我建议你在写论文时把“第3步的SkuMatcher实现”单独展开，把基于单重范围的置信度得分计算方式写出来，配上几个测试用例，这个工作量在论文评审时很有说服力。

5.3 前端管理后台与移动端的联动设计

前端部分我做了两个独立工程。管理后台使用Vue 3 + Element Plus，负责商品上下架、设备管理、订单查询、补货报表。用户端直接使用UniApp同时编译到H5和微信小程序，毕竟真实场景里用户是扫码后在小程序里完成交互的。

这里我的经验是：管理后台走传统管理界面路线没问题，但用户端页面不要超过8个。毕竟毕设的精力是有限的，核心页面是扫码页、商品列表页、订单详情页、售后申请页，把这4个页面打磨干净，效果远好于堆10个粗糙页面。

6. 部署与演示：从本地跑通到答辩现场不翻车的准备

6.1 本地环境搭建：别在答辩前夜才装环境

我的“鲜果购”项目对应环境建议如下：

这里有个特别值得注意的坑：如果你使用的是自签名HTTPS证书，微信小程序会拒绝访问后端API。建议在生产演示环境中，把后端接口统一配置成HTTP局域网地址或内网穿透方案，否则真机上扫码会直接白屏。别问我是怎么知道的，我答辩前夜调了两小时才发现是证书问题。

6.2 模拟设备脚本：硬件“软著”也能够完整演示

前面提到，硬件不是每个人都有条件集齐。我写了一个 python3 device_simulator.py，作用是以MQTT客户端模拟设备端：

python复制import paho.mqtt.client as mqtt
import json, time, random

client = mqtt.Client()
client.connect("127.0.0.1", 1883, 60)

# 设备上线
client.subscribe("device/dev001/command")

def on_message(client, userdata, msg):
    data = json.loads(msg.payload)
    if data["cmd"] == "open":
        # 模拟开门后取走约200g重量，并上报称重事件
        payload = {
            "event": "weighing",
            "deviceId": "dev001",
            "stableWeight": 1800,   # 假设基准2000g
            "timestamp": int(time.time())
        }
        client.publish("device/dev001/event", json.dumps(payload))

client.on_message = on_message
client.loop_forever()

这个脚本在答辩演示时，完全可以代替实体设备跑通“扫码开门→称重→支付”全流程。只要在介绍时说明“演示环境采用设备模拟脚本模拟货柜行为，生产环境通过MQTT对接实体设备”，答辩老师通常不会苛责，反而会认可你的工程化思维能力。

6.3 答辩演示的节奏设计

答辩演示最怕的是“手忙脚乱地一口气点完所有页面”。我的建议是准备好一个“演示脚本”，按业务链路来走：

1. 先展示设备列表页，点开某台设备的详情，介绍“这台设备上绑定了哪些商品、库存如何”。
2. 打开用户H5页面，模拟扫码开门，切到后端日志页，展示收到开门事件和指令下发日志。
3. 调出模拟设备脚本的终端窗口，展示称重上报消息。
4. 切换到订单列表，展示支付成功的订单记录与库存扣减后的实时变化。
5. 最后打开MySQL，执行一条库存查询SQL，展示扣减结果。

这样演示一遍，时间控制在8分钟左右，逻辑清楚，每个环节都有迹可循。比单纯把页面点一圈有说服力得多。

7. 毕业设计论文的写作与答辩准备

7.1 论文章节编排与工作量呈现

很多同学代码写得很多，但论文写得像流水账，导致答辩效果打折扣。我建议论文结构这么安排：

• 第一章：绪论（研究背景与意义、国内外研究现状、主要工作内容）
• 第二章：相关技术介绍（Spring Boot、MySQL、MQTT、Vue、UniApp等）
• 第三章：系统分析（可行性分析、需求分析、用例图、业务流程分析）
• 第四章：系统设计（总体架构、功能模块设计、数据库设计、接口设计）
• 第五章：系统实现（核心功能截图 + 关键代码片段 + 实现逻辑说明）
• 第六章：系统测试（测试环境、功能测试用例表、性能测试、异常场景测试）
• 第七章：总结与展望

关键在于第三章到第六章，一定要把“设备端与Web端的交互时序”和“称重结算状态机”画清楚。这两张图是整篇技术含量的代表。

7.2 可能被追问的问题与应对话术

答辩环节导师最喜欢从“异常与并发”两个角度追问，我把被问到的高频问题整理成了一张表：

答辩时不需要把每个问题答得非常深，关键是给出逻辑闭环：发现问题、分析原因、给出方案、验证效果。

7.3 需要提前准备的材料清单

除了论文正文、PPT、演示视频这三件套外，我强烈建议你额外准备一份“项目部署说明文档”，内容包括环境要求、数据库初始化脚本、启动步骤、常见部署问题排查。一方面这是部分学校的硬性材料要求，另一方面也能体现你的工程交付能力。如果导师现场要求你演示重启服务或重新跑一遍完整流程，这份文档就是你最可靠的“记忆外挂”。

写在最后：这类“软硬结合”毕设的可扩展方向

我自己的感受是，无人售卖系统这类题目的上限很高，主要体现在后续可扩展的方向实在太多了。你可以把普通货柜升级成多格口货柜，增加温控模块做生鲜冷链监测；也可以引入人脸识别代替扫码开门；还可以在管理端加上基于时间序列的销量预测，辅助自动补货决策。哪怕只是把其中一个方向做成“系统实现的展望”，毕设的整体立意都会不一样。

更重要的是，这套系统从数据库、后端、前端到硬件通信、支付回调，覆盖了一个商业项目基本完整的技术栈，做完它，你对“一个真实系统是怎么跑起来的”会有一个整体认知，这对找工作面试时的项目经验描述也很有帮助。

我建议你拿到源码后，不要急着直接改标题交差，先按照本文的拆解，把核心链路跑通，再试着改一个自己感兴趣的模块，比如换一种库存扣减策略，或者加一个设备分组管理。经过这一轮动手，它才真正从别人的源码，变成你自己的毕业设计。