很多学校和企业准备上WiFi网络计费系统的时候，立项报告写得特别详细，需求清单列了几十页，但翻来覆去看一遍，会发现真正能决定项目成败的几个基础前提反而没人提。大家都在讨论系统功能够不够全、价格够不够低，却没人问"我们的网络底座能不能支撑这套计费系统"。结果系统买回来了，装上去才发现底层网络设备不支持必要的协议，或者无线AP密度根本不够，计费再准也没有用。这种情况在项目里反复出现，说明选型阶段确实存在一些被系统性忽略的问题。

网络设备的协议支持是第一道门槛

WiFi网络计费系统要正常工作，底层网络设备必须支持相应的认证协议，常见的有Portal认证、802.1X、MAC认证等。这不是系统能不能跑起来的问题，是能不能跑通的问题。有些学校的老款AP只支持简单的Web认证，不支持802.1X，选型时如果不确认这一点，买回来的计费系统可能只支持802.1X认证，结果就是系统装好了但终端连不上。选型阶段必须把"现有网络设备型号清单"和"计费系统支持的认证协议清单"做交叉比对，把不支持的部分单独列出来，要么换设备要么换方案，不能含糊过去。

无线覆盖密度直接影响计费数据的准确性

WiFi网络计费系统的计费数据来自用户的实际上网行为，而用户的上网行为受无线信号质量影响很大。如果某个区域信号弱，用户频繁掉线重连，计费系统会记录大量的短时连接，流量统计也会出现碎片化数据。这种数据拿来计费，准确性很难保证，用户投诉也难处理。选型时不能只看计费系统本身的精度指标，要结合实际无线覆盖密度一起评估。信号覆盖不达标的区域，先把AP补齐再谈计费，否则系统上线后就是一堆说不清的账。

用户规模和并发量是两个不同的概念

选型时大家习惯说"我们有1万用户"，但WiFi网络计费系统真正要扛的是并发量，不是用户总量。1万用户里，同时在线的可能只有两三千，高峰期可能飙到五六千。计费系统的认证服务器、数据库、计费引擎都要按并发峰值来选型，不能按用户总数算。有些系统标称支持10万用户，但并发认证只能扛500，放在学校宿舍区晚上集中上网的场景里根本不够用。选型时要把"高峰期并发认证量"和"日常在线终端数"两个数字问清楚，按峰值放大1.5倍做选型依据，留出余量。

认证页面的响应速度直接影响用户体验

Portal认证页面看起来简单，但它的响应速度对用户体验影响极大。学生连上WiFi后弹出认证页面，如果3秒打不开，很多人会以为网络有问题直接退出。选型时很少有人关注认证页面的加载性能，更多在看功能列表。实际上认证页面的响应速度取决于计费系统的认证引擎处理能力、数据库查询效率、以及认证页面本身的部署位置。选型阶段要把"认证页面平均响应时间"作为硬指标，最好实测一下高峰期的表现，不能只看供应商给的实验室数据。

数据存储和审计能力的边界要提前确认

WiFi网络计费系统产生的数据量比很多人想象的大。每个用户的认证记录、流量记录、上下线记录都要存储，按照公安部的要求还要留存至少60天。如果一个学校有1万活跃用户，每天产生的认证日志可能就有几十万条，加上流量明细，存储需求不是小数目。选型时如果不确认存储容量和扩展方式，系统跑几个月就可能因为存储满了出问题。另外审计能力的边界也要提前问清楚——系统能按用户、按时间段、按IP查多细的粒度，导出报表格式是什么，这些在项目后期都是运维反复要用到的功能。

和现有身份认证系统的对接方式不能想当然

学校一般已经有统一身份认证系统，WiFi网络计费系统要和它对接，但对接方式有好几种——LDAP同步、RADIUS转发、API调用、数据库直连。选型时如果只写"支持对接统一身份认证"，不具体到对接方式，后面实施时就会发现两种系统之间的数据同步延迟、账号状态不一致、密码修改不同步等问题层出不穷。选型阶段要把对接方式定到具体协议层面，最好让两个系统的供应商坐在一起确认接口细节，不能只听计费系统供应商单方面说"没问题"。

运维团队的承接能力决定系统能不能用好

WiFi网络计费系统上线后，日常运维工作量不小——用户开户、套餐变更、故障排查、报表导出、策略调整。如果学校网络中心只有两三个人，还要兼顾其他系统，选一个操作复杂、每改一个策略都要翻三层菜单的系统，运维根本跟不上。选型时要结合自己运维团队的实际情况，看系统的管理界面是否清晰、常用操作是否便捷、是否支持批量操作、是否提供足够的运维日志。功能再强大，如果运维用不起来，系统就只是一个摆设。