做了几年网络项目，WiFi计费系统设备选型阶段踩的坑不少。有些坑刚入行都会踩，有些坑要做到一定规模才碰到。整理出来，希望做选型的人少走一点弯路。

认证网关并发量的水分

认证网关是WiFi计费系统的核心硬件，所有用户的认证请求、流量统计、带宽控制都经过它。选型阶段供应商通常给一个并发用户数，比如"支持500并发"，听起来够用，但这个数字是怎么测出来的，测试条件是什么，要仔细核实。

常见的坑：供应商给的是"轻负载并发"——每个用户只有少量HTTP请求，不跑视频不下文件。实际场景里，500个用户如果有一半在看视频，认证网关需要处理的流量和状态维护量是轻负载测试的好几倍。选型时应该要求供应商提供满载并发参数，或者自己做压测。

另一个容易忽略的参数是"新建连接速率"——设备每秒能处理多少新增会话。早晨上班或课间休息，大量用户同时发起认证，如果这个速率不够，认证页面加载很慢，或者认证成功后网页迟迟打不开。这个参数比并发数更容易被忽视，但实际影响更直接。

AP数量和认证网关的比例关系

每台认证网关能管控的AP数量有上限，超过上限后AP的状态同步、策略下发、日志上报会出现延迟，进而影响用户体验。

不同厂商产品手册里这个上限写法不一样，有些是"管理AP数量"，有些是"最大AP接入数"，背后实现逻辑可能有差异。选型时要问清楚：AP数量到上限时，系统会自动拒绝新AP接入，还是降级运行（新AP用本地策略，不受集中管控）？降级运行期间计费功能是否受影响？

一个医院项目，改造前60个AP，选的认证网关最大支持128个，看起来有余量。后来扩建加了80个AP，总数超限，新加的AP全变成"游离状态"，不受计费系统管控，相当于医院里有一片区域的WiFi完全免费开放。发现这个问题是扩建完成三个月之后，客户以为一切正常，实际上计费覆盖面已经缩水了。

AC和认证网关分离还是合一

无线控制器（AC）和WiFi计费系统的认证网关，市面上有两种形态：分离和合一。

分离方案的优点是功能专注——AC只管无线管理，认证网关只管认证和计费，两者可以独立升级，互不影响。缺点是对接复杂，需要通过API或Portal协议交换用户状态，版本升级有时会导致对接失效。

合一方案的优点是对接是内部实现，稳定性有保障；缺点是功能扩展受限，想单独替换无线或认证部分，往往只能整套换。

50个AP以内的小规模场所，合一方案更简单，管理界面统一，故障排查路径清晰。多楼栋、多园区的大规模项目，分离方案更灵活，可以按区域部署认证网关，避免单点故障影响范围扩大。

终端兼容性测试不能省

WiFi计费系统的Portal认证页面需要在各种设备和浏览器上正常渲染和提交。听起来简单，实际上是每个项目里最容易出长尾问题的地方。

常见的兼容性问题：老款安卓（Android 7以下）的系统WebView版本旧，Portal页面JavaScript不能正常执行；iOS的Captive Network Assistant在某些网络配置下不工作，需要用户手动打开浏览器；Windows系统弹出的认证窗口尺寸固定，Portal页面没做响应式适配的话表单显示不全；MDM管理的企业iPad因为证书信任策略，可能直接拒绝加载Portal页面。

这些问题如果验收阶段才发现，改起来会涉及Portal模板修改和功能回归，很麻烦。正确做法是选型阶段就要求供应商演示兼容性清单，或者自备测试设备实测。

日志存储容量在选型时就要算好

WiFi计费系统的日志包括认证日志、流量日志、在线记录、告警日志。公共WiFi运营、教育行业有合规要求，需要留存一定时长的日志。如果设备本地存储不够，要么频繁清理历史日志，要么事后追加硬件，都是麻烦。

按500个并发用户、每用户每天1000条认证/流量记录来算，一年下来日志量级是亿级别。认证网关的本地存储能不能撑下来，或者有没有对接外部日志系统（syslog/ES）的能力，是选型时需要确认的硬性条件。

不要等选型结束后才发现设备本地只有64G的SSD，按日志写入速度撑不过半年，然后再临时想办法扩容或迁移历史数据。

备件库存和停产风险

这个问题三到五年内才会暴露，但选型时应该提前考虑。WiFi计费系统用的认证网关、AC是定制硬件，供应商停产这个型号或退出市场，备件会很难找，维修成本会大幅上升。

选型时应该问：这款设备的生命周期计划是多少年？供应商有没有备件库存计划？主要硬件能不能用通用服务器代替（软件授权可以迁移）？这些问题没有标准答案，但把它们问清楚，有助于在两款功能相近的产品之间做出更理性的判断。