企业官网建设流程全解析

随着无人自助业态的快速发展，DIY手工领域的无人自助拼豆场景也逐渐普及，用户无需店员陪同，扫码即可自助取用拼豆材料、使用工位完成创作，全程自主操作，大幅降低门店运营成本的同时提升用户体验。本文将从需求梳理、技术选型、核心功能开发、测试部署全流程，详细讲解无人自助拼豆系统的全栈开发实战，所有技术方案均经过多个无人共享业态项目验证，可直接落地。

一、需求梳理与核心业务模型设计

无人自助拼豆系统的核心参与方分为普通用户、平台管理员、物联网设备三类，需求梳理需覆盖三方的全场景使用诉求：

核心需求梳理

• 用户端需求：支持LBS定位查看附近门店，提供一键导航功能；/一键授权登录，无需手动注册；扫描设备即可解锁拼豆工位柜，系统自动计时；实时查看当前门店所有拼豆材料的品类、剩余库存，按需取用；创作完成后可选择是否存储作品，结算后自动锁柜；支持历史订单查询、作品存储状态查询。
• 管理端需求：支持多门店统一管理，可配置门店位置、营业时间等基础信息；设备全生命周期管理，实时查看所有拼豆柜的在线状态、占用情况、锁状态；物料库存自动同步，拼豆剩余量低于阈值时自动触发预警；多维度订单统计，支持按门店、时间维度统计用户活跃度、使用时长等核心指标；全操作日志审计，所有用户开锁、管理员操作、设备上报事件均留痕可查。
• 物联网端需求：设备每30秒定时上报状态，包含在线状态、锁状态、各品类拼豆剩余重量、柜内温湿度；可接收服务端指令执行开锁、锁柜、灯光控制等操作；异常状态主动上报，比如柜门未关、物料耗尽、设备断电等场景。

核心业务模型设计

系统核心实体包括7类，可直接基于该模型设计数据库表结构：用户表（存储用户基础信息、授权信息）、门店表（存储门店位置、营业时间）、设备表（存储设备SN、所属门店、当前状态、配置参数）、物料表（存储拼豆品类、单位参数）、订单表（存储用户id、设备id、开始/结束时间、使用时长、订单状态）、存储表（存储用户作品的存放位置、存储时长）、操作日志表（存储所有操作的触发方、时间、内容、结果）。

二、技术栈选型与分层架构设计

参考多个成熟无人共享系统的落地经验，本次开发采用前后端分离架构，技术选型兼顾开发效率、扩展性、跨平台适配能力：

技术栈选型

• 后端服务：采用Spring Boot + MyBatis Plus + MySQL 8.0 + Redis构建，Spring Boot生态完善开发效率高，MyBatis Plus大幅降低CRUD重复代码量，Redis用于存储用户会话、设备实时状态、接口限流数据，提升系统响应速度。
• 用户端：采用UniApp基于Vue语法开发，一套代码可同时适配小程序、H5、Android/iOS APP，满足不同用户的使用习惯，无需多端重复开发。
• 管理后台：采用Vue 2.x + Element UI构建，组件丰富，后台页面开发效率高，适配PC端管理场景。
• 物联网接入层：采用EMQX作为MQTT Broker，支持百万级设备并发接入，低延迟完成设备与服务端的消息交互，适配拼豆柜的硬件通信需求。

分层架构设计

整体架构分为5层，各层职责清晰，支持横向扩展：

1. 接入层：包含Nginx反向代理、EMQX MQTT接入网关，分别承接前端HTTP请求和设备端MQTT请求，支持负载均衡配置。
2. 前端层：包含UniApp用户端、Vue管理后台，负责与用户、管理员的交互逻辑。
3. 业务服务层：包含用户服务、订单服务、设备服务、门店服务、统计服务，所有业务逻辑均在该层实现，后续可根据业务规模拆分为微服务架构。
4. 数据访问层：包含MyBatis Plus数据库操作、Redis缓存操作、MQTT消息发送封装，屏蔽底层数据交互细节。
5. 基础设施层：包含MySQL数据库、Redis缓存、EMQX消息中间件、对象存储（存储用户作品照片），为上层服务提供基础支撑。

三、核心功能模块开发实战

这里重点讲解三个核心模块的开发要点，给出可复用的代码示例：

1. 用户扫码开锁流程实现

扫码开锁是用户端的核心流程，整体逻辑为：用户扫描设备->前端传递设备id到后端->后端校验设备状态->生成初始订单->下发开锁指令->更新设备状态->返回结果给前端。核心接口代码示例如下：

@RestController@RequestMapping("/api/user/order")publicclassUserOrderController{@ResourceprivateDeviceServicedeviceService;@ResourceprivateOrderServiceorderService;@ResourceprivateMqttCommandServicemqttCommandService;@PostMapping("/openDevice")publicR<OrderVO>openDevice(@RequestBodyOpenDeviceDTOdto,@RequestHeader("userId")LonguserId){// 校验设备是否存在且处于空闲在线状态Devicedevice=deviceService.getById(dto.getDeviceId());if(Objects.isNull(device)){returnR.fail("设备不存在");}if(device.getStatus()!=DeviceStatusEnum.ONLINE_FREE.getCode()){returnR.fail("当前设备正在使用中，请选择其他设备");}// 生成预订单，状态为待确认Orderorder=orderService.createPreOrder(userId,device);// 下发MQTT同步开锁指令，超时时间3秒CommandResultresult=mqttCommandService.sendSyncCommand(device.getDeviceSn(),CommandEnum.OPEN_LOCK,Collections.singletonMap("orderId",order.getOrderId()),3000);if(!result.isSuccess()){orderService.cancelOrder(order.getOrderId());returnR.fail("开锁失败，请稍后重试");}// 更新设备状态为使用中，确认订单生效deviceService.updateStatus(device.getDeviceId(),DeviceStatusEnum.ONLINE_USING.getCode());orderService.confirmOrder(order.getOrderId());// 组装返回VOOrderVOorderVO=newOrderVO();BeanUtils.copyProperties(order,orderVO);orderVO.setDeviceName(device.getDeviceName());returnR.ok(orderVO);}}

2. 设备状态上报对接

拼豆柜设备每30秒上报一次当前状态到MQTT Topic/device/{deviceSn}/report，EMQX通过规则引擎转发到后端服务的状态处理接口，后端校验设备合法性后更新缓存和数据库中的设备状态，同时判断拼豆剩余量是否低于阈值，若低于阈值则触发管理员预警通知。

3. 管理端数据统计功能

统计模块采用多线程异步统计+Redis缓存的方案，避免大数据量查询影响核心业务接口性能。每天凌晨自动统计前一天各门店的订单量、使用时长、新增用户数等指标，统计结果存入Redis，有效期24小时，管理端查询时直接读取缓存，响应时间可控制在100ms以内。

四、系统测试与上线部署流程

测试流程

开发完成后需经过4轮测试才能上线：

1. 单元测试：覆盖所有后端接口的业务逻辑，校验参数校验、异常处理是否符合预期，单元测试覆盖率不低于80%。
2. 接口联调测试：使用Apifox调试所有前后端接口、设备MQTT接口，确保参数传递、返回结果符合接口文档要求。
3. 硬件联调测试：模拟真实使用场景，连续测试100次开锁、锁柜、状态上报操作，成功率需达到100%，状态同步延迟不超过1秒。
4. 压力测试：使用JMeter模拟1000并发用户下单、开锁操作，接口响应时间不超过500ms，错误率低于0.1%，满足高峰时段使用需求。

部署流程

采用Docker容器化部署，简化环境配置步骤：

1. 服务器环境准备：安装Docker、Docker Compose，配置安全组开放HTTP(80/443)、MQTT(1883/8883/8083)端口。
2. 中间件部署：通过Docker Compose一键启动MySQL、Redis、EMQX、Nginx服务，挂载数据卷实现数据持久化。
3. 后端服务部署：将Spring Boot项目打包成jar包，编写Dockerfile构建镜像，启动容器并配置健康检查。
4. 前端部署：UniApp用户端分别打包成对应平台的包，H5版本和Vue管理后台打包后的dist文件上传到Nginx静态资源目录，配置反向代理规则转发接口请求。
5. 上线验证：上线后验证所有核心流程，包括开锁、结算、设备上报、管理后台统计功能是否正常，监控服务器资源使用率确保无异常。

本文提供的全栈开发方案已经过多个无人共享业态项目验证，不仅适用于无人自助拼豆系统，也可快速适配其他无人自助设备场景，后续可根据业务需求扩展AI作品识别、用户社区、拼豆款式推荐等功能，进一步提升用户体验。