做WiFi无线认证系统，本地部署还是云端，是选型时绕不开的一道决策。两种方式都能跑通认证计费，但运维归属、数据位置、扩容方式、故障责任全不一样。很多项目上线前没想清楚，跑了一年才发现部署形态和自己的团队能力、合规要求根本不匹配，迁移的代价比当初多想两天贵得多。

本地部署：数据在手里，运维在肩上

本地部署把认证平台放在场所自己的机房或服务器上，实名数据、上网日志都留在本地的网络里。它的优势是数据主权清晰，尤其适合对数据出境、数据位置有硬性要求的政务、金融、涉密场所。坏处是运维全靠自己：服务器要管、数据库要备、版本要升、故障要自己救。如果场所没有专职网络运维，本地部署会把一个"用系统"的事变成"养系统"的事。

云端部署：运维外包，前提是网络通

云端部署把认证平台放在服务商的云上，场所侧只留接入设备（AC、BRAS、网关），认证计费统一回连云端。它的好处是运维轻：版本升级、数据备份、双机热备都由云端做，场所不用养服务器。特别适合多分支、连锁类项目，加一家店只是"加一个接入点"。前提是中心到云端的网络要稳，一旦场所出口断了，认证可能受影响（部分场景可配本地缓存兜底）。

混合部署是很多项目的现实解

不是非本地即云端。不少项目走混合：认证平台在云端管账号和计费，但实名日志、审计数据落地在本地或对接本地审计设备，满足"数据不出场"的合规；或者中心在云、分支本地有轻量缓存应对断网。混合部署照顾了运维轻量和数据合规两头，代价是架构设计要更清楚，哪些上云、哪些留地、断网时怎么降级，方案阶段就要画明白。

VPN是云地对接的技术前提

云端部署里有个容易被忽略的技术点：很多分支的NAS设备本身没有固定公网IP，而Portal协议要求双方能交互才能完成认证。这时候通常要靠L2TP VPN拨号，让分支NAS拨到云端认证平台拿到固定地址再对接。认证系统一般内置VPN服务器和VPN用户管理来接这个需求。做云部署方案时，得先确认每个分支能不能稳定建VPN，否则认证链路建不起来，页面怎么弹都白搭。

按团队能力而不是按潮流选

选型时一个常见误区是"云更先进所以选云"。先进不等于适合。如果你场所没有运维人力、又不在乎数据位置，云是对的；如果你有专职团队、数据有合规红线，本地或混合反而更稳。反过来，连锁类多分支硬上本地，每家店养一套运维，成本和控制力都崩。所以部署形态该由"团队能力 + 数据要求 + 分支数量"三件事共同决定，不是由哪个词听起来新决定。

留好迁移的退路

不管选哪种，都建议想清楚三到五年的发展：门店会不会从三家变三十家？数据要求会不会收紧？团队会不会换血？这些变量变了，部署形态可能要调。所以初期就尽量选"能平滑切换"的架构，比如账号体系标准化、日志格式规范、对接协议用主流标准。等真要迁移时，是"导出导入"的事，不是"推翻重来"的事。部署决策不是一锤子买卖，留好退路比一次选对更重要。

断网降级要想清楚

云部署最怕的是"场所出口一断，认证全瘫"。所以选云之前要问清楚：断网时本地有没有缓存兜底？分支的AC/BRAS能不能在云连不上时暂用本地认证策略？这部分降级配得好，云部署的可用性才立得住；配不好，一次运营商光缆挖断，全分支上不了网，责任全在办网者。本地部署反之，断云不影响本地，但运维重。降级策略是部署决策的隐藏条款，选型时就必须摊开谈。

成本结构也要算清

部署选型常只比功能，不比成本结构。本地部署看似一次买断便宜，但服务器、备份、运维人力、版本升级都是持续投入；云端看似省了硬件，但是按年订阅、流量和节点都计费。多分支场景云的边标成本往往更可控，单点小场所本地的边标更省。选型时把三到五年的总拥有成本拉出来比，而不是只看首年报价，结论常常反过来。