那个bug至今想起来都让我后背发凉。测试支付页面，经典用户点“确认付款”之后，测试弹窗提示“支付成功”，经典订单状态却依然显示“待支付”。测试用户以为没付成功，经典又点了一次。测试第二次真的经典扣款了。第一次的测试钱呢？被系统吞了，卡在中间状态，经典既没进商户账户，测试也没退回用户银行卡。经典

这是测试典型的分布式事务问题。支付服务和订单服务各自维护数据库，经典通过消息队列异步通信。测试用户点击确认，支付服务先扣款，然后发消息通知订单服务更新状态。问题出在消息发送失败——支付服务扣款成功，但MQ连接超时，消息没发出去。订单服务等不到通知，状态不变。用户看到的就是“付了钱但订单没变”。

更操蛋的是，支付服务有重试机制。用户第二次点击时，支付服务又扣了一笔。两笔扣款，一笔有对应消息，一笔没有。没消息的那笔成了孤儿数据。财务对账时发现差额，客服被用户骂得狗血淋头。

修复方案不复杂。支付服务扣款和发消息必须在一个本地事务里，用本地消息表记录待发送消息，后台任务轮询补发。或者引入TCC模式，Try阶段冻结金额，Confirm阶段真正扣款，Cancel阶段解冻。但当时团队赶进度，谁也没想到MQ会超时。

另一个经典bug跟缓存有关。商品详情页，价格显示错误。用户看到的是99元，加入购物车变成199元。缓存里存的是旧价格，数据库已经更新了。缓存过期时间设了24小时，运营改价之后没手动刷新缓存，用户看到的一直是昨天的价格。

这种问题在秒杀场景更致命。库存缓存和数据库不一致，用户下单时显示有货，支付时提示库存不足。或者反过来，明明没货了，缓存里还有，用户下单成功但发不了货。我们后来加了缓存更新策略，改价时主动删除缓存，读的时候如果缓存失效就查数据库并回填。但依然有并发问题——两个请求同时发现缓存失效，都去查数据库，都回填，顺序可能颠倒。

最隐蔽的bug是时区问题。服务器用UTC时间，数据库存UTC，前端展示用本地时间。某次活动，开始时间设的是“2024-03-15 00:00:00”，运营以为是北京时间。结果服务器按UTC解析，活动提前8小时开始了。用户半夜收到推送，一脸懵逼。修复方式很简单，所有时间字段统一用时间戳，前端根据用户时区格式化。但当时没人意识到这个坑，测试环境用的是本地时间，没复现出来。

测试这些bug让我明白一件事：代码逻辑正确不代表系统正确。网络会超时，缓存会过期，时区会错乱，用户会重复点击。测试用例要覆盖异常路径，不能只测happy path。支付、库存、时间——这三个领域出bug的概率最高，也最致命。每次上线前，我都会盯着这几个模块多看几遍。不是不信任代码，是不信任这个复杂的世界。