校园网计费系统最核心的输出是账单。账单不准确，轻则学生投诉，重则财务对账出错，影响学校和运营商的合作。做过大型校园网项目的人都知道，账单问题通常是上线后3-6个月才集中爆发的——前期测试没覆盖到真实的高并发场景。

账单不准的根本原因：计费报文丢失

计费系统的底层逻辑是：认证网关周期性向计费服务发送Radius Accounting报文（计费开始、计费更新、计费结束）。计费服务根据报文里的上网时长、流量数据计算费用。

问题出在：Radius Accounting报文是基于UDP传输的，不保证送达。如果网络抖动或者计费服务短暂繁忙，部分计费报文会丢失。丢失的如果是"计费结束"报文，这个用户的上网会话就会一直在计费系统里"挂着"，持续计费。

好的计费系统会做"会话保活检测"——定期向认证网关查询"这个用户是否还在线"。如果网关返回"已离线"，计费系统自动关闭会话并结算。没有这个机制的产品，账单不准是必然的。

测试账单准确度的正确方法

厂家演示的时候，通常会拿1-2个测试账号跑一遍流程，然后告诉你"账单准确"。这种演示没有参考价值。

正确的测试方法是：模拟真实场景的并发用户数，让所有用户同时上线、随机下线，跑24小时，然后比对计费系统里的账单记录和认证网关里的实际在线日志。差异率超过1%的产品，不要选。

还有一个测试方法：故意重启计费服务，看重启期间上线的用户，计费系统能不能补录计费报文。不能补录的产品，说明架构设计上没有考虑计费报文的持久化和重传机制，后期账单准确度一定会出问题。

跟运营商对账的差异处理

很多校园网是"学校代运营商收费"模式：学生买上网套餐，钱先到学校账户，学校再跟运营商结算。这种场景下，计费系统出的账单不仅要对学生准确，还要跟运营商的宽带使用数据对得上。

实际项目中，两边数据对不上是常态。原因可能是：计费系统和运营商的计费周期不一致（一个按自然月，一个按周期月）；或者流量计算方式不同（一个算上下行总和，一个只算下行）。

选型的时候要问清楚：计费系统能不能导出"跟运营商对账专用"的账单格式？能不能按运营商要求的周期和维度重新聚合数据？这两个功能没有的话，后期财务对账会非常痛苦。

学生投诉最多的场景：套餐剩余流量显示不准

学生端最敏感的不是"这个月交了多少钱"，而是"我买的100G套餐，怎么用了3天就提示用完了"。这种投诉，90%不是计费系统算错了，是套餐剩余流量的计算逻辑没有考虑"已用流量 + 当前会话实时流量"。

具体说：学生在下载一个10G的文件，下载过程中查看剩余流量，如果系统只显示"已用流量"，不把"当前会话已经产生的但尚未结算的实时流量"算进去，学生看到的剩余流量就会比实际多。等下载完再刷新，突然少了10G，投诉就来了。

好的计费系统，学生端查询剩余流量时，会实时向认证网关查询"当前活跃会话的实时流量"，加到已用流量里一起计算。这个功能看起来小，实际对减少投诉非常重要。选型的时候用这个场景测一下，能不能做到实时流量查询。

数据库层面也要考虑账单的完整性

计费系统的账单数据存在数据库里，数据库本身的可靠性也影响账单准确度。有的产品用SQLite单文件存储，好处是部署简单，坏处是并发写入性能差，而且一旦文件损坏，所有账单数据全丢。对于用户数超过3000的校园网，建议选支持MySQL或者PostgreSQL的产品。

还有一个经常被忽略的问题：账单数据的备份策略。有的产品默认只保留最近3个月明细，超过自动清理。但教育局审计通常要求网络使用日志和计费记录保留6个月以上。如果产品只保留3个月，审计时拿不出数据，学校要承担责任。选型的时候一定要确认"明细保留策略"能不能改，默认保留多长时间。