|

多设备登录——踢下线这件事，比想象中难做 手机 A 上登录着账号，在手机 B 上重新登录（同一账号），按照产品规则，手机 A 应该被踢下线。 手机 A 现在是什么状态？ 如果是用户刚好在 A 上改了收货地址，改完点保存，请求打到服务器——T

微信换绑了手机号，原来的账号找不回来了 用户来客服说：之前用微信登录了 App，现在换了手机号，微信也重新绑定了新号，但进 App 之后账号里什么都没有——是个全新的账号。 问题不在微信，在平台侧的账号设计。 --- 账号、身份、登录方式是

短信账单上多了 2000 块，被人刷验证码了 运营发现短信费用突然多了一大笔，排查后发现：有人写了个脚本，对着注册接口循环请求，每次填不同的手机号（或者同一个号频繁请求），批量触发了几千条验证码短信。 短信按条收费，一毛到几毛不等。一个没有

同一个手机号，注册出了两个账号 排查日志发现：同一个手机号，在 300ms 内发来了两个注册请求（网络抖动，客户端自动重试），两个都通过了"手机号是否已注册"的校验，两个都成功插入了 user 表。 数据库里，同一个手机号对应了两条记录。

部分发货：三个包裹签收了两个，整单算完成了吗 实物商品拆单发货是常态——仓库不同、供应商不同、商品重量限制……一笔订单三个包裹，用户陆续签收。 问题来了：签收了两个，第三个还在途，整单状态要写什么？ --- 整单状态不等于子单状态的简单映射

运营降价了，用户来投诉"为什么我的订单还是原价" 运营把一款商品从 299 降到 199，价格改了之后，已经下单未支付的订单里显示的还是 299。 用户来问：现在 199，为什么我付 299？ --- 价格是下单时刻的快照 这其实不是 bu

拆单之后，用户问：我的订单到底是什么状态 一笔订单拆成三个子单，第一个已发货、第二个已签收、第三个因为仓库缺货还在待发货——用户在 App 上看到的父订单状态是什么？ 你以为这个问题很简单：把三个子单状态汇总一下，谁最落后就显示谁。 但"谁

订单状态机——"已完成"的订单，怎么变成"已取消"的 客服来反馈：有用户的订单已经确认收货了，系统里显示"已取消"。 排查发现：运营侧的一个批量脚本，扫描了"超过 30 天未操作"的订单执行取消，没有判断当前状态，直接执行了 UPDATE

库存扣减时机这道题，答案不是技术给的 下单时扣库存还是付款时扣库存——这个问题的答案不取决于技术选型，取决于你的商品形态和业务对超卖的容忍度。 --- 三种商品，三种答案 虚拟商品（充值卡、游戏道具、电子书）：没有物理库存限制，下单即视为"

双击了下单按钮，收到两条扣款短信 用户来投诉：买了一件商品，银行卡被扣了两笔钱，订单系统里也出现了两条一模一样的记录。 前端按钮有 loading 状态，点完就禁用了。但这次是网络抖动，第一个请求超时，浏览器自动重发了一次，两个请求都到了后