这两年做无人共享项目的人越来越多共享健身房算是其中门槛比较高的一类。原因很简单它不像共享充电宝那样只做一个扫码借还的闭环而是要把门禁、灯光、设备、计费、会员、多端入口全部串起来任何一个环节断了整个店就没法真正无人运转。我自己帮朋友落地过几个类似项目从需求梳理到设备联调再到小程序发版都走了一遍今天就把这套基于Java的无人共享健身房物联网系统源码拆开来讲重点说说物联网结合多端到底是怎么设计的以及你拿到源码之后要重点看哪些模块、动手改哪些地方。这个项目源码的覆盖面很完整后端是Java体系客户端同时支持微信小程序、公众号、独立APP和H5物联网端包含门禁控制、设备状态采集这类硬骨头。适合正在做共享经济、智慧场馆、物联网平台相关产品的开发者参考也适合准备拿来做毕业设计或商业落地的人直接改造成自己的方案。1. 无人健身房的业务闭环为什么说物联网多端是刚需1.1 先搞清楚无人健身房最核心的业务链路很多人一看到无人健身房就以为重点全在硬件上其实真正难的是业务链路设计。一次完整的无人健身流程应该是这样的用户在小程序或APP上完成注册和实名认证购买单次卡、月卡、次卡或充值余额然后到店扫码开门。门禁打开的同时物联网后台会记录入场时间并自动启动计费。用户在里面使用跑步机、椭圆机或力量设备时设备上的传感器或智能插座会上报工作状态系统可以判断设备是否被占用、是否异常运行。用户离场时再次扫码或通过蓝牙感应关门系统自动结束计费并从余额或卡次中扣费。这套链路里物联网和多端不是两个独立模块而是互相咬合的。门禁要响应小程序端下发的开门指令设备状态要实时同步到用户端页面计费规则要在服务端统一处理所有端只是不同的展示和操作入口。所以源码里你会看到业务逻辑高度集中在后端小程序和APP基本只是壳子加交互层。1.2 为什么用小程序公众号APPH5四端而不是只做一个端我经常被问一个问题有微信小程序不就行了吗为什么还要做APP和H5答案是用户习惯和运营场景完全不同。微信小程序获客成本最低适合新用户快速体验。用户扫门口二维码直接进入小程序开门连下载都不需要。公众号H5适合做会员服务、活动推送、余额查询这类轻操作。很多健身房的老用户习惯在公众号里收到扣费提醒和运动周报。独立APP适合高频核心用户。APP可以承载更复杂的数据展示运动记录、体测报告、课程预约也能做离线开门和蓝牙直连不依赖网络。通用H5适合PC端、异业合作页、广告落地页或者嵌入到其他第三方平台里。从技术角度看四端共用一套后端API是必然选择。源码里应该重点关注接口设计是否做到端无关也就是说小程序和APP调用的是同一套REST接口只是传参和鉴权方式略有区别。1.3 什么场景下这套系统才能真正跑起来我见过不少失败案例硬件商做了一套设备只管卖硬件不管软件互联网公司做了一套SaaS但接不了非标设备健身房老板自己拼凑了一套方案结果门禁和计费数据对不上用户投诉一堆。这套源码比较良性的地方在于它把设备接入、计费、多端都放在了一个体系里你拿到的不是单点功能而是一条完整的业务链。适合用它的典型场景包括24小时共享健身房、园区或公寓的公共健身区、酒店配套健身房以及想从传统值守模式转向无人模式的存量健身房。2. Java技术选型与工程骨架从单体到可扩展的设备接入层2.1 后端技术栈的基本盘这套系统后端用的是Java生态里最主流的一套组合说实话在共享经济类项目里算是性价比很高的方案模块技术选择在无人健身房里的作用基础框架Spring Boot提供REST API、定时任务、依赖注入等基础能力ORMMyBatis Plus操作会员、订单、设备、场地等业务表缓存Redis存储设备在线状态、验证码、临时开门凭证、高频计费数据消息队列RabbitMQ或Kafka处理设备上报消息、异步推送通知、订单结算事件数据库MySQL存储核心业务数据按业务分库或分表物联网通信Netty MQTTNetty处理硬件TCP长连接MQTT处理设备事件消息鉴权JWT Spring Security多端统一身份认证这套选型的好处是生态成熟、招人容易、遇到问题资料多。坏处是如果设备并发量特别大比如上万台设备同时上报MySQL和单机Redis会成为瓶颈需要在架构上做分片。但对于一家或几家健身房的规模这套方案绰绰有余。2.2 工程模块怎么划分才能不烂尾我拿到源码后第一件事就是看工程结构。如果所有代码堆在一个模块里后期加设备协议、加计费规则都会非常痛苦。比较好的划分方式是按业务域拆模块gym-common公共工具类、统一返回结构、异常定义gym-admin运营后台接口管理会员、订单、设备、场地、套餐gym-api面向C端多端的用户接口gym-iot物联网接入模块包含Netty服务、协议解析、设备指令下发gym-job定时任务模块处理计费结算、设备状态巡检、过期订单回收gym-message消息推送模块微信模板消息、短信、APP推送实际改造时你可以按这个思路重新组织自己的代码。模块化带来的直接好处是物联网协议变化不会牵动用户下单逻辑计费规则调整也不会影响设备控制代码。2.3 设备接入层为什么要单独抽象出来这是整套系统里技术含量最高的部分。无人健身房的设备不是一个品牌一个型号门禁可能是某家的网络门禁储物柜锁是另一家的蓝牙锁跑步机的数据接口又不一样。如果每接一种设备就写一套业务代码系统很快会变成一团乱麻。源码里的思路应该是把设备抽象成统一的模型每种设备对应一个DeviceAdapter实现。业务层只跟DeviceAdapter打交道不关心底层协议是TCP、MQTT还是HTTP回调。这样新增设备时只需要写一个适配器不需要动业务逻辑。public interface DeviceAdapter { // 设备连接后的初始化动作比如注册、鉴权、同步状态 boolean onConnect(DeviceSession session); // 解析设备上报的原始数据转换成统一DeviceData对象 DeviceData parse(byte[] rawData); // 下发控制指令比如开门、锁定、启动设备 boolean sendCommand(DeviceSession session, DeviceCommand command); }我第一次看到这个抽象的时候觉得很简单但真实场景里坑特别多。比如某款门禁的TCP协议是自定义二进制格式另一款用的是JSON over MQTT还有一款只提供云对云的HTTP接口。真正写适配器的时候你需要针对每种协议做编解码、心跳保活、异常重连这块的工作量往往比业务代码还大。3. 硬件接入的实战拆解门禁、智能锁和设备数据采集3.1 门禁控制的完整命令链路门禁是整个无人健身房场景里最关键的设备因为它直接关系到用户能不能进去以及计费从什么时候开始。源码里门禁控制的链路大体是这样的用户在小程序端点击开门小程序调用后端API发起开门请求。后端校验用户身份、会员状态、场地方是否有空位。校验通过后后端生成一个一次性开门凭证通常是一串有时效的签名串存入Redis设置过期时间。后端通过Netty连接或MQTT向门禁控制器下发开门指令指令中携带凭证。门禁控制器验证凭证后开锁同时上报门已打开事件。后端收到事件后创建入场记录开始计时计费。这个链路里有两个关键点一是凭证必须有有效时间防止用户把开门链接分享给别人比如有效期设成10秒或30秒二是开门指令必须走服务端下发不能小程序直连门禁否则绕过计费系统的风险太大。3.2 设备状态采集跑步机、椭圆机和力量器械怎么接入健身房和普通共享空间最大的不同是设备多、状态数据复杂。跑步机要上传运行速度、坡度、累计里程、心率椭圆机要上传踏频、阻力、卡路里力量器械可能只需要一个是否被占用的开关量。源码里一般会为每种设备定义一张数据表或一套数据模型。从硬件接入方式来看常见的有三种设备自带Wi-Fi或4G模块设备直接连接后端MQTT Broker定时上报状态。这种方式最省心但存量设备大多不支持。加装智能插座或传感器在设备电源线上装一个智能插座通过检测电流判断设备开关状态。成本低、兼容性好但拿不到精细化运动数据。对接厂商云平台部分商用健身设备厂商有自己的云端API通过厂商开放接口拉取数据。这种最稳定但受限于厂商文档和接口稳定性。我接触过的商用项目里往往是三种方式混用。门禁和储物柜用协议对接跑步机走厂商云或蓝牙网关普通力量器械用智能插座方案。源码里只要设备适配层设计得好这三种方案都能共存。3.3 调试硬件时的几个血泪经验硬件联调是这类项目里最消磨意志的环节我把自己踩过的坑列几个出来心跳机制一定要做。网络门禁长时间没有通信会被运营商NAT踢掉连接客户端必须按固定间隔发送心跳服务端也要做超时判定超时设备自动标记离线。设备指令的ACK很重要。下发开门指令后不能默认一定成功。有些门禁的继电器老化指令到达了但锁没弹开。源码里如果支持指令重试和失败上报要优先保留。本地时间和服务器时间校准。设备记录的上报时间经常不准时间戳尽量以服务器接收时间为准设备自身的时间只做参考。断电和恢复是必测场景。门禁断电后再上电是否能自动重连、状态是否从离线恢复为在线这套逻辑不跑通半夜设备掉线就等着用户打电话投诉吧。4. 多端源码的组织方式小程序、公众号、APP和H5如何共用一套后端4.1 微信小程序的工程结构与登录流程小程序的源码一般就是常规的微信小程序工程WXML、WXSS、JS三件套。但无人健身房场景里小程序最核心的是登录和开门两个页面。登录建议用微信官方推荐的wx.login换code再由后端调用微信接口换取openid和session_key自己维护一个用户体系。不要在小程序端直接保存用户的openid也不要把微信敏感信息暴露在代码里。开门页面的逻辑通常是这样页面加载时调后端接口获取当前用户可用的套餐或余额同时轮询或通过WebSocket监听门禁状态。点击开门按钮后显示加载中状态等待后端返回开门结果和入场记录。真正的无人健身房小程序还会做扫码进场扫的码可以是场地二维码或门禁上的静态码扫完直接触发同一套开门API。4.2 公众号H5和通用H5有什么不同公众号H5指的是在微信内置浏览器中打开的网页它可以直接用微信JS-SDK获取用户身份所以登录流程可以做到静默授权。通用H5则不行它没有微信的授权环境通常需要用户输入手机号加验证码登录。源码里可以观察一下它是怎么区分这两种场景的。好的做法是通过一个channel参数来标识当前请求来自哪个端后端根据channel决定使用微信授权登录还是账号密码登录。这样公众号H5、通用H5和小程序可以共用后端的/login接口只是参数不一样。4.3 APP端的实现思路原生、跨平台还是套壳APP端是这个项目里工作量最不固定的部分。如果你看到APP源码是Android和iOS两套原生工程说明开发方选择了最高成本但也最可控的方案。如果是一套UniApp或Flutter代码那说明重点在跨平台复用安卓和iOS共用一套逻辑。对无人健身房来说APP相对小程序的核心优势是支持蓝牙开门。小程序目前对蓝牙的支持虽然也能用但在锁类型兼容性和后台运行上不如APP。所以很多方案里APP会在用户靠近门禁时自动弹出蓝牙开门提醒省去扫码动作。这个能力是H5和小程序很难替代的。4.4 多端共用API时的权限和兼容设计多端项目最容易出的问题就是接口版本混乱。小程序已经发版上线了APP还在开发中后端接口一改线上小程序直接挂了。源码里如果能找到/api/v1/这类版本前缀设计说明作者有意识地在做多端兼容。我自己在类似项目里是强依赖版本管理的任何破坏性变更都强制开新版本接口旧接口保留一个过渡周期。另外不同端的操作能力要做权限区分。比如管理后台只能给WEB端使用开门指令只允许小程序和APP调用H5端可以做查询和支付但禁止触发门禁控制。这些可以在后端做clientType和permission的二次校验。5. 无人值守场景下的计费、会员与安全风控设计5.1 计费模型按时、按次、套餐混合策略无人健身房的计费比普通共享空间复杂因为健身时长普遍较长动辄一两个小时单纯的单价计费不灵活。源码里我建议重点看它的计费规则引擎是怎么设计的。优秀的实现会支持多种费用模型叠加按时计费按分钟或半小时为单位自动扣费适合散客临时锻炼。按次计费单次进入扣一次费适合只来跑步的人。月卡/季卡/年卡时间卡制一定期限内不限次数适合高频用户。储值卡先充值后消费按实际使用时长从余额扣减。组合套餐比如月卡10次私教课或年卡储物柜使用权。计费触发点要由物联网事件驱动。入场开门是计费开始事件离场关门是计费结束事件设备上报异常时可能触发暂停计费或免单逻辑。这些都应该是可配置的而不是写死在代码里。好的源码会有一张billing_rule表和一套规则解释器运营人员可以在后台配置不需要改代码。5.2 防逃单和异常订单处理无人场景下最大的风险是进门不付费和出场不结账。常见的风控手段包括预付保证金新用户首次进入时冻结一笔押金离场结算后退还或解冻。黑名单机制欠费或恶意逃单的用户加入黑名单门禁拒绝再次开门。异常订单巡检定时任务扫描那些打开超过24小时但没有正常结算的订单自动发送通知或执行强制结算。设备离线兜底如果离场关门事件丢失系统要能通过蓝牙信标或摄像头辅助判断人员是否离场否则会出现计费一直走着的恶意投诉。我见过一个项目把计费状态机做得特别细待入场、在场中、待结算、已完成、异常关闭、申诉中。每个状态之间都有明确的事件触发和超时机制。这套东西看起来繁琐但真正跑起来能省掉大量客服精力。5.3 会员体系与私域运营无人健身房没有前台会员的所有感知都来自线上。源码里的会员模块除了基础的注册、登录、资料维护还要能支撑运营。具体来说会员等级根据消费金额或锻炼次数划分等级不同等级享受不同折扣或权益。积分系统签到、锻炼、消费都能得积分积分可以兑换储物柜时长或饮品券。推荐有奖老用户拉新用户注册并消费双方都可获得奖励时长。数据报表每周给用户推送运动时长、消耗卡路里、锻炼频率的周报这是提升用户粘性的核心功能。小程序和公众号的模板消息在这里很有用。入场超时提醒、余额不足提醒、周报推送、活动通知这些都能通过微信模板消息触达用户成本几乎为零。6. 部署落地时最容易踩的坑与排查思路6.1 公网环境下的设备连接稳定性设备联网项目部署到公网后第一个不稳定因素就是网络。门禁设备通常部署在弱电井或墙壁内Wi-Fi信号时好时坏。出现了设备频繁离线的问题先别急着改代码按这个顺序排查检查设备所在位置的网络信号强度和丢包率。确认路由器是否开启了AP隔离导致设备无法访问公网。验证设备配置的服务器地址和端口是否正确很多设备出厂配置用的是旧IP。查看服务端日志里设备是主动断开还是长时间无心跳后被判定离线。如果是主动断开检查服务端是否有防火墙或负载均衡的闲置超时设置必要时调低心跳间隔。我遇到过最离奇的问题是设备每30分钟准时掉线排查到最后发现是设备固件里的TCP保活时间写死为1800秒和运营商NAT会话超时时间完全一致导致连接恰好被清掉。这种情况只能靠客户端心跳和服务端快速重连机制来兜底。6.2 数据库事务与计费一致性问题计费系统最怕的是扣费重复或漏扣。比如用户入场时创建了订单记录但离场结算时接口超时用户以为没扣费就再点了一次结算结果重复扣了两笔。源码里应该有幂等设计关键是让每次结算请求带上唯一的业务流水号后端根据流水号判断是否已经处理过。数据库层面订单创建、余额扣减、设备状态更新这三个操作必须放在同一个事务里或者通过消息队列保证最终一致性。我个人的做法是强一致性操作走数据库本地事务非核心操作比如推送通知、生成报表走消息队列异步处理。这样既保证核心资金安全又能让系统在高并发下不至于接口雪崩。6.3 一套源码落地时的改造顺序建议如果你拿到的是一套比较完整的源码建议按以下顺序改造而不是上来就改代码先跑通最小闭环部署后端配好数据库接一台门禁设备用一个测试小程序完成注册-购卡-开门-被动计费-结算全流程。再补设备把跑步机、储物柜、灯光等设备逐步接入每接一种设备都验证上报数据的准确性。然后做多端小程序稳定后再扩展公众号H5和APP。公众号H5可以直接复用大部分APIAPP如果是UniApp写的也能快速复用。最后完善运维配上监控告警、日志收集、定时巡检任务确保无人值班时系统能自己发现问题并通知人处理。在改造过程中一定要做版本管理每次改动都打tag。无人健身房项目涉及设备固件、后端、前端、数据库多个层面没有版本脉络的话出了问题定位起来会非常痛苦。6.4 源码之外你需要准备的东西最后说一句实话源码给你的是软件框架但真正让系统跑起来你还需要准备一些非代码的东西一台固定的服务器或云主机尽量选带宽稳定、延迟低的机房。域名和备案小程序要求后端API必须是HTTPS且域名要提前加到小程序后台白名单。设备厂商的技术对接文档和测试设备没有真实设备联调代码永远只停留在纸面上。微信小程序和公众号的注册资质个人主体无法开通微信支付商业项目需要企业主体。这些准备工作看着琐碎但每一样都卡在流程上。物理设备、支付资质、服务器环境任何一环缺了代码再完整也跑不起来。做了几个无人健身房项目之后我最大的体会是这类系统的技术难度其实不在某一块而在整合。Java后端、物联网协议、多端客户端、计费风控每块单独拎出来都有成熟方案但要把它们拧成一条稳定的链路靠的是对业务细节的死磕和足够多的真实踩坑经验。希望这篇拆解能帮你少走一些弯路尤其是拿到源码后不至于一脸茫然不知道该从哪儿下手。这套架构如果你能彻底吃透哪怕以后不做健身房做共享洗衣房、智能会议室、无人便利店思路都是相通的。