校园一卡通在高校里几乎是标配：吃饭、洗澡、开门禁、借书，都用这张卡。后来校园网也要收费，很多学校自然就想到把WiFi计费也接进一卡通体系里，一个账号、一张卡、一个管理后台，听起来很顺。
实际落地的时候，这个"顺"字往往变成"坑"字。
对接这件事的技术逻辑其实不复杂：一卡通系统有学生身份信息和账户信息，WiFi计费系统需要知道谁在上网、该从哪个账户扣钱。两个系统之间通过接口交换数据，看起来是标准操作。但标准操作在实际环境中往往遇到标准之外的问题。
一卡通系统的账户逻辑是"预付费"：学生往卡里充钱，花多少扣多少，余额不足就不能刷。一卡通账户里的钱是真实的人民币余额。
WiFi计费系统的账户逻辑有多种可能：可能是预付费（先充值后上网），可能是后付费（先用后结算），可能是包月制（按时长包不涉及单次扣费）。
这两种账户体系对接的时候，问题就来了：学生一卡通账户里剩5块钱，WiFi套餐一个月20块——这5块钱够不够开通WiFi功能？怎么扣？按比例折算天数？还是必须充值到一个最低门槛才能开通？
还有更麻烦的：一卡通账户欠费了，要不要同步停WiFi？WiFi欠费了，一卡通刷卡消费要不要受影响？两个账户的余额要不要统一展示？这些业务规则没有在对接之前谈清楚，实施的时候就只能临时补逻辑，补出来的逻辑往往是漏洞。
一卡通消费是实时发生的：学生刷卡消费，余额立刻扣减，这个体验是秒级的。但如果WiFi计费系统的查询接口响应慢，学生连接WiFi的时候要等好几秒才能确认余额够不够，这个等待时间会引发大量投诉。
更严重的情况是数据不同步导致的双重扣费。学生刚用一卡通充值，WiFi计费系统还没同步完，学生就尝试连接WiFi——系统可能判定余额不足拒绝了请求，但随后数据同步过来才发现其实够用。这种边界情况在并发量大的时候出现的次数不少，处理不好会引起学生对系统的信任危机。
数据同步还有一个维度是学生离校后的账户注销。毕业生离校了，一卡通账户要销户，WiFi计费账号要不要同步注销？如果不同步，毕业生还能用校园网上网，产生费用找谁收？
校园一卡通市场上有好几家主流厂商，各家的接口协议、数据格式、字段定义都不一样。WiFi计费系统这边的厂商也是另一家，两个异构系统之间的对接，没有标准化的中间层就得靠定制开发。
定制开发的坑在于：开发周期往往比预期长，调试过程中频繁遇到边界情况，两个厂商互相推责任说对方接口有问题，最后往往是学校出面协调，但协调的效率很低。
还有一个问题是厂商配合度。很多一卡通厂商对于开放接口给第三方有顾虑，担心数据安全或者竞争风险，接口文档不完整，技术支持响应慢。这种情况在对接谈判阶段往往还没暴露出来，项目启动之后才发现配合度不够，进度延误是常态。
假设学校决定调整WiFi套餐的定价策略，从包月改成包月加超流量两种模式。这种调整如果涉及一卡通账户扣费逻辑的变更，就要同时改一卡通系统和WiFi计费系统两边的接口和业务规则。
改两套系统比改一套系统复杂得多，需要两边的开发人员同时在场、同时测试、同时上线。如果两个系统分属不同的供应商，变更的协调成本就更高。
对接前要问清楚一件事：后续的业务规则调整，是否需要厂商介入才能改，还是计费系统本身提供可视化的业务配置界面，运维人员自己能调整。前者意味着每一次规则变更都要走项目流程，后者才是真正可用的灵活配置能力。
一卡通和WiFi计费对接在技术上可行，在落地上有坑。坑的根源往往不是技术本身，而是对接前对业务规则的梳理不够深入、对两个系统的差异认识不够充分、对后续运维成本估计不足。在决定对接之前，把这两个系统的账户逻辑、数据同步要求、接口标准、变更机制这四件事想清楚，能避掉大部分的坑。
English