1. 引言
1.1. 研究背景与行业现状
根据中研普华产业研究院《2024~2029年自动售货机产业现状及未来发展趋势分析报告》，2022年中国自动售货机市场规模达289.08亿元，设备数量增至11.66万台，近六年复合增长率约26.1%。在智能零售与物联网技术的驱动下，自动售货机已从单一的即时消费工具，演变为集“商品售卖、数据采集、用户交互”于一体的智能终端[1]。
从商业系统实践看，头部企业如友宝、猩便利的售货机系统已实现基础的库存监控、销售数据统计功能，但多数系统存在三个典型局限：一是设备终端与管理平台的交互以“定时上报”为主，缺乏实时数据同步，导致补货决策滞后；二是系统架构多为单体应用，前端界面与后端业务逻辑耦合度高，迭代维护成本高；三是用户侧仅支持基础购买流程，缺乏个性化推荐、会员体系等增值服务，用户体验停留在“工具化”层面。
从学术研究维度，智能零售与物联网管理领域的相关成果可分为三类：
1) 技术实现类：聚焦于物联网设备的通信协议(如LoRa、NB-IoT)优化、边缘计算在终端的部署等，如文献[1]设计的智能无人售货柜系统，解决了多设备组网的稳定性问题，但未涉及业务流程的智能化。
2) 运营优化类：基于历史销售数据构建补货模型、选址模型，如文献[2]提出的新零售平台库存算法，但其数据输入依赖人工规整，无法适配售货机终端的实时碎片化数据。
3) 系统架构类：探讨前后端分离、微服务架构在零售系统的应用，如文献[3]基于Vue.js和Spring Boot的开源案例，但未针对售货机场景的“多终端异构、数据实时性要求高”等特性做定制化设计。
综上，现有研究与商业实践存在两大断层：一是学术模型的“理想化假设”与售货机场景“数据实时性、设备异构性”的现实需求脱节；二是商业系统的“功能导向”与智能零售时代“用户体验+运营效率双提升”的目标脱节.
1.2. 研究问题与创新方案
本文针对上述不足，明确核心研究问题，拟提出的创新性解决方案包含三个维度：
1) 架构创新：采用“前后端分离 + 微服务”架构，将终端设备、前端应用、后端服务、数据库分层解耦，实现各模块独立迭代与水平扩展；
2) 数据交互创新：基于MQTT协议构建终端与平台的实时通信通道，结合WebSocket实现前端与后端的即时数据推送，确保库存、订单、设备状态的实时同步；
3) 功能创新：在用户侧集成个性化推荐引擎，在运营侧开发智能补货决策模块，通过“终端数据采集–平台智能分析–决策反向赋能终端”的闭环，同时提升用户体验与运营效率。
2. 系统设计
2.1. 系统架构图
在本系统中按结构主要分成了前端和后端两个模块，分别有不同的功能。在前端模块集中于消费者，消费者进行商品的选择、活动的查看和对想要的商品进行扫码支付；后端模块则可以分成平台管理员和运维/运营人员，运维/运营人员只涉及工单处理内容，其他后端内容由平台管理员处理，如点位管理、设备管理、商品管理等等。售货机系统具体的需求如图1所示。
Figure 1. System hierarchy diagram
图1. 系统层次框图
2.2. 数据库ER图
图2为系统的数据库ER图，核心实体及关系如下：
1) 设备实体(Device)：包含设备ID、类型、位置、状态、所属区域等属性。
2) 商品实体(Product)：包含商品ID、名称、规格、价格、库存等属性。
3) 用户实体(User)：包含用户ID、昵称、手机号、会员等级等属性。
4) 订单实体(Order)：包含订单ID、用户ID、商品ID、金额、状态、时间等属性。
5) 区域实体(Area)：包含区域ID、名称、负责人等属性。
6) 关系：设备与商品为“多对多”(一台设备可售多种商品，一种商品可在多台设备售卖)；用户与订单为“一对多”；设备与区域为“多对一”。
2.3. 关键业务UML序列图
图3是自动售货机系统的UML序列图，分为“消费者购买流程”和“运维人员设备故障处理流程”两个核心场景，以下是详细解释：
Figure 2. ER diagram
图2. ER图
2.3.1. 消费者购买流程
展示用户从“发起购买”到“售货机出货”的全链路交互：
1) 消费者→前端页面：消费者在自动售货机的前端界面(或移动端)选择商品，发起购买请求。
2) 前端页面→后端API：前端向后端API发送请求，查询商品数据(如价格、库存)。
3) 后端API→数据库：后端API查询数据库，获取商品的详细信息。
4) 数据库→后端API：数据库返回商品数据给后端API。
5) 后端API→后端API：后端处理支付逻辑，调用支付服务完成收款。
6) 后端API→售货机终端：支付成功后，后端API向售货机终端发送“出货指令”。
7) 售货机终端→后端API：售货机执行出货操作后，向后端API反馈“出货结果”，并更新自身库存数据。
2.3.2. 运维人员设备故障处理流程(下半部分)
1) 售货机终端→后端API：售货机终端检测到设备故障(如货道卡滞、温控异常)，向后端API发送“故障信号”。
2) 后端API→后端API：后端将故障信息存入数据库，进行持久化记录。
3) 设备→运维人员端：系统将故障信号推送至运维人员的管理端(如APP、网页)。
4) 运维人员端→后端API：运维人员通过管理端查询故障详情，前往设备现场维修。
5) 运维人员→后端API：维修完成后，运维人员在管理端操作“确认恢复”，后端API接收该指令。
6) 后端API→数据库：后端将设备“已恢复”的状态更新至数据库，完成故障闭环。
Figure 3. UML sequence diagram
图3. UML序列图
2.4. API设计与安全机制
2.4.1. API设计原则
1) URL命名：使用名词复数表示资源集合，如/api/devices (设备列表)、/api/products/{id} (单个商品详情)。
2) HTTP方法语义：GET用于查询，POST用于创建，PUT用于全量更新，PATCH用于部分更新，DELETE用于删除。
3) 响应格式：统一返回{“code”：状态码，“data”：响应数据，“message”：提示信息}结构，便于前端统一解析。
2.4.2. 安全机制
1) 认证机制：采用JWT (JSON Web Token)实现用户与服务间的认证。用户登录后，服务端生成包含用户信息、权限、过期时间的JWT令牌，后续请求需在HTTP头中携带该令牌，服务端验证令牌有效性后提供服务。
2) 授权机制：基于RBAC (基于角色的访问控制)，在JWT令牌中嵌入用户角色(如普通用户、运维人员、管理员)，后端服务根据角色判断是否允许访问特定API。
3) 接口防护：实现接口限流(基于Redis的令牌桶算法)、参数校验(通过Spring Validation框架)、SQL注入防护(MyBatis参数化查询)等机制，保障接口安全性。
3. 开发技术
3.1. Spring Boot技术栈
Spring Boot作为Spring框架的衍生开发方案，显著降低了新应用初始化构建及后续研发流程的复杂度。借助预设配置方案消除项目设置障碍，该框架帮助开发者缩减学习曲线，将重心聚焦于核心业务实现而非底层架构搭建。框架内集成多项即装即用模块(如嵌入式服务器、安全机制、指标监控体系及运行状态检测)，促使单体应用的构建操作趋向便捷化。在微服务架构实施层面，Spring Boot展现出强大的支撑能力与适应弹性，已然成为当代Java开发领域不可替代的基础组件[3]-[5]。
3.2. MyBatis持久层框架
MyBatis是一款主流的关于持久层的技术框架，其通过灵活的SQL映射和自动化ORM机制，能够明显地提升项目的开发效率和代码的可维护性。相较于传统的对象关系映射(ORM)框架，MyBatis展现出更高的灵活性，因为它赋予了开发者直接编写并完全掌控SQL语句的能力，尤其擅长应对复杂多变的查询需求。当与Spring Boot集成应用时，MyBatis进一步提升了数据库访问的效率，显著简化了数据访问层的开发流程。
3.3. Vue 3前端框架
Vue.js框架是现在前端开发最流行的框架的已经更新到了Vue 3，因为Vue.js具有模块化的架构和组合式API的设计能够明显地提高代码的可维护性并且方便了开发人员进行灵活的组合。既可以作为网页中的一个微小组件存在，也能够支撑起整个单页应用程序(SPA)的构建[3]。Vue 3的Composition API的通过逻辑复用和代码组织的能力，为开发者提供了灵活、高效的开发方式，使他们能够更灵活地组织和复用代码逻辑。借助Vue 3及其庞大的生态系统，开发者能够以前所未有的高效方式，打造出既现代又高性能的Web应用界面。
4. 系统管理
4.1. 后台首页
管理员登录售货机系统进入的首页后可以查看关于工单统计、销售统计、销售数据、销售额分布。等相关信息，具体内容如图4和图5所示。
4.2. 点位管理
在系统后台可以进入点位管理的页面，在点位管理的页面中提供了对点位信息的增删改查功能，包含顶部搜索区(可按名称和区域筛选)、操作按钮区(新增、修改、删除、导出)、数据表格(展示点位名称、区域、商圈类型等详细信息)以及分页控制区，具体情况如图6所示。
Figure 4. Upper half of the backend homepage
图4. 后台首页上半部分
Figure 5. Lower half of the vending machine’s backend homepage
图5. 售货机后台首页下半部分
Figure 6. Site management page
图6. 点位管理页面
4.3. 合作商管理
在系统后台可以进入合作商管理的页面，在合作商管理的页面中提供了对合作商信息的增删改查功能，包含顶部搜索区(按合作商名称搜索)、操作按钮区(新增、修改、删除、导出)、数据表格(展示合作商名称、点位数、商圈类型等详细信息)，具体情况如图7所示。
Figure 7. Partner management page
图7. 合作商管理页面
4.4. 区域管理
在系统后台可以进入区域管理的页面，在区域管理的页面中有对区域信息的增删改查功能、在顶部的搜索区提供了按照区域名称来搜索、操作区的按钮则是查看详情、修改、删除、数据表格(展示区域名称、点位数、备注说明等详细信息)以及分页控制区，具体情况如图8所示。
Figure 8. Region management page
图8. 区域管理页面
4.5. 设备管理
在系统后台可以进入设备管理的页面，在设备管理的页面中有对设备信息的增删改查功能，重点是设备管理页面的操作包括(货道设置、策略设置和修改相关信息)，具体情况如图9所示。
Figure 9. Device management page
图9. 设备管理页面
4.6. 商品管理
在系统后台可以进入商品管理的页面，提供商品管理的相关功能，重点是对商品管理页面的操作(修改和删除)，具体情况如图10所示。
Figure 10. Product management page
图10. 商品管理页面
4.7. 订单管理
在售货机系统的后台可以点击订单管理界面，提供查看售货机的订单，包含顶部搜索区(可按订单编号、创建的时间范围)、操作按钮区(查看详情)以及分页控制区，具体如图11所示。
Figure 11. Order management page
图11. 订单管理页面
4.8. 前端商品管理
售货机系统的前端商品页面展示了售货机系统中拥有的商品图片和价格，具体如图12。
5. 结论与展望
本系统通过“前后端分离 + 微服务”的架构设计，实现了终端设备、后端服务、前端应用的解耦，解决了传统售货机系统迭代难、扩展性差的问题；通过MQTT与WebSocket的组合，构建了实时数据交互通道，使库存管理、订单处理的时效性提升至秒级；通过集成个性化推荐、智能补货等功能，同时满足了用户体验升级与运营效率优化的双重需求。
Figure 12. Front-end product management page
图12. 前端商品管理页面
未来可进一步探索AI算法在需求预测、设备故障预警中的应用，以及区块链技术在商品溯源、支付对账中的落地，持续推动自动售货机系统向“智能化、生态化”演进。
基金项目
本文系2025年江西省大学生创新创业训练计划项目：饮领鲜机——自动售货机系统(项目编号：S202510895048X)的研究成果。