|

退货按原价退，用户净赚了 50 块——优惠分摊是个容易忽略的计算题 用户买了 A（100元）、B（120元）、C（80元），合计 300 元，满300减50，实付 250 元。退了 A，退款打了 120 元过去。 账对不上：用户拿回退款 1

集卡稀有卡设了 5% 概率，活动结束超发了几千张 稀有卡概率设了 5%，奖品准备了 500 份，活动预计跑一周。结果上线 2 小时，奖品没了，已集齐用户 12000 人。 5% 听起来很低——但如果有 50 万次抽卡请求，期望出 2.5 万

双11红包雨多发了 2000 个——并发读库存，是经典的定时炸弹 预算 10000 个红包，活动跑了一小时，数据库写了 12073 条发放记录。 代码逻辑看起来没问题： 为什么"看起来没问题"的代码会超发 --- 并发下这段逻辑会炸 100

分享裂变背后：为什么光验证手机号根本拦不住羊毛党 一个账号领了 37 份礼包 活动第三天，一个账号领了37份新人礼包。翻日志发现：这个用户注册了37个账号，每个都用真实手机号+验证码注册，每个账号都领了奖励。 开发说：我们有手机号验证码，怎

签到写进去了，积分却没到账：DB 和 MQ 不在同一个事务 签到记录有，积分没有 日志里能看到签到记录，页面也返回了"签到成功"，但积分表里什么都没有。 问题出在 MQ 那一步：签到写 DB 成功，MQ 消息发失败，异常被吞掉了，流程就这么

预售尾款超时没释放库存——定时任务扫表是个坑 扫表定时任务，数据一多就撑不住 预售场景：用户付了定金，7天内补尾款，否则自动释放库存。 第一反应往往是写个定时任务，每小时扫一遍 presaleorder 表，超时的就释放。数据量小的时候这样

拼团差一人，两个人同时付款，结果团里来了6个人 你以为你会做 拼团需求来了，你觉得很简单： 1. 查一下团里还有几个空位 2. 有空位就把这个人加进去 3. 人数满了就成团 代码写出来大概长这样： 5人团，已经4人，差1人。两个用户几乎同时

同一张券被核销了两次，你才意识到状态机有多重要 一张券被核销了两次 移动端弱网环境下，核销接口在 100ms 内被调用了两次（客户端自动重试），两次都返回成功，券被消耗了两张的价值，但库里只扣了一次用量。 接口没有 bug，问题出在缺少两样

接到秒杀需求，你先别急着写代码 秒杀场景有一个核心矛盾：用户点击抢购的瞬间，并发请求可能几百上千个同时到达，但库存就那么几件。 在写任何一行代码之前，得先想清楚一件事：库存扣减，放在哪一步？ 这个问题没有"显然正确"的答案，下单时扣和付款时

抽奖接口被连点两次，奖发了两份——幂等不是前端的事 用户连点了两次，两个请求时间差 200 毫秒先后到达后端，两次都成功，奖品发了两份。 这不算罕见。网络抖动重试、页面刷新、用两个标签页同时操作——这些场景前端拦不住，最终都会变成两条独立的