一张会员卡，卡管背后至少牵扯三张表：会员信息、理系等级规则、卡管消费流水。理系少一张，卡管系统跑两天就乱。理系我见过一家连锁水果店，卡管开业三个月换了四套收银工具，理系最后卡在同一个坑里——会员储值余额和实际应收对不上，卡管差了七百多块。理系老板说，卡管每次对账都像在破案。理系

问题出在设计思路上。卡管很多人把会员卡当成一个“打折凭证”，理系开发时只存个卡号和折扣率，卡管消费时减掉对应金额就完事。这种做法在单店、低频消费的场景下勉强能跑，一旦涉及储值、积分、跨店核销，立刻塌方。

核心不是卡，是账户

会员卡的本质是一个预付费账户。用户充进来的钱是负债，不是收入。这个会计原则决定了系统怎么记流水。每笔消费必须拆成两部分：扣减余额和确认收入。我见过一个技术团队用一张表记所有变动，充值记正数、消费记负数，月底拉个sum就当报表。结果退款和赠送金混在一起，根本分不清哪些是用户真金白银充的，哪些是活动送的。

正确的做法是分账户。本金账户、赠送账户、积分账户各自独立。消费时按比例扣减，退款时只退本金部分。这不是过度设计，是法律要求。《单用途商业预付卡管理办法》写得很清楚，预收资金和赠送金额必须分开管理。

等级规则别写死在代码里

一家美发店老板跟我吐槽，他想把银卡门槛从累计消费2000降到1500，开发说改不了，规则硬编码在Java类里。这种系统上线即报废。等级规则应该是配置项：升级条件、保级周期、降级逻辑，全部存数据库。运营人员自己在后台改，不需要发版。

另一个细节是等级重算的触发时机。很多系统在用户消费后立刻判断是否升级，这没问题。但降级呢？通常是每年1月1日批量跑。如果用户12月31日消费了一笔，1月1日凌晨系统还没跑完，他可能被误降。解决方式很简单：降级任务放在凌晨3点执行，且只处理保级周期已过的账户。

并发扣款是事故高发区

两个收银台同时给一个会员结账，余额只够一笔。没有锁的话，两笔都成功，余额变负数。数据库层面用乐观锁或者select for update都行，关键是开发时得想到这个场景。我见过一个系统用Redis做缓存扣减，异步落库，结果Redis挂了重启，丢了一天的消费记录。缓存可以加，但数据库必须是最终真相。

还有积分。积分兑换和积分获取如果不在同一个事务里，用户可能用A店的积分在B店兑换，B店查到的余额是旧的。分布式事务太重，简单做法是积分变动走消息队列，但兑换前必须回源查一次主库。牺牲一点性能，换数据准确。

对账功能不能省

再好的系统也会出bug。关键是出了bug能快速定位。每天凌晨跑一次对账：会员余额总和 vs 充值总额减消费总额减退款总额。差额超过阈值就告警。那个水果店老板后来换了系统，第一件事就是让我加对账报表。他说，我不怕出错，怕的是错了不知道错在哪。

会员卡管理系统不复杂，但细节多。账户分离、规则配置化、并发控制、每日对账，这四件事做到位，基本不会出大乱子。剩下的就是UI好不好看、导购会不会用了。