校园WiFi计费系统上线前做压力测试，很多学校会做一个"模拟用户拨测"就觉得够了。但实际上，计费系统在高并发场景下会暴露的问题，远不止"能同时认证多少用户"这么简单。这篇文章不从测试工具层面谈，而是从脉冲并发、资源竞争、异常恢复三个角度，把"压测到底测什么"拆开说。

最基础的压测是：同时有多少个用户能成功通过认证？这个指标厂商一般都会给，但实际上线时，并发峰值往往出现在特定时间段：晚上十点下晚自习，宿舍区同时有人插网线、连WiFi、打开认证页。这种"脉冲式并发"比平稳并发更难处理，因为它会触发认证服务器的请求队列堆积，导致部分用户超时失败，而失败又会触发重试，进一步恶化拥塞。真正有效的压测，不是"同时发起多少请求"，而是"在多长时间内，系统能把队列消化完"。如果消化时间超过用户侧的超时阈值，用户体验就是"认证失败"，哪怕后台后来把请求处理完了。

第二个容易被忽视的压测点：DHCP 分配速度。很多校园WiFi计费系统是和 DHCP 联动的，用户认证通过后，要拿到 IP 才能真正上网。如果 DHCP 服务器的响应速度跟不上认证通过的速度，用户侧的表现就是：认证成功了，但网页打开很慢，或者拿不到 IP。这个瓶颈不在计费系统本身，但用户一定会认为是"你们计费系统不行"。压测时必须把 DHCP 也拉进来一起压，而不是只压计费系统的认证接口。很多项目在这里翻车：计费系统认证性能很好，但 DHCP 是交换机自带的，性能一般，结果整体体验被 DHCP 拖住。

第三个点：数据库写入瓶颈。每个用户上线，计费系统都要写一条在线记录；用户下线，要更新流量计费信息。如果是在线用户很多、且大家都在刷视频，计费系统后台数据库的写入压力会非常大。压测时不能只测"认证那一瞬间"，还要测"持续在线、持续计费"的状态。很多系统认证能通过，但跑两天后数据库慢查询堆积，整个系统变卡。更复杂的情况是：多校区共用一套计费系统，数据库写入是集中式的，某个校区的流量高峰会影响其他校区的性能。这种"跨校区干扰"在压测方案里很少被考虑到。

还有一个现实问题：多运营商代拨场景。很多校园WiFi计费系统后面接了多家运营商，用户可以选择走哪家出口。这种架构下，压测不能只测"计费系统 → 运营商"这一条链路，还要测"多家运营商同时代拨时的资源竞争"。有的运营商侧响应慢，会拖住计费系统的上线流程，导致其他用户也跟着卡。更麻烦的是：如果某家运营商的代拨接口挂了，计费系统能不能快速切换到其他运营商，还是会让用户卡在"选择运营商"这一步？这些故障切换场景，比"能同时认证多少用户"更有实际价值。

最后说一个容易被当成"过度测试"的点：异常断网后的重认证风暴。比如宿舍区交换机故障，恢复后几百个学生同时重新连网，计费系统能不能在短时间内容忍大量重认证请求？这个问题在实验室环境很难完整模拟，但现实里几乎每个学期都会发生。压测方案里如果完全没有考虑这种"恢复性并发"，上线后就很可能会在这种时刻掉链子。一个很实用的做法是：压测时专门设计一个"断网恢复"场景，看系统能不能在五分钟内把重认证请求消化完，而不是让学生反复重试、投诉电话被打爆。

补充一个很多项目忽略的点：计费策略的复杂度对性能的影响。很多系统在测试时用的计费策略很简单（比如"包月不限流量"），但实际上线后，计费策略会有很多分层：不同学院不同价格、不同时间段不同费率、流量上限和速率限制组合。这些复杂策略会让每次认证和计费请求的处理时间变长。压测时不能用"最简策略"，而要用"最复杂策略"去压，否则上线后就是：认证都能过，但一满负荷就卡。