做连锁企业的WiFi认证系统项目时，最大的难点往往不是技术选型，而是搞清楚总部到底管多少、门店自己能管多少。管多了，门店IT没权限处理本地突发情况，一个小问题要层层上报到总部，流程走完黄花菜都凉了。管少了，各门店标准不统一，出了安全事件总部完全不知情。这个分寸拿捏不好，系统上线之后就是无休止的扯皮。

统一认证还是分级认证，账要算清楚

先要做一个决策：认证的判定权放在总部还是放在门店？放在总部的好处是策略统一、安全可控、审计方便。所有用户的认证请求都回到总部的WiFi认证系统中心节点处理，门店只保留AP和AC作为认证代理。这样做的问题是，如果总部和门店之间的专线断了，门店的WiFi就变成了一个摆设——所有用户都无法认证，包括门店自己的员工。

放在门店的好处是网络自治，即使专线断了本地WiFi也不受影响。但问题也很明显：门店本地的认证日志和审计记录如果没有及时上传总部，出了安全事件总部没法追溯。而且门店IT的技术水平参差不齐，你让他们在本地维护一套WiFi认证系统，出了问题还得总部远程支持，人力成本算下来可能比集中部署还要高。

我们后来采用的是一个混合方案：认证的判定逻辑放在总部中心节点，但在每个门店的AC上配置了一个本地缓存策略。当专线正常时，认证请求走总部Radius；当专线中断时，AC自动切换到本地缓存的认证策略——只允许白名单内的设备接入，并且严格限制出口带宽。这样在断网情况下保障了最基本的业务连续性，同时安全风险也控制在可接受范围内。

总部下发策略要做到可灰度、可回滚

总部统一管理一个最大的风险就是：如果总部下发了一条错误的全局策略，所有门店同时受影响。这可不是开玩笑的事。有一次我们在总部后台调整了一条Portal认证的超时时间，从三分钟改成了一分钟，目的是提升安全等级。结果第二天门店就炸了：很多老年客户或者网络信号不太好的角落，一分钟根本来不及完成认证流程。门店电话打到总部IT支持那儿，一天接到了几十个投诉。

那次教训让我们在WiFi认证系统的策略下发流程里加了两道保险。第一是灰度发布：任何全局策略变更，先在几个试点门店生效，观察二十四小时没有异常投诉后，再逐步推广到全部门店。第二是一键回滚：所有策略变更都保留上一个版本的快照，一旦发现异常，总部门可以在后台一键回滚到上一个状态，不需要逐店登录操作。

本地管理员的权限边界要划清楚

门店IT需要一定的本地管理权限来应对日常运维——比如说帮客人解决上网问题、临时添加访客账号、查看本店的认证日志。但权限给多了，可能出现误操作；给少了，什么事都得找总部，效率太低。

我们做了一个基于角色的权限分级。门店管理员可以看到本店的所有认证记录和设备状态，可以创建临时访客账号（有效期不超过24小时），可以重启本店的AP。但不能修改认证策略参数、不能导出超过七天的日志、不能删除任何审计记录。所有门店管理员的操作日志实时上传总部，任何越权操作都会被自动告警。

这个权限体系的设计花了不少时间，但上线后效果很好。门店IT有了足够的自主权处理日常问题，总部也不用担心下面有人乱操作。说到底，多分支WiFi认证系统的核心矛盾不是技术上的，是管理上的——你得让每个层级的人都有他们该有的权力，同时也有他们该承担的责任。 再补充一个容易被忽略的细节：分支机构之间的网络环境差异。有的门店用的是企业宽带，有的门店用的是普通家宽，有的门店甚至用的是4G/5G CPE作为出口。这些不同的网络环境对WiFi认证系统的影响是不一样的。家宽的IP地址可能每天都会被运营商强制更换，如果你的认证策略里绑定了出口IP做区域识别，就会出问题。CPE场景下NAT层数多了一层，Portal重定向可能被多级NAT干扰。我们在项目中遇到过的最极端情况是一个门店同时接了三条宽带做负载均衡，用户的一次认证请求可能经过不同的出口出去，Radius服务器那边看到的源IP一直在变，差点被当成攻击给拦截了。所以多分支架构不光要考虑管理权限的分级，还要考虑每个分支网络环境的特殊性，在认证系统的网络策略上留够弹性。另外Portal页面的多语言支持和本地化适配也是连锁场景下的刚需，尤其是涉外酒店或合资企业，认证页面至少要支持中英文双语切换，且在海外访问时短信验证码的发送通道要能自动切换到国际线路，否则海外客人根本收不到验证码。