国内高校的校园WiFi建设有一个很有中国特色的现象：三家运营商各自投资、各自布网，最后在同一个校园里共存。对学生来说意味着可以选择运营商套餐，对学校信息化部门来说意味着要协调三套完全不同的认证和计费体系。校园网WiFi网络计费系统在这种多运营商环境下的对接，是整个项目里技术含量最高、也最容易扯皮的部分。

先搞清楚每家运营商要什么

在动手写对接方案之前，有一个问题必须先搞清楚：三家运营商对"认证"这件事的定义不完全一样。移动的网络部门认为认证应该是EAP-SIM/AKA，直接走SIM卡，用户不需要输密码，手机自动认证。电信更习惯Web Portal+短信验证码的模式，跟他们手机营业厅的认证逻辑一致。联通的情况比较复杂，不同省份的策略不一样，有些地区要求走RADIUS代理，有些又支持Web Portal。

这意味着你的计费系统不是一个"统一认证入口"就能解决的。它更像是一个翻译层：学生打开浏览器看到的是同一个Portal页面，但他选择"移动"之后，后台要走移动的认证协议；选择"电信"，走电信的流程。如果系统能把这种协议差异封装在配置层而不是代码层，后面的维护成本会低很多。

RADIUS是基础，但不能只靠RADIUS

大部分校园网WiFi网络计费系统跟运营商之间的技术桥梁是RADIUS协议。学校侧架一台RADIUS服务器（或者直接用计费系统内置的RADIUS模块），运营商侧开放他们的RADIUS代理，两者之间通过共享密钥建立信任，然后做认证请求转发。

这套方案在技术上是成立的，但实际操作中有几个坑点。第一个是超时时间。运营商的RADIUS代理通常经过好几层网络跳转，响应时间可能比你想象的慢。如果你把超时设成默认的5秒，学生会频繁看到"认证超时"的提示，然后重试，然后又超时，体验非常差。建议至少设到15秒，并配合"认证中请稍候"的友好提示。

第二个是属性映射。不同运营商的RADIUS服务器返回的属性名称和值域不一样。移动返回的用户标识可能是MSISDN（手机号），电信可能用Account-Name，联通可能两者都有。你的计费系统拿到这些属性之后，要能正确映射到统一的本校用户标识体系里，否则后面做日志查询、账务对账的时候会一团糟。

Portal页面的设计有讲究

学生第一次连接校园WiFi时看到的那个认证页面（Portal），是多运营商对接里用户体验的核心环节。这个页面要解决几个问题：让用户知道有哪些运营商可选、展示不同运营商的套餐信息、在用户选择后跳转到对应的认证流程。

我见过做得比较差的Portal，三个运营商的入口堆在一个页面上，每个下面放一段运营商自己写的宣传语，字体大小都不一样，手机上根本看不清。学生随便点了一个，认证失败了也不知道是选错了还是密码错了。好的Portal应该是干净的：一个大标题，下面三个选项卡或者下拉框，用户选一个运营商，下面立刻显示这个运营商的认证表单——手机号、密码或者验证码——没有多余信息干扰。

还有一个细节：Portal页面要能记住用户上次的选择。学生一旦选了某个运营商并成功认证，下次打开Portal的时候应该默认选中上次的运营商，而不是每次都让他重新选。这不是技术难题，但很多项目里没人提这个需求，导致学生体验很差。

批量开户和销户是刚需

每年九月开学季，几千名新生同时报到。如果每个新生都要自己去Portal页面上注册、绑定运营商、完成认证，信息化部门的电话能被打爆。一套靠谱的校园网WiFi网络计费系统应该支持跟学校教务系统对接，批量导入新生数据，预开通账号。

批量开户不仅仅是"往数据库里插记录"这么简单。新生开户的时候要同时做这几件事：创建校园网账号、开通对应的计费策略（免费还是限额）、跟运营商侧同步用户数据（有些运营商要求学校在开学前一周把新生手机号列表发过去，他们在自己的认证系统里预注册）、分配初始密码或触发短信告知。这一连串动作如果手动做，一个人处理一个学生至少五分钟，五千个新生就是四百多个工时。

毕业季的批量销户同样重要。但销户比开户复杂——有些毕业生可能还留在学校读研，他的本科账号不应该被直接删除，而应该暂停或者降级。这需要计费系统能识别用户的学籍状态变化，跟教务系统的数据保持同步。

对账问题不能等出事了再处理

多运营商环境下的账务对账是很多学校后期最头疼的事。运营商说"这个月你校园里通过我认证的用户有8000人，按照协议你应该付我XX钱"，学校说"我这边只统计到6500人"。差出来的1500人去哪了？可能是运营商的统计口径包含了重复认证（一个人一天认证了五次算五次还是一次？），可能是学校侧RADIUS日志有丢失，也可能是两个系统的时间戳对不上。

避免这种扯皮的方法是在系统上线的时候就约定清楚：统计口径是什么（按去重用户数还是按认证次数）、统计周期是什么（自然月还是计费月）、对账数据的传输格式和校验机制是什么。最好能做到每天自动跑一次对账脚本，差异超过5%就自动报警，而不是等到月底对账的时候才发现数字对不上。

落地建议

如果你正在做或者即将做一个多运营商校园WiFi项目，我的建议是：先把三家运营商的技术对接人拉到一起，开一个技术方案碰头会，把认证协议、RADIUS属性、Portal跳转逻辑、对账流程这些细节全部过一遍，形成书面确认。不要相信"我们这边支持标准RADIUS"这种笼统说法——"标准"两个字在每家运营商那里可能有不同的含义。把这些分歧在项目启动阶段就暴露出来，比在上线之后打补丁强一百倍。