前阵子帮朋友落地了一套无人自助洗宠店小程序,整个项目从零做到可以上线,前后差不多两个半月。后端用的JAVA(Spring Boot + MyBatis-Plus + MySQL + Redis),前端是微信原生小程序,智能门锁、智能插座、水控全部通过HTTP接口对接,配合支付回调、倒计时结算,真正把一家店跑成了无人值守。这篇文章我想把整套实现方案、数据库设计、核心接口逻辑和一些可以直接拿去改改就能用的开源代码片段完整交底,给准备做类似项目的朋友一个参考底稿。如果你是小程序开发者、Java后端,或者正打算在社区、商圈投一家自助洗宠店,这篇内容应该能帮你少走不少弯路。
1. 项目拆解:无人自助洗宠店到底由哪些模块组成
1.1 业务场景全流程
先把无人洗宠店的实际使用场景完整走一遍。
用户走到门店门口,看到海报上的小程序码,微信扫码进入小程序,首页自动定位到这家门店,看到套餐列表:小型犬基础洗护、大型犬精洗、自助吹干+药浴等。用户选一个套餐,预约下午两点到三点,点击支付。支付成功后,小程序弹出门锁和对应工位的开启按钮。用户按下开锁,门锁打开,进入工位,把狗放进恒温浴缸,扫码启动吹水机,系统开始计时。洗完后用户点“结束使用”,系统按套餐原价加上超时费用结算,超时部分从余额或原支付渠道扣款,门锁再次解锁放用户出门。
整个过程没有店员,所以后台至少要做四件事:身份识别(openid/手机号)、库存控制(哪个工位空闲)、订单生命周期管理、设备联动控制。拆开来看就是六个模块:用户、门店、套餐、订单/支付、设备、运营后台。
这个流程里最容易出问题的是支付和设备联动。支付出问题,用户付了钱订单不更新;设备联动出问题,用户付了钱开不了门。我在后面会重点讲这两块的实现和避坑。
1.2 技术选型:为什么是Java + 原生小程序
我在选型的时候也纠结过。
如果只想做演示Demo,用Python Flask或者Node.js一周就能把接口全写完,小程序端甚至可以用uni-app一套代码发微信、支付宝两个端。但这是开实体店,不是课程设计,后端稳定性、支付安全性、团队可维护性都得考虑。
最终选Java有四个原因:
- 支付生态成熟。微信支付遇到问题,搜“Java微信支付v3”能找到大量答案和官方SDK,踩坑成本低。
- 并发场景好处理。无人店的峰谷明显,周末下午可能几十个用户同时下单开锁,Spring Boot + Redis面对这种量级很稳。
- 团队招人容易。Java后端在招聘市场上供给量大,后续接手成本低。
- 设备对接不受限。门锁、插座厂商都提供HTTP接口,Java作为服务端调它们没有任何障碍,生态里也有大量成熟的HTTP客户端和定时任务方案。
小程序端我也没犹豫,直接用原生。无人店核心页面就那几个:首页、门店列表、套餐详情、订单状态、支付回调。原生小程序稳定、包体积小、对硬件设备SDK的适配更直接,没必要为了“多端复用”强行引入一套跨端框架。像套餐选择页用到的radio单选框、自定义顶部标题这些功能,原生实现起来都很顺手。
1.3 系统模块划分
我习惯把这种系统拆成四个端:
- 小程序端:首页/门店定位、套餐展示、预约下单、支付结果、订单中心、工位状态。
- 后端服务:用户授权、套餐与库存、订单状态机、微信支付、退款、设备控制指令、定时任务(超时关单/自动结算)。
- 设备端:智能门锁、洗护设备、水表电表,每台设备有唯一deviceId,后端通过HTTP接口下发指令,设备端主动上报心跳。
- 运营后台:门店信息维护、套餐价格调整、设备上下线、退款审核、经营报表。
这四个端里,后端服务是大脑,订单状态机和支付回调是核心中的核心。下面逐步讲清楚。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动手前的准备:注册、类目、支付和数据库设计
2.1 小程序注册、类目与开发配置
写代码之前先把微信侧的资质搞定,不然代码写完也上不了线。
小程序注册主体建议用企业或个体工商户。个人主体小程序不能开通微信支付,很多设备能力也受限,做无人付费场景基本行不通。
登录微信公众平台后,在后台选择类目。无人洗宠店在“生活服务”大类下找“宠物服务”,系统会要求上传营业执照和经营范围证明。这个环节千万别嫌麻烦,类目选错了后面支付审核过不去,甚至整个小程序会被限制支付功能,整改周期非常长。
开发者工具里要做几件事:
- 开发环境可以关闭“校验合法域名”开关,否则本地请求服务器会被拦。
- 申请并配置服务器域名。注意request合法域名和uploadFile合法域名是分开的,我一开始只配了request,结果图片上传一直报域名不合法。
- 如果后续要用WebSocket推送工位状态,还要在socket合法域名里加上地址。
如果你是第一次接触Java开发,环境变量要先配好。我遇到过不少同事,代码写完了,本地java -version都跑不起来,最后发现是JAVA_HOME没配对。网上搜“java环境变量配置详细教程”有很多,生产环境建议统一用JDK 8或11,别在服务器里混版本。
2.2 微信支付v3的开通与密钥管理
微信支付现在必须用v3接口,早期教程里的v2接口文档已经逐步下线。开通流程大致如下:
- 在微信支付商户平台注册商户号,完成对公账户验证。
- 商户号关联小程序AppID。
- 自己生成APIv3密钥(32位随机字符串,自己保存,微信不存储)。
- 下载商户API证书,包含证书文件和私钥文件,私钥文件有密码。
- 下载微信支付平台证书,用于回调验签。
- 在商户平台配置回调地址notify_url。
密钥管理有几个经验:
- APIv3密钥和商户私钥不能提交到Git仓库,可以用配置中心或环境变量注入。
- 回调地址必须是公网HTTPS,开发阶段用内网穿透工具联调,生产环境必须用正式域名。
- 官方提供的SDK,推荐用wechatpay-java,回调的验签、解密都封装好了,能少写很多底层逻辑。下面的代码片段我会讲如果自己实现需要怎么做,但生产环境用官方SDK更省心。
另外提一句,“微信小程序签名”这个关键词其实包含两层含义:一是微信登录时后端要用appid+secret换取openid,二是支付接口用商户私钥做RSA签名。这两块我都遇到过问题,后面在核心实现里详细说。
2.3 核心数据库表设计与状态机
数据库设计是这套系统最容易返工的地方。我最终的落库核心表主要有这几张:
| 表名 | 核心字段 | 说明 |
|---|---|---|
| t_user | openid, unionid, nickname, phone, balance | 用户表,openid唯一 |
| t_store | name, address, lat, lng, status | 门店表 |
| t_device | store_id, device_code, device_type, status | 设备表,门锁/插座/水控 |
| t_product | store_id, name, price, duration, unit_price | 洗护套餐表 |
| t_order | order_no, user_id, store_id, device_id, product_id, amount, pay_amount, status, start_time, end_time | 订单表,核心表 |
| t_pay_record | out_trade_no, transaction_id, order_id, amount, |
