选WiFi网络实名认证系统的时候，采购方通常盯着功能清单看：支不支持短信认证、有没有管理后台、能不能导出日志。这些是基本要求，差不多的产品都能满足。真正把系统用烂、用出问题的，往往不是功能有没有，而是几个平时不起眼的参数出了偏差。

认证并发量的数字不能直接信

供应商的产品手册上通常写了"支持XXX并发用户认证"，这个数字是怎么测出来的，测试环境和实际场景差多少，很少有人去追问。

认证并发的测试通常是在稳定网络环境下，每个并发用户持续发送轻量认证请求。实际场景的并发高峰是爆发型的：开学第一天早上八点，几千个学生同时打开手机，同时走认证流程，认证请求的时间分布是峰值型的，而不是平稳分布的。

在高峰期，WiFi网络实名认证系统要处理的不只是认证请求本身，还有短信验证码的发送、用户状态的写入、认证结果的推送。每一个环节都有延迟，叠加之后的实际响应时间可能远超手册数字。

建议在选型评测阶段，要求供应商提供实测场景下的峰值并发数据，最好能做现场压测，而不是只看手册。如果供应商不能提供实测数据，只给实验室数字，要在合同里写明实际部署后的性能保障条款。

短信验证码的发送成功率是个运营参数

短信验证码听起来是个成熟方案，稳定可靠。但短信到达率受到运营商网络、号段归属、发送通道质量的影响，不是百分之百的。

用户收不到短信的场景：国际号码（境外手机卡）、虚拟运营商号段在某些区域信号差、发送通道被运营商判定为营销短信拦截（这种情况比想象中多）。用户收不到短信，看起来是短信运营商的问题，但用户投诉的对象是场所和认证系统。

选WiFi网络实名认证系统时要问清楚：短信通道是哪家服务商？有没有备用通道自动切换？短信发送失败率的统计有没有监控？有些系统没有发送失败告警，一旦通道出问题，用户大量认证失败，运维不知道，只能等到投诉来了才反应。

认证白名单和黑名单的粒度影响实际管控

白名单允许某些设备绕过认证直接上网；黑名单禁止某些设备上网。这两个功能在WiFi网络实名认证系统里很基础，但粒度差异大。

有些系统的白名单只支持按MAC地址添加，MAC是设备级别的，容易被伪造。有些系统支持按IP段白名单，适合给固定IP的服务器或打印机免认证使用。更精细的支持按用户账号+设备组合白名单，某个员工的某台设备永久通过，换台设备就要重新申请。

黑名单也类似。封一个MAC，设备换一下MAC就绕过了。封一个账号，账号重新注册就绕过了。真正的封堵需要组合策略：MAC+账号+IP三重匹配，任一变化就触发重新验证。这种策略并非所有WiFi网络实名认证系统都支持，要在选型时验证。

日志的查询效率和导出能力要实测

很多WiFi网络实名认证系统能存日志，但查日志的体验很差。日志量大的系统，按条件查询要等几分钟，按指定格式导出可能要更长时间，甚至有些系统在大量数据导出时会超时报错。

监管审查往往要求在较短时间内提供特定时段的上网记录。如果系统查询慢，这个需求就是有压力的操作。系统本身查询效率不够的，只能提前把数据定期备份到外部存储，需要时从备份里查，但这又多了一套维护工作。

选型阶段，建议用实际数量级的测试数据做日志查询压测：数据量设置为三个月的日志估算量，查一个典型条件（如某账号最近90天的认证记录），看实际响应时间。大部分供应商演示时用的是几百条测试数据，和生产环境差距很大。

系统的可维护性决定了长期运营的成本

WiFi网络实名认证系统上线之后，账号管理、日志维护、固件升级、故障处理这些事是长期的。厂商的支持能不能跟上、有没有人在合理时间内响应故障，直接决定了系统用三年之后是顺还是烂。

我遇到过一个场景：某机构的WiFi网络实名认证系统三年前装好，原来负责维护的集成商已经不做这个业务了，系统厂商支持部门换了人，之前的配置文档没有交接，遇到问题找不到人说得清楚。最后花了比当初装系统更多的代价才理清楚配置，顺利升级。

选系统不能只看功能，要看厂商的支持体系是否完善、有没有标准的文档和运维手册、能不能在合理时间内响应故障。这些软性因素在选型比较表里通常不出现，但决定了系统能不能用好、用久。