学校WiFi计费系统上线头一个月，是最容易出状况的阶段。设备是新的，规则是新的，师生是第一次用，任何一环衔接不好都会暴露。我们参与和旁观过不少上线项目，发现故障类型高度重合。提前知道这些常见坑，能少熬很多夜。这篇把上线初期最高频的几类故障列出来。

账号同步延迟导致大面积登不上

最常见的一类。计费系统和统一身份认证对接后，新生数据往往不是一次性同步过来的，而是分批、有延迟。结果学生拿着学工号去认证，系统里还没有这个账号，全部被拒。上线第一天尤其明显。规避办法是提前做一次全量同步，并且在认证失败时返回明确提示"账号未开通，请联系管理员"，而不是笼统的"认证失败"。我们建议上线前三天就跑全量同步，上线后再转增量，别等学生堵在门口才发现问题。

Portal页打不开或跳转异常

学生连上WiFi，应该自动弹出认证页，但上线初期常出现弹不出、或者弹了但提交后不跳转。原因可能是认证服务器的重定向配置错了，也可能是某些手机系统限制了 captive portal 探测。这类问题排查起来很碎，建议上线前用主流机型（iOS、安卓不同版本）实测一遍弹页和跳转。我们见过一所学校，iPhone弹页正常，某国产安卓机型死活不弹，最后发现是系统浏览器对 captive 检测做了改动，只能引导学生在浏览器手动输地址。这种兼容性要提前摸清。

计费错乱引发投诉潮

刚上线时计费规则如果没调好，可能出现重复扣费、套餐没生效却按流量计、免费额度没给到。这类故障影响最直接，学生反应最激烈。规避办法是上线前用测试账号走完整流程：注册、充值、使用、扣费、查询、退款，每一步对账。我们强烈建议先小范围灰度，比如挑一个宿舍楼试运行一周，确认账单无误再全校铺开。直接全校上线，一旦计费错乱就是全校投诉。

认证服务器被并发打垮

开学、重大考试、晚上高峰，都是认证并发的顶点。上线初期服务器容量如果按平时估，很容易在顶点时刻响应变慢甚至挂掉。这类故障的特点是"平时好好的，一忙就崩"，最难排查。建议上线前做压力测试，按全校在线的峰值并发压一遍认证和计费接口。我们见过认证服务器和计费数据库部署在同一台机器上，高峰时数据库把CPU吃满，认证也跟着瘫。资源隔离和容量预留，上线前必须确认。

运维接口没人接，出问题找不到人

系统上线热闹一阵，之后谁来盯监控、谁来处理工单，常常没落实。结果小故障拖成大故障，学生报修石沉大海。上线初期就要把运维责任落到具体岗位，信息化部门值班、厂商远程支持、宿舍管理员怎么上报，串成一条线。我们建议上线头一个月厂商驻场或每天巡检，把常见问题和处理手册交给学校，别等厂商撤了才发现学校这边接不住。

上线初期的故障，大多不是技术多难，而是准备工作没做细。全量同步提前跑、弹页多机型实测、计费先灰度、容量按峰值压、运维责任落到人，这几件事在切换前做完，系统就能平稳度过最危险的头一个月。

准备一份上线检查清单

我们习惯在切换前拉一张清单，逐条打勾：账号全量同步完成、主流机型弹页测试通过、计费规则灰度验证、服务器压测达标、监控告警接入、运维联系人确认、回退方案就绪。这张三页纸的东西，能把八成以上的低级故障挡在门外。很多学校上线乱，是因为没人把"该做啥"写下来，全靠现场发挥。清单不复杂，但能把责任落到纸面上，谁漏了谁知道。

给学生留一个报障入口

再周全的准备也可能有漏网之鱼。上线初期要给学生一个清楚的报障渠道，比如宿舍管理员、学校IT值班、或者一个企业微信报修入口，并且承诺响应时间。我们建议认证失败页上直接放一个"连不上点这里反馈"的按钮，学生一键提交，管理员马上能看到。这比学生发朋友圈吐槽再被校领导转过来，处理成本低得多。报障入口本身也是你发现故障的传感器。