去年帮一个中型园区做WiFi认证系统选型，甲方技术负责人扔过来三份厂商方案让我对比，我翻了一遍，发现三份方案里都刻意绕开的三个问题，恰恰是后面整个项目能否顺利交付的关键。这几个点如果选型阶段不谈清楚，后面基本就是在给实施团队挖坑。

认证协议选什么根本不是单纯的技术问题

很多人一上来就讨论Portal好还是802.1X好，好像这是一个非此即彼的选择题。但老实说，我在现场碰到的实际情况远比这个问题复杂。比如说园区里有几栋老实验楼，里面的网络设备连VLAN都不支持，你跟他谈802.1X就是空话。还有一部分场景是访客临时上网，你不可能给每个来访人员下发证书。

最头疼的是要同时兼容几种业务形态。有的区域是员工日常办公，走802.1X证书认证；有的区域是会议室和公共空间，走Portal短信验证；还有一部分是物联网设备，打印机、摄像头、智能门锁这些，它们根本不可能弹Portal页面，只能用MAC旁路认证。三种认证方式在一个WiFi认证系统里要平滑切换，SSID怎么分、VLAN怎么划、策略怎么下，这些都是选型阶段就要在脑子里跑通的。很多方案写到这儿就含糊其辞，说一句"支持多种认证方式"就带过去了，但怎么支持的、切换逻辑是什么、有没有性能损耗，这些都不讲。

我自己的经验是，选型的时候别问厂商"你们支持什么认证协议"，这个问题得到的答案永远是"全都支持"。你应该问的是：如果我同一台AC下面同时挂了Portal终端、802.1X终端和MAC认证终端，你的策略下发逻辑是什么？优先级怎么排？切换要不要重新关联？问具体场景，你能筛掉一半只会画PPT的厂商。

认证网关和计费引擎要不要分离

这个问题在方案评审的时候吵过不止一次。有人觉得认证和计费放在一起，管理方便、故障点少；有人觉得应该拆开，认证只管认证、计费只管计费，各自独立扩展。

从实际运维的角度看，我的结论是：如果你的场景只有一种业务形态，比如纯办公或者纯运营，合在一起问题不大；但如果你的WiFi认证系统要兼顾运营计费——比如校园网按时长收费、酒店按天计费、产业园区有包月套餐——那我强烈建议把认证网关和计费引擎拆开。原因很简单，认证协议升级或者切换的时候，你不希望影响计费数据的连续性。反过来也一样，计费策略调整、套餐变更、结算周期修改，不应该要求你动认证网关。

有一次我们在一个校园项目里就是这么做的。认证网关放在AC上面做802.1X和Portal的准入判定，策略服务器单独跑CoA来下发带宽限速和上网时长策略，计费引擎从Radius的Accounting报文中实时采集流量和时长数据。三个组件松耦合，中间全部通过标准Radius报文交互。项目交付两年，认证网关因为安全漏洞升级过一次，计费引擎因为新增支付通道改过三次，彼此完全不受影响。这个架构决定的不是性能，是运维的容错空间。

第三方对接不是"有接口就行"

选型阶段最容易被敷衍过去的就是对接问题。厂商方案里通常写"提供标准API接口""支持与第三方系统对接"，但你去细问就发现，他们所谓的"对接"可能只是提供了一个Webhook推送，你要自己写中间件来适配。

WiFi认证系统在实践中需要对接的东西远比想象的多。如果是校园场景，大概率要对接教务系统查学籍状态、对接一卡通系统做销户联动、对接短信平台发验证码；如果是酒店场景，必须对接PMS做入住客人自动开通、对接公安审计系统做实名上传；如果是园区场景，可能要对接OA做员工离职自动销户、对接访客预约系统做临时账号生成。

我碰到过最痛苦的一次，是甲方选了某个WiFi认证系统后，发现它的"标准API"只支持单向推送，不能接收外部系统回调。这意味着我们没法在OA里注销一个员工账号后自动同步到认证系统里去，所有离职销户都得人工登录后台操作。最后为了这个事儿专门写了一个定时同步脚本，每天凌晨跑一次，中间还有十二个小时的时间差——这个安全隐患，选型的时候没人提过。

所以后来我形成了一个习惯：选型的时候要求厂商开放测试环境，自己写个小程序调一圈他们的API，重点测三个能力：能不能双向调用、有没有回调机制、并发量上限是多少。不测不知道，一测吓一跳。

最后多说一句，WiFi认证系统选型别只看功能列表。功能列表这东西，每家都能写得一模一样。真正拉开差距的都在这些不写在彩页上的东西里：架构设计、对接能力、边缘场景的兼容性。多问几个"如果我这样这样"的问题，你能看到方案最真实的那一面。