上个月有个做园区WiFi运营的朋友找我聊，他们刚接了一个新项目，大概两千多终端，方案选型上纠结了很久。他们之前一直用开源方案顶着，几十个AP、几百个用户的时候勉强够用，但规模一上去问题就全暴露了——认证超时、计费不准、对账出错，运维那边天天被客户催。他问我WiFi网络计费系统到底该怎么选，我跟他聊完以后觉得这个问题其实挺典型的，不只是他一个人遇到。

很多人有一种误解，觉得WiFi网络计费系统必须得上商业方案才靠谱。但实际上，如果你只有一两个点位、加起来不到两百个终端，用CoovaChili + FreeRADIUS + MySQL这套组合完全能跑。很多大学实验室里就是这么搭的，跑一两年没出过什么大问题。

但问题出在哪呢？出在"够用"的条件上。开源方案的前提是你得有人能维护——RADIUS配置、数据库优化、日志轮转、安全补丁，这些事情做起来都不难，但都需要花时间。很多小运营商或者小园区团队，IT就一两个人，既要管网络又要管服务器还要对接客户，根本没精力维护这套东西。我问过几个用了大半年以后放弃开源方案转商业产品的客户，原因几乎一样：不是开源方案不够好，是自己没精力伺候了。

所以小规模场景下选型的核心判断不是"技术能不能"，而是"团队能不能持续维护"。如果团队就一两个人，直接上商业WiFi网络计费系统反而更划算，前期多花点钱，后期少操很多心。

到了五百到两三千终端这个量级，WiFi网络计费系统的选型标准就跟小规模完全不同了。这个阶段你必须考虑几个开源方案天然缺失的东西：精确的流量计费、多套餐管理、用户自助服务门户、以及最基本的对账功能。

我见过一个商场WiFi运营的案例，他们用的是某国产商业WiFi网络计费系统，初期选了标准版。上线三个月以后发现一个问题：每天都有十几个用户的流量统计对不上，少了十几兆或者多了几十兆。单个用户差异不大，但一个月下来累积误差有好几百块钱。后来查出来是CoA（Change of Authorization）响应超时导致的部分会话没有正常终结，计费模块拿到的不是最终流量数据。

这类问题在小规模场景下根本不会被发现——用户基数太小，误差影响微乎其微。但规模一大，任何微小的计费误差都会被放大。所以中等规模选型的时候，不能只看"有没有计费功能"，要看计费精度、异常处理机制、以及是否能跟RADIUS的Accounting报文完整对接。

超过三千终端，或者有多个分支机构的场景，WiFi网络计费系统的选型就不能只看功能清单了，架构设计才是真正的决策因素。分布式还是集中式？多地部署的话数据怎么同步？运营管理权限怎么划分？这些问题没想清楚，功能再多也是白搭。

一个连锁酒店集团的技术负责人跟我说过一句话我觉得挺到位："我们要的不是一个功能最全的计费系统，而是一个出了问题能快速定位到是哪个节点故障的系统。"他这句话其实点出了大规模场景的核心痛点——单一故障点。如果WiFi网络计费系统把所有能力压在一台服务器或者一个数据中心上，任何一个环节出问题都会导致全网不可用。

所以这个规模的选型，重点应该放在：RADIUS负载均衡能力、分布式计费节点的数据一致性、多地部署时的网络延迟容忍度、以及是否有完善的分级管理权限体系。

不管什么规模，WiFi网络计费系统的选型都必须考虑一个铁一般的事实：它要对接现有的AP和AC设备。市面上没有一套方案能跟所有品牌、所有型号完美对接。我就碰到过一个项目，前期选型完全没考虑到这一点，签了合同、付了预付款以后才发现，AP厂商的RADIUS实现跟计费系统的标准RADIUS有兼容性问题——CoA消息格式不一致，导致部分用户下线后无法重新认证。

这种事情完全可以避免。选型之前至少要做三件事：第一，列出所有在用AP和AC的品牌型号；第二，让备选方案厂商提供一份兼容性测试报告；第三，在测试环境里至少跑一轮端到端的认证计费流程。这三件事花不了多少时间，但能避免上百万的项目翻车。

最后还有一个维度，几乎所有人在选型WiFi网络计费系统时都会忽略——长期的运维成本。这里说的运维成本不单指每年的维保费和升级费，还包括日常运营中需要投入的人力成本。

比如你的计费系统有没有自动化的对账功能？如果没有，财务每个月至少要花半天手动核对。有没有批量操作的界面？如果没有，运营人员每次上新套餐都要一个用户一个用户地改。这些看起来都是小事，但乘以十二个月再乘以三五年，累积起来的成本是非常可观的。

所以我一直建议，拿到报价以后不要只比功能点，要去看看这套系统的人机交互设计——运营端的操作复杂度、报表的自动化程度、异常告警的覆盖范围。这些才是决定你未来三五年运维体验的东西，比多一个少一个功能重要得多。