企业官网建设流程全解析

GogoAI自助健身门店系统，访客临时入场方案设计

痛点分析

24小时自助健身房没有前台，访客、体验客、会员带朋友这类临时入场场景很难管控。传统方案要么直接给长期二维码，容易转发蹭卡；要么强制注册会员、买正式卡，流程繁琐流失体验用户。

同时存在几个典型问题：临时凭证缺少时间窗口、一次性限制，截图后反复开门；访客入场之后没有独立计费会话，和正式会员权限混在一起；缺少实名登记、风险黑名单，出现安全事件无法追溯；会员邀请访客模式下，人数上限、访客责任边界没有控制；断网场景下临时通行权限无法在边缘网关同步；访客账单、入场日志、安防抓拍无法关联，财务对账、纠纷复盘困难。

GogoAI自助健身系统设计独立的访客临时入场模块，区分管理员下发、会员邀请、线上购买单次票三类发证入口，采用签名动态凭证、时间窗口、一次一码机制，打通实名、计费、门禁、安防、消息通知链路，兼顾引流获客和场馆安全管控。

整体方案与访客类型划分

后端基于Spring Boot、Redis、MQTT边缘网关实现，访客分为三类：后台管理员临时通行（运维、保洁、体验接待）、会员邀请访客（会员带同伴）、线上散客访客（美团/小程序购买单次票、体验票）。

临时凭证核心属性：唯一凭证号、门店ID、生效时间、过期时间、最大入场次数、访客实名信息、凭证类型、计费模式（免费/固定单次/时段计费）。 核心数据表：visitor_temp_auth临时授权表、visitor_record访客入场记录表、visitor_invite会员邀请关系表。 凭证校验复用之前的入场权限责任链，新增访客校验节点，和正式会员卡权限隔离。

临时凭证生成核心Java代码实现

生成带签名的动态凭证，存入Redis，设置过期时间，防止篡改和重复使用。

@Service @Slf4j public class VisitorAuthService { @Autowired private StringRedisTemplate redisTemplate; @Value("${visitor.auth.secret}") private String authSecret; /** * 创建访客临时通行授权 */ public ResultDTO<VisitorAuthVO> createVisitorAuth(VisitorAuthDTO dto) { // 会员邀请场景：校验该会员剩余可邀请名额 if("MEMBER_INVITE".equals(dto.getAuthType())){ long inviteCount = inviteMapper.countTodayInvite(dto.getMemberId(), dto.getStoreId()); if(inviteCount >= dto.getMaxInviteNum()){ return ResultDTO.fail("今日邀请访客名额已用完"); } } // 生成唯一凭证 String authCode = UUID.randomUUID().toString().replace("-",""); // 签名防篡改 String sign = DigestUtils.md5DigestAsHex((authCode + dto.getStoreId() + dto.getExpireTime() + authSecret).getBytes()); VisitorAuth auth = new VisitorAuth(); auth.setAuthCode(authCode); auth.setStoreId(dto.getStoreId()); auth.setRealName(dto.getRealName()); auth.setPhone(dto.getPhone()); auth.setAuthType(dto.getAuthType()); auth.setMaxEnterCount(dto.getMaxEnterCount()); auth.setUsedCount(0); auth.setValidStartTime(dto.getValidStartTime()); auth.setValidEndTime(dto.getExpireTime()); auth.setFeeMode(dto.getFeeMode()); auth.setSign(sign); authMapper.insert(auth); // 缓存到Redis，网关可以快速校验 String key = "visitor:auth:" + authCode; redisTemplate.opsForValue().set(key, JSON.toJSONString(auth), Duration.ofMinutes(120)); VisitorAuthVO vo = new VisitorAuthVO(); vo.setAuthCode(authCode); vo.setSign(sign); vo.setQrContent(authCode + "." + sign); return ResultDTO.success(vo); } }

二维码内容由凭证编号+签名组成，门禁终端扫码后，上传到网关和业务服务双重校验，篡改签名直接拒绝通行。

凭证校验与次数控制逻辑

扫码入场时，校验链路依次判断：签名合法性、是否在有效时间窗口、剩余可用次数、门店匹配、访客是否在黑名单。 单次票设置maxEnterCount=1，扫码成功后立刻+1计数，同时删除Redis缓存，实现一次有效，截图无法二次开门；管理员临时通行可以配置多次，比如保洁全天多次进场。

会员邀请模式做限额控制，后台配置每个会员每日最多邀请人数，邀请链接绑定该会员，访客入场记录和邀请会员绑定，一旦出现尾随、违规，可以追溯到邀请人。访客入场之后，同样触发AB门防尾随、AI人数识别，安防告警逻辑和正式会员完全一致。

边缘网关定时同步门店访客临时授权白名单，外网中断时，缓存内的有效凭证依然可以正常扫码入场，离线入场记录本地留存，网络恢复后同步入库。

访客计费、订单和实名流程

线上购买访客单次票场景，访客先在小程序完成实名、支付，支付成功之后自动生成临时通行凭证；支持两种计费模式：固定单次费用（进场即扣费，离场不再结算）、时段计费（进场创建计费会话，离场自动按时长结算）。 免费体验、管理员运维通行选择免费模式，不生成计费订单，但是入场日志依然完整留存。

访客数据独立隔离，不进入正式会员卡包；访客订单单独标记订单类型，进入统一的异常订单状态机，支付失败、扣款成功但是凭证未生成时，同样走补偿和人工复核流程。访客完成入场之后，小程序推送入场通知、账单明细。

实名信息支持对接人脸终端，访客首次实名后，本次有效期内可以刷人脸入场；所有访客手机号、实名信息加密存储，后台严格控制查看权限，店长仅能查看本店访客记录。

邀请链路、后台管理与权限隔离

会员在小程序发起邀请，填写访客手机号，系统生成短链或者二维码，直接转发给访客；访客点开链接不需要注册会员，仅需实名确认即可拿到通行二维码。邀请可以设置有效期，超时自动失效，不占用会员长期名额。

总部后台看板可以查看全部门店访客记录；门店店长只能查看本店访客授权、入场流水；普通教练角色没有下发临时凭证权限。所有临时凭证下发、作废操作写入审计日志，记录操作人、凭证信息、作废原因。后台支持一键作废未使用的临时凭证，作废之后Redis缓存立即清除，即时失效。

访客黑名单独立维护，违规蹭卡、多次告警的手机号加入黑名单，任何门店都无法再次下发临时通行权限。

和上下游模块联动

访客模块和入场权限引擎对接，作为独立校验节点；和时段计费模块联动，进场创建计费会话；和消息推送模块联动，凭证即将过期提醒、账单通知；和安防模块联动，访客抓拍图片绑定访客记录；和总部权限模块联动，门店数据隔离；和订单模块联动，访客订单参与财务分账统计。

同时和IoT网关打通，临时授权变更之后，网关白名单实时刷新，避免权限缓存延迟放行。

落地风险与优化点

第一，访客二维码一定要做一次性控制或者短时效，不要生成长期有效凭证，避免截图流转； 第二，访客实名不可省略，24小时无人场景，实名是安全追溯的基础； 第三，会员邀请必须设置人数上限，放开无限制邀请很容易被用来多人蹭卡； 第四，边缘网关同步访客白名单，离线场景下也要校验次数和时间，不能离线无条件放行； 第五，访客账单单独归类，财务报表区分正式会员收入和散客访客收入，方便运营评估引流效果。

落地效果总结

访客临时入场方案落地之后，解决了自助场馆体验引流、会员带友、运维临时通行的需求，三种发证入口覆盖大部分临时场景。签名凭证+次数控制+时间窗口的组合，降低蹭卡风险，实名+日志满足安全追溯要求。

访客流程轻量化，访客不用注册正式会员即可快速入场，提升转化；同时权限、计费、安防、审计能力和正式会员保持一致，不会因为临时访客引入管控漏洞。整套方案和门禁、计费、订单、权限模块配合，完善无人门店的获客与临时通行能力。