参与过几所学校的WiFi计费系统选型评审发现一个规律：大家看的东西都差不多——支持多少在线用户支持哪些认证方式跟哪些一卡通做过对接案例价格多少。这些当然重要但真正决定项目成败的往往是标书里不太显眼现场演示也看不出来的那些指标。

认证延迟P99值比平均值重要十倍

厂商给的性能参数里大概率会写"平均认证响应时间小于500ms"之类。数字看起来不错？但平均值欺骗性极强——100次认证里95次都是100ms剩下5次都是5秒平均下来也就350ms很好看。可那5个等了5秒的用户体验已经炸了。

你应该问的是P99值甚至P999值——所有认证请求里有99%或99.9%能在多少毫秒内完成。一个健康的计费系统正常负载下P99应控制在1秒以内P999不超过3秒。厂商给不出这些数据或者支支吾吾说没测过就要小心了。

更实用的方法是在POC测试阶段自己量。用压测工具模拟不同并发（至少测500/1000/2000/5000四个梯度）每个梯度跑够长时间（至少30分钟让系统热起来）然后自己算P99和P999。别信厂商测试环境数据要在你自己硬件或接近实际部署环境的条件下测。

故障恢复时间决定夜间睡眠质量

任何系统都会出问题关键出了之后多久能恢复正常。这个指标叫RTO（Recovery Time Objective）选型时几乎没人认真评估过。

具体要搞清楚几件事：Radius服务进程挂了自动重启要多久？数据库主从切换多久？配置文件改错了能不能快速回滚？服务器宕机冷启动全套服务要多久？这些问题的答案很多项目是"不知道"或"应该挺快的吧"。

建议招标技术要求里明确写入：核心服务（RadiusPortal计费引擎）单点故障恢复不超过5分钟；数据库故障切换不超过3分钟；全站级灾难恢复不超过30分钟。验收阶段逐一做破坏性验证做不到就扣钱或要求整改。凌晨三点被电话叫起来处理网络故障的时候你会感谢当初的自己。

日志系统能力直接影响排障效率

学生投诉"上不了网"你第一步干什么查日志对吧日志好不好用直接决定多快定位问题。

很多中小厂商日志系统就是文本文件往硬盘写查问题靠greptail。用户量小还行一旦日志量上来（一天几个GB那种）完全不可用。

你需要关注这几个能力：日志是否结构化存储（JSON格式可按字段检索）而不是纯文本；是否支持全文搜索和多维度过滤（按时间按用户ID按错误类型按AP设备）；日志保留策略是什么能查多长时间归档方案可不可靠；有没有异常检测告警能力（某个错误码暴增自动通知）。四条超过两条不满足后期运维成本会比省下来的采购成本高得多。

二次开发和接口扩展性

没有任何商用系统能完美匹配所有需求总有些定制化要做：对接特殊计费规则适配已有统一身份认证平台导出特定格式报表给财务部门跟门禁联动等等。

选型时要问清楚：提供了哪些API接口（RESTfulSOAP私有协议）？接口文档完整公开吗有没有SDK或示例代码？二次开发限制在哪（哪些表能改哪些不能改哪些配置开放哪些写死）？有没有客户社区或开发者支持渠道？

最痛苦的情况是买了一套功能基本满足的系统后来发现一个小需求做不了（比如需要把计费数据推送到另一个部门的系统）找厂商说"不在标准功能范围可以做定制但额外收费排期三个月"。那时候就很被动了。

运维工具链成熟度

最后这一点经常被完全忽略：上线后日常运维方不方便？

具体包括：有没有可视化监控面板（实时在线数认证成功率各区域流量分布）？告警机制完善吗（短信邮件企业微信钉钉都支持吗）？批量操作方便吗（批量修改套餐批量停机复机）？升级过程平滑吗（能不能不停服热更新）？备份恢复流程验证过没有？

有些厂商这些方面投入很大产品体验好；有些基本靠命令行和数据库直操对运维人员技术水平要求很高。信息中心团队规模有限或人员流动性大（高校很常见的话选一款运维友好型的产品比选一款功能强大但难伺候的划算得多。系统要用好几年不是演示完就扔的。

选型本质上是一系列取舍。没有完美的产品只有最适合当前需求和团队能力的方案。上面提到的指标不一定每个都满分但决策前至少纳入评估范围别只看厂商PPT上的对比表格。实施中才发现某个关键指标不达标那时候换方案的代价太大了。