学校无线计费最怕的时间段，是晚上宿舍区和白天考试周。几千人同时在线，账单偶尔会出现对不上的情况：学生说没用却扣了，或者用了却没记。这种账算错，不一定是系统坏了，往往是高并发下的边界没处理好。理解它为什么错，比急着换系统更有用。
并发不是人数，是同时发生的动作
很多人以为并发就是在线人数，其实计费的并发压力来自同时发生的计费事件：登录、心跳、用量上报、超时断连。晚高峰这几类动作在同一秒里成百上千地砸过来，任何一环处理慢了就会堆积。我们见过系统平时好好的，一到晚高峰就出现用量回写延迟，导致账单落后实际几小时。理解并发看动作不看人头，才找对方向。
最常见的错：用量回写丢了
计费系统一般在校端记录实时用量，再定时回写数据库。高并发时，如果回写队列满了或者超时，某段用量可能没写进去，学生实际用了却没计费，或者反过来重复写。我们处理过一次，晚高峰丢了一小批回写，第二天对账发现几十条记录对不上。这种错不致命，但积累起来就是信任危机。队列和重试机制必须提前压测。
会话超时和计费周期叠加的坑
学生连着不动，系统按策略会踢掉闲置会话。但如果会话超时的时间和计费周期结算时间撞在一起，可能出现一段用量既算在这一周期又算在下一周期，或者两段都没算。我们建议把超时策略和结算时间错开，别让两个时间边界重叠。这种边界场景平时测不出来，只有高峰期才暴露，所以压测要专门造这类叠加。
时钟不同步会悄悄毁掉对账
计费系统往往有多台服务器，认证、计费、数据库可能各跑各的。如果它们之间时钟没对齐，一条用量记录的时间戳会前后矛盾，对账时怎么都对不上。我们碰到过最隐蔽的一次，是两台机器差了三秒，月底几千条记录时间戳错乱，财务查了两天。时间同步看着小，其实是账算对的前提。
重复计费怎么发生的
学生频繁切换接入点，每次切换可能触发一次计费事件。如果系统没做好去重，一次实际用量被记成两三次，学生就觉得被多扣了。我们处理过宿舍区学生走动多导致重复计费的案例，最后是在计费事件上加了会话合并才解决。重复计费是高频场景下的典型病，设计时就得把漫游和去重想进去。
为什么压测要按真实峰值的倍数做
很多学校压测只做到日常在线人数，上线后晚高峰一翻倍就出问题。我们做项目要求压测到真实峰值的二到三倍，专门打并发计费事件。因为日常平稳，问题藏得住，只有峰值才把薄弱环节逼出来。压测不是走形式，是把高峰期会犯的错提前在实验室里犯一遍。
账算错了先别怪系统
出现对账差异，学校第一反应常是系统不行。但我们经验里，一半以上差异来自配置：策略叠加、时间边界、接口丢数据。先拉日志看差异集中在哪类事件、哪个时间段，往往能定位到具体配置。我们建议学校建一个差异分类表，新出现的错归到已知类还是未知类，处理起来有章法，不至于每次都从头查。
给我们的启示
高峰期账算错，本质是设计阶段没把并发当回事。我们做方案会把并发场景单列，压测、队列、重试、时钟同步、去重逐条落实，上线后还要盯第一个晚高峰的账单。把错的可能性提前堵住，比上线后到处救火强。计费系统稳不稳，看高峰不看平时。
差异要分已知和未知两类
对账差异天天有，关键是分类。已知类比如月末结算的尾差，系统能解释；未知类比如突然多出的重复计费，必须查。我们帮学校建过一张差异分类表，新出现的错先归已知还是未知，处理路径完全不同。分类做细，财务不慌，运维也有章法，不会每次都从头查起。
第一个晚高峰是验收日
不管压测做得多好，真实第一个晚高峰才是真正的验收。我们上线后那晚一定有人盯着账单，看计费成功率、差异笔数、回写延迟这三项。哪项异常立刻介入，不等第二天。把上线后的第一个高峰当成考试，考过了才敢说系统稳。这个习惯帮我们拦下过好几次隐患。
并发问题要写进运维手册
高峰期账算错的坑，不能只处理一次就忘。我们建议把这类问题的定位和处置写进运维手册，下次晚高峰前有人照着查。知识沉淀下来，系统才越用越稳，不依赖某个人记性好。
把并发当成长期指标盯
并发能力不是上线测一次就完，学生规模年年变，晚高峰压力也会变。我们建议把并发相关指标列为长期监控项，每年开学前做一次压测回顾。把并发当成长线指标，系统才不会被规模增长悄悄拖垮。