GogoAI连锁自助健身房多门店统一管理系统方案
痛点分析
连锁自助健身房如果采用单店独立部署模式，门店数量增多之后会暴露大量问题：各门店卡种、定价、核销规则不统一，总部无法标准化管控；会员跨店通行、跨店约课流程割裂；营收、客流、订单数据分散在多个系统，汇总报表困难。
权限管控复杂，总部、区域经理、店长、教练角色混在一起，容易出现越权查看其他门店财务数据的情况；IoT门禁、储物柜、传感器分散管理，总部无法统一监控设备在线状态；营销活动只能单店单独配置，无法一键下发到全部门店；私有化和SaaS混合部署场景下，数据同步、版本迭代、运维成本持续升高。同时24小时无人模式对故障告警、异常订单、安防事件集中处理的要求更高，单店独立系统很难做到统一运维。
GogoAI多门店统一管理系统采用总部集中管控+门店自治的架构，一套后端支撑全部门店，支持总部统一配置、门店个性化调整，数据行级隔离，打通会员、卡种、订单、财务、IoT硬件、排课模块，兼顾连锁标准化和门店灵活运营需求。
整体架构设计
系统整体划分为四层：总部管控层、门店业务层、边缘IoT网关层、用户终端层。
总部管控层负责品牌配置、全局卡模板、营销活动、财务汇总、报表看板、分级权限、系统版本下发；门店业务层承接本店会员、订单、时段计费、私教排课、访客管理；边缘网关部署在门店本地，处理门禁、摄像头、储物柜等硬件，支持断网自治；终端包含会员小程序、教练端、店长后台、总部运营后台。
采用微服务拆分：用户权限服务、门店配置服务、会员卡包服务、订单计费服务、排课服务、IoT物联服务、消息通知服务、数据报表服务。数据库采用共享库+行级门店ID隔离方案，所有业务表携带store_id，MyBatis拦截器自动拼接过滤条件；支持混合部署，大型连锁客户可选择独立库私有化交付。
核心数据表：store_info门店信息表、store_config门店配置表、global_card_template全局卡模板表、user_store_rel用户门店关联表。
门店数据隔离核心代码实现
基于AOP+MyBatis拦截器实现自动数据权限过滤，区分超级管理员、总部运营、区域经理、门店账号的数据范围，避免每个业务接口重复编写门店过滤逻辑。
@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface StoreDataScope { boolean enable() default true; }@Aspect @Component @Slf4j public class StoreDataScopeAspect { @Autowired private UserContext userContext; @Before("@annotation(scope)") public void before(StoreDataScope scope) { if (!scope.enable()) { return; } LoginUser loginUser = userContext.getLoginUser(); // 超级管理员放行，不做门店过滤 if (loginUser.isSuperAdmin()) { DataScopeContextHolder.clear(); return; } List<Long> storeIds = loginUser.getStoreIdList(); if (CollectionUtils.isEmpty(storeIds)) { throw new ServiceException("当前账号未分配门店权限"); } // 将可访问门店集合存入线程上下文，供MyBatis拦截器拼接SQL DataScopeContextHolder.setStoreIds(storeIds); } }门店查询接口直接增加注解，自动隔离数据：
@Service public class MemberService { @StoreDataScope public Page<MemberVO> getMemberPage(MemberQuery query) { return memberMapper.selectPage(query); } }总部与门店配置下发机制
系统区分全局模板和门店私有配置，卡种、体验活动、计费规则分为两种模式：总部模板下发、门店自主创建。总部创建全局卡模板之后，可以选择下发到指定区域或者全部门店，门店接收模板后可以修改售价、有效期等本地化参数，基础权益模板锁定，防止门店随意修改卡权益造成会员纠纷。
配置变更采用发布订阅模式，配置更新后推送消息到MQ，门店缓存自动失效；门店本地缓存本店的卡种、计费规则、门禁权限，减少高频查询对数据库的压力。配置变更日志留存，记录修改人、修改门店、变更前后内容，用于审计追溯。
会员跨店通行能力在这一层实现：总部开启跨店通用开关后，会员在A门店购买的通用卡，到B门店扫码时，权限引擎自动校验卡权益，联动B门店边缘网关开门，同时记录跨店入场流水，财务可以按门店维度拆分营收。
分级权限体系
权限分为功能权限+门店数据权限两层，预设角色支持自定义：
- 总部管理员：查看所有门店数据，新增门店、下发全局模板、查看汇总财务报表、管理所有设备告警；
- 区域经理：绑定一组门店，仅查看该区域门店运营数据，可给区域内门店账号分配权限；
- 门店店长：仅本店权限，可以创建本店私有套餐、查看本店会员、订单、客流、设备；
- 教练：本店会员查看、约课签到，无财务、设备配置权限。
所有高危操作，比如批量调整会员课时、远程开门、退款操作，都需要二次验证并写入审计日志。门店账号无法看到其他门店的会员手机号、财务流水等敏感数据。
IoT硬件集中运维链路
所有门店边缘网关统一接入IoT服务，总部运维看板集中展示各门店门禁、读头、储物柜、传感器在线状态、告警信息。告警支持分级推送，撬门、尾随、烟感告警同时通知总部运维和本店店长；设备离线、电压异常等故障告警汇总到运维工作台。
总部支持远程指令下发：远程开门、同步权限白名单、网关配置更新、OTA固件升级。新店上线标准化流程，后台录入门店信息，网关绑定门店SN，自动拉取门店配置、权限模板，缩短新店部署周期。网关本地自治能力保留，外网断开时门店门禁、计费正常运行，联网后批量同步事件到云端，保证连锁门店网络不稳定场景持续营业。
财务和数据汇总报表
系统自动汇聚各门店订单、核销、时段计费、私教提成数据，支持总部查看全域营收、客流趋势、卡种销量、门店对比报表；报表支持按日、周、月、自定义时间筛选，自动区分通用卡跨店收入、门店自有套餐收入、访客散客收入。
财务分账规则可在总部统一配置，设置教练提成比例、门店分成；核销完成后自动生成分账流水，门店店长只能查看本店分账明细，总部可以查看全量分账数据。报表导出权限受控，只有财务、超级管理员拥有导出权限。
和各业务模块联动逻辑
多门店基座作为底层支撑，和之前各个业务模块打通：
- 订单异常模块：异常订单按门店归类，总部可以查看所有门店异常订单，门店店长只能处理本店订单；
- 私教排课模块：教练绑定门店，跨门店排课需要总部开启跨店授课权限；
- 访客临时入场模块：访客记录归属门店，黑名单总部全局生效；
- 备份模块：私有化连锁方案支持总部集中备份所有门店数据，单门店也支持独立备份；
- 消息推送模块：告警、营销通知可以选择推送单门店、区域、全部门店。
落地优化与踩坑总结
第一，不要直接把所有门店数据无差别开放给总部账号，严格使用数据权限拦截器，避免接口越权漏洞；
第二，全局模板下发和门店私有配置做好版本隔离，门店修改的内容不要覆盖总部原始模板；
第三，跨店卡的计费、分账规则提前定义，避免会员跨店消费之后营收归属不清；
第四，IoT告警量很大，增加告警聚合、防抖，相同门店短时间重复告警合并推送，防止运维被消息轰炸；
第五，门店数量持续增长之后，报表统计SQL压力大，采用异步预聚合统计，定时生成报表快照，减少实时查询压力。
落地效果总结
这套多门店统一管理方案适配直营连锁、加盟连锁两种模式，已经在多家24小时自助健身品牌落地。总部实现标准化管控、统一营销、集中运维，门店保留本地化运营的灵活性；数据隔离机制保障门店之间数据安全，同时全域数据可以汇总分析。
整套基座可以平滑扩容，新增门店只需要在后台录入门店信息、绑定边缘网关，不需要单独部署一套系统。和门禁IoT、时段计费、私教排课、访客入场、异常订单模块组合，形成一套可复制的连锁自助健身数字化平台。
