每年毕业季，几届学生的上网账号集中离校。这些账号如果留在计费系统里，既占配额又可能继续挂账，时间一长就成了没人认领的幽灵账单。清理不是点一下删除那么简单，要在不停账、可回溯的前提下把人平稳请走。
先区分毕业离校和休学保留
不是所有离校都要清。毕业的是彻底走，休学、留级的还要保留。清理前要从学籍系统拿到准确的离校名单，按状态打标。计费系统只处理标记为毕业离校的批次，避免把还要用网的人误删，这种误删引发的投诉比漏清更麻烦。
清理前先结清再冻结
直接删账号会丢掉余额和欠费记录。正确顺序是先对有余额的账号做退费或转移，对欠费的做催缴或核销，确认账目干净后再冻结。冻结后账号不能上网但明细保留，财务要查某届的历史账随时能调出来。这一步顺序错了，后面补账极难。
批量操作要分批不要一把梭
几千个账号一次性删除，数据库锁表、计费服务卡顿都可能发生。稳妥做法是按学院或者按批次切小，每批几百个，跑完校验再跑下一批。每批出一份处理明细，记下来处理了哪些、哪些因异常跳过。分批虽然慢一点，但出事能定位到具体哪一批。
保留归档比保留账号重要
账号可以删，数据不能丢。离校账号的计费明细应当归档到历史表，至少保留学校规定的年限。归档后前台查不到，但后台按届、按学院能统计。很多学校审计时要看某年某专业的网络费用走势，靠的就是这份归档，不是靠还活着的账号。
通知和留痕要同步做
清理动作最好和学生端的通知联动，比如离校前提醒余额处理。系统侧则要留操作日志，谁在什么时候清了哪批、依据哪份名单。哪天有人拿着旧账号来问，能立刻说清楚当时为什么清、清之前账是不是平的。
提前一个月启动别等毕业当天
清理别堆到离校手续那天。提前一个月从学籍系统拉预离校名单，边走手续边清账号，压力分散。赶在最后一天一把清，系统忙、人更乱，容易错删。
余额处理要有明文办法
离校账号有余额，退还是转下届，学校要有明文规定。计费系统按办法批量执行，不退不转的做核销。办法写清楚，学生来问有依据，财务核销有凭证，不至于各自发挥。
归档要带检索字段
历史明细归档不能只丢进一张大表。按届、按学院、按离校批次建检索字段，审计或统计时一查就出。没有检索的归档等于没归档，真要用时还是翻不出来。
清理后要出一份总账
整批清完，出一份这届的总账：多少人、收了多少、退了多少、免了多少。交给财务和学生处留底。数字摆出来，清理干不干净一目了然，不用事后靠记忆争。
和离校系统打通自动触发
清理最好由离校手续自动触发，学生办完离校，计费侧收到事件就开始冻结流程。手动拉名单总有漏，自动触发才稳。打通离校系统，清理从运动式变成常态化。
保留申诉通道
批量清理偶有错杀，比如延毕的被误标毕业。要留申诉通道，被错清的人能申请恢复，恢复动作留痕。没有申诉，一次误清就是一桩投诉，还查不清当时为什么。
财务核销要同期完成
清理和财务核销同步走，不要账清了财务还挂着。每批清理附带核销说明，财务同期销账。两边同节奏，年底资产清查才对得上。
次年对比看趋势
每年毕业清理的总账留着，隔年一比能看离校规模趋势。趋势对容量规划有用，哪年扩招明年账号压力就大。数据留下来，规划不再拍脑袋。
清理要进迎新闭环
毕业清理和新生开卡是一个闭环的两端。清理完腾出的配额，正好接新生开卡。两端用同一套账号生命周期管理，年初年末都顺。
清理要避开选课高峰。毕业清理和期末选课都挤在学期末，系统压力大。清理排期初或者错峰，别和选课抢资源。错峰是运维常识，两件事撞一起谁都慢。
离校名单要双人复核。批量清理前，学籍名单和计费名单各由一人核对再交叉确认。单人核容易漏延毕、错标，双人复核多一道保险，错清的投诉能少一大半。
余额处理要出凭证。退费或转移每一笔留电子凭证，学生问起来立刻调。凭证链完整，财务审计、学生申诉都对得清，不会各说各话。
冻结后观察一周再删。账号冻结后留一周观察期，期间有人申诉能秒恢复。直接删了再恢复要重建，麻烦得多。观察期是用时间换稳妥。
清理脚本要可重跑。批量清理脚本要幂等，重跑不产生重复操作。哪天发现漏一批，重跑补上不伤已清的。幂等是批量操作的底线。
毕业季清理的本质是给计费系统做年度瘦身。做得干净，系统越跑越轻；做得马虎，幽灵账号越积越多，年底对账就是一本糊涂账。