宿舍WiFi网络计费系统单独建一套账号，是项目里最容易被低估的麻烦。我们见过不少学校，计费系统自己发账号、自己管密码，结果学生要记两套密码，忘记一个就打客服。更糟的是毕业离校时只在学校统一身份认证里销了号，计费系统里的账号还活着，继续产生账单或者被人冒用。所以凡是新建的宿舍计费系统，第一件事就该想清楚：它能不能直接吃学校的统一身份认证，而不是另起炉灶。

先确认学校统一身份认证是什么协议

动手对接之前，得先搞清楚学校那套统一身份认证到底开放了什么接口。有的学校用的是标准的轻量目录访问协议，有的跑的是基于声明的单点登录，还有的干脆是自家开发的接口，文档都未必齐全。计费系统要接进去，至少要能拿到三样东西：学生的唯一学号、姓名、所属院系或楼栋。拿不到院系和楼栋，后面按楼栋出账单、按学院分摊费用就做不了。所以对接的第一步不是写代码，而是把认证系统能给你的字段清单要过来，逐条核对。

账号同步方向要想好

对接最容易踩的坑是同步方向。有的方案让计费系统定时去认证系统拉全量账号，听着省事，但一万多学生每次全量拉，网络和数据库压力都不小，而且认证系统一旦临时维护，计费这边就同步失败。更稳的做法是事件驱动：学生注册、复学、退学时，认证系统推一条消息过来，计费系统只增量更新。我们一般建议学校把这套推送机制写进对接规范里，而不是靠定时任务兜底。方向定错了，后面每次迎新都是一次小型事故。

密码和改密流程要归口

学生改密码这件事，必须在统一身份认证那里完成，计费系统不存密码、也不提供改密入口。这一点要写死。我们见过反面案例：计费系统自己留了一份密码副本，结果被拖库，学生抱怨学校泄露信息。正确的做法是计费系统只做认证转发，验证动作交给学校统一身份认证，验证通过就拿到一个带时效的凭证。学生忘记密码，引导他去学校统一身份认证的页面改，计费这边不碰明文。这样责任边界清楚，安全审计也好做。

计费账号和上网账号要合一

还有一个常常被忽略的点：学生用来上网的账号和用来充值的计费账号，最好是同一个。如果上网用学号、充值又得另注册一个手机号账号，学生很容易搞混，客服量直接翻倍。比较好的实践是，计费系统直接以学号作为主账号，充值绑定微信或支付宝做支付渠道，但不另建一套身份。这样一来，学生在 认证页 页面输入学号密码就能上网，余额和账单都挂在学号下，查账、退费、转移都顺。

离校销号要闭环

毕业和退学是检验对接是否到位的关键时刻。理想状态下，学校统一身份认证里学生状态一变，计费系统当天就收到推送，自动停掉上网权限、冻结余额、生成待结算清单。但实际项目里，常常因为推送延迟或者字段缺失，出现人走了号还在、或者余额没人认领的情况。我们建议在上线前就拿一批真实的离校数据做一次演练，确认从状态变更到计费侧停权、冻结、出清单这条链是通的。闭环做不好，每年毕业季都是网络中心的噩梦。

对接失败要有降级方案

再好的对接也得防一手认证系统宕机。我们一般会要求计费系统保留一个本地缓存的凭证，在统一身份认证短暂不可用时，让学生还能正常上几分钟网，而不是整片宿舍瞬间断网。这个缓存有时效，认证一恢复就重新校验。降级不是为了绕过认证，而是为了避免单点故障把整栋楼拖下水。这一点写进方案，运维老师夜里能少接很多电话。

对接文档要学校自己留底

对接做完了，接口文档、字段定义、推送格式这些，必须由学校自己留一份底，不能只存在厂商脑子里。我们见过厂商人员一换，学校的对接细节没人说得清，下次升级全得重来。文档归学校，是避免被绑死的关键，也是后续自己排查问题的依据。

先在测试环境跑通再上生产

正式上线前，一定要在测试环境用一批仿真的账号和楼栋把整条对接链跑一遍，别直接在生产上试。测试环境能暴露字段缺失、推送延迟、编码乱码这类问题，而且不影响真实学生。我们习惯把测试通过作为上线前置条件写进实施计划，宁可多花两天测试，也不要拿几千学生的真实用网去赌对接没问题。