GogoAI AI门店健身系统，入场权限控制逻辑解析
痛点分析
24小时AI自助健身门店没有前台人员，门禁是第一道风控关口。很多方案只简单校验会员卡是否有效，缺少多层规则判断，很容易出现各类安全和业务问题：过期卡、冻结卡依旧可以开门；时段卡不受黑白时段限制，夜间低价卡白天进场；预约类订单没有校验预约窗口，预约取消后权限没有即时回收。
同时凭证复用、代刷、尾随进场、跨门店通行等问题难以拦截；门禁硬件和业务系统权限不同步，后台修改卡状态之后，门禁缓存没有及时失效。单次核验链路涉及卡、预约、门店、时段、人数上限等多个条件，串行校验耗时过长，扫码开门响应慢，用户体验差。一旦权限判断出错，还会带来场地超额、资损和安防隐患。
GogoAI AI门店健身系统把入场权限做成分层校验引擎，统一支撑二维码、人脸、RFID多种凭证入场，将会员卡规则、预约规则、门店通行策略、限流策略整合在一起，做到权限实时生效、可追溯、可配置。
权限整体设计思路
后端基于Spring Boot开发，Redis用于凭证缓存、权限快照和限流控制，设备网关负责和门禁控制器通信。权限校验采用快速失败的校验链模式，前面条件不满足直接拒绝，不再执行后续校验，降低接口耗时。
整个校验链路分为五层：凭证合法性校验、用户与卡片状态校验、门店通行权限校验、时段与预约规则校验、场馆人流上限校验。校验全部通过后，下发开门指令，同时生成入场流水，同步给安防系统做人员统计。
数据库核心表：member_card会员卡表、access_rule通行规则表、reservation预约记录表、store_access_rel门店通行关系表、access_log入场日志表。通行规则支持后台可视化配置，不同卡种绑定不同的通行策略，不用修改代码。
权限校验引擎核心Java实现
使用责任链模式组装校验节点，每个校验节点只负责一项规则，便于后续扩展新的校验条件，比如增加黑名单、欠费拦截、未成年人时段限制等规则。
public interface AccessCheckHandler { /** * 权限校验处理 * @param accessDTO 入场凭证信息 * @return 校验结果 */ ResultDTO check(AccessDTO accessDTO); } @Component public class CardStatusHandler implements AccessCheckHandler { @Autowired private MemberCardMapper memberCardMapper; @Override public ResultDTO check(AccessDTO accessDTO) { MemberCard card = memberCardMapper.selectById(accessDTO.getCardId()); if (card == null) { return ResultDTO.fail("会员卡不存在"); } if (!"EFFECTIVE".equals(card.getCardStatus())) { return ResultDTO.fail("卡片已失效/冻结"); } // 判断是否在有效期 Date now = new Date(); if(now.before(card.getValidStartTime()) || now.after(card.getValidEndTime())){ return ResultDTO.fail("不在卡片有效期内"); } return ResultDTO.success(); } } @Component public class StorePermitHandler implements AccessCheckHandler { @Autowired private StoreAccessRelMapper relMapper; @Override public ResultDTO check(AccessDTO accessDTO) { boolean canAccess = relMapper.existsPermit(accessDTO.getCardId(), accessDTO.getStoreId()); if (!canAccess) { return ResultDTO.fail("该卡片不支持当前门店入场"); } return ResultDTO.success(); } } @Service public class AccessCheckChainService { @Autowired private List<AccessCheckHandler> handlerList; public ResultDTO verifyAccess(AccessDTO accessDTO){ for (AccessCheckHandler handler : handlerList) { ResultDTO result = handler.check(accessDTO); if (!result.isSuccess()) { return result; } } return ResultDTO.success("校验通过，允许开门"); } }预约类入场与时间窗口控制
对于团课、场地预约类入场，除了卡状态，还需要额外校验预约单。预约存在独立的准入窗口，比如预约19:00-20:00的时段，支持提前15分钟进场，延后10分钟离场，超出这个窗口直接拒绝入场。预约取消、预约核销完成后，权限即时失效，防止凭证二次复用。
系统区分两种入场模式：免预约入场（月卡、通用次卡）、强制预约入场（私教、团课、专项场地），在卡模板中配置入场模式，校验引擎自动适配不同分支逻辑。同时生成一次性动态二维码，凭证写入Redis并设置短过期时间，防止截图转发代刷。
缓存设计与权限实时同步
如果每次扫码都全量查询数据库，高并发场景下数据库压力较大。系统会在第一次校验通过后缓存权限快照，但增加失效机制：卡片冻结、过期、预约取消、门店权限变更时，主动删除Redis内对应的权限缓存，保证修改立即生效，不会出现缓存延迟放行的问题。
凭证缓存key设计：access:cred:{credNo}，同时记录凭证是否已经核销，保证一个凭证只能成功开门一次，拦截重复扫码。
限流、黑名单与防尾随联动
权限校验通过之后，还会校验场馆实时在场人数，达到限流上限时拒绝入场并提示用户稍后再来。黑名单单独作为独立校验节点，欠费、违规用户加入黑名单后，所有凭证直接拦截。
权限模块和之前的安防预警模块打通：门禁开门记录推送给AI摄像头，用于人数统计和防尾随识别。当AI识别到尾随，安防告警触发，不会直接关闭已开门，但会标记这条入场记录为异常事件，推送告警给管理员。
入场日志与审计追溯
每一次扫码、人脸尝试入场，无论成功或者失败，都会写入access_log日志，记录凭证编号、用户ID、门店ID、门禁设备编号、校验结果、失败原因。后台可以按门店、时间、用户维度查询入场记录，也可以导出报表，用于对账、事件复盘和客流统计。
日志异步写入消息队列，避免同步写库拖慢门禁响应速度；门禁开门指令下发之后，同步等待设备回执，如果设备返回开门失败，日志标记为开门异常，触发运维提醒。
异常场景容错处理
网络波动是自助门禁高频异常点，网关和后端网络断开时，不允许门禁本地放行，避免脱离平台管控。门禁本地只缓存设备配置，不缓存长期有效的会员权限。
当接口超时，门禁提示网络异常，请用户重试；后台补偿任务定期扫描入场流水，核对“校验成功但没有开门回执”的记录，标记异常并通知运营。同时支持管理员后台远程开门、临时通行码下发，应对用户特殊入场需求。
落地效果总结
这套入场权限控制逻辑落地GogoAI AI门店健身系统后，解决了自助门店门禁权限规则单一、凭证容易复用、权限变更延迟的问题。责任链模式让规则解耦，新增卡种、新增准入条件只需要新增校验节点，不用改动原有核心流程。
支持多凭证统一校验，免预约和预约两套模式自动适配，和购卡核销、安防预警、会员运营模块打通，形成会员从购卡、预约、入场、场内安防到离场的完整闭环，降低无人门店的运营风险。
