写代码前没理清这三大逻辑？90% Bug由此而生

　　掘金上看见个标题《写代码前没理清这三大逻辑？90% Bug由此而生》，点开看第一段还在讲“面向对象的三要素”，我直接切出窗口，第三杯咖啡冷在手边，奶泡已经塌成一圈灰褐色。不是气，是后怕——三个月前那晚，监控大屏的绿光扫过我眼角，像手术灯下没擦干净的血迹。

　　我们跟开发在钉钉群吵到凌晨一点十七分，王工发了个“？”截图，是某库某表的 update 语句，where 条件里嵌了子查询，又套了个 ifnull。我说这不对，他说“跑通了啊”。我原以为他是在怼我，结果十分钟后他撤回消息，重发一个 commit 记录，里面改了三处：主键索引字段名、触发器的时序判断、还有一个被注释掉的事务回滚标记——他压根没看到自己漏掉了幂等校验的分支出口。这个我敢打包票，因为当时我翻了七次 git blame，commit 时间戳和 Jenkins 构建日志对得上，十八秒误差都没。

文章配图，仅供参考

　　第一个是状态流转逻辑。不是状态机那套虚的，是“用户提交订单→库存扣减→履约分配→发票生成”这条链路上，每个节点对中间态的容忍度。比如履约分配失败后，订单能不能回退？能，但必须退回“待支付”还是“已支付”？这差一个枚举值，但上线后发现退错导致重复扣款——不是数据一致性问题，是状态定义本身在 PR 评审时就被三个人理解成三个版本，没人拍板。当时会议室空调坏了，刘婷一边擦汗一边把白板擦成灰色，擦完才想起还没画完整闭环。

　　第二个是并发约束逻辑。不是加不加锁的问题，是你根本没想清楚哪个操作要互斥、哪个可以放行、哪个压根不该进并发队列。我们上周复盘，发现某接口在 QPS 刚破三百时开始吐 500，日志里全是乐观锁失败——可那张表的 version 字段压根没出现在 UPDATE SET 里，UPDATE 语句是用 MyBatis Plus 自动生成的，@Version 注解写在实体类字段上，但 XML 里手写了 SQL，覆盖了默认逻辑。这种 bug 查三天，最后改一行 XML 收工。你说它难吗？不难。你说它该发生吗？它就不该出现。它出现是因为写代码前，没人对着数据库连接池的配置数、业务请求平均耗时、GC 停顿时间这三样东西，推算出并发安全临界点。纯靠感觉。感觉说“应该没问题”，结果有问题。

　　第三个是数据生命周期逻辑。你写的那行 INSERT，到底什么时候被 DELETE？DELETE 是同步还是异步？异步的话，延迟多久？会不会和下游的定时任务产生竞态？上次恢复演练花了三百七十二秒，不是慢，是卡在某个归档脚本死等一个永远不会落库的脏标记。后来查出来，标记生成在 Kafka 消费端，而消费端上游有个 retryQueue 堆积了两天的数据，堆满后自动丢弃……这跟代码无关，但你没理清这三层，代码就活在假象里。

　　说到Kafka，其实我不太信 topic 分区数配比那套话术。上周六下午三点四十四分，运维拉我进小群，说消费延时突增，问我是不是改了反序列化逻辑。我没改。但我记得那天中午，测试环境执行计划里有一条 SQL，强制走了全表扫描，原因是我临时删了复合索引的一个字段——为了测一个极低概率的空值场景。这事跟 Kafka 没关系，但它让我想起凌晨那会儿，王工撤回消息前，发的第二张图里，有个字段名拼错了两个字母，叫 user_stauts。我盯着看了八秒，没戳穿，因为我自己昨天也写错过一次，也是 statuses。人总在这类地方失守。

　　所以我说优胜劣汰站得住，不是因为有统计，是因为活下来的代码，都踩过这三坑里的至少两坑。不是靠文档，不是靠规范，是靠被线上告警扇过耳光，被业务方打电话骂醒，被运维甩来一串 GC log 和堆转储文件——然后你坐那儿，一边喝冷掉的咖啡，一边把那三个逻辑拆开，揉碎，拿生产日志对，拿 binlog 流对，拿 redis 缓存穿透路径对。对不上？那就删掉重来。不是重写，是回到白板前，先把状态流转箭头画直，把并发临界点标红，把数据从进库到离库的时间轴写在便签纸上，贴在显示器边框上，歪着，皱着，但不能撕。

　　我现在在整理一份轻量级 check list，就一页纸，不走流程，不进 Jira，只放飞书文档末尾，谁提 MR 前自己打勾。第一条：“状态跳变是否全部覆盖？包括失败、超时、补偿。” 第二条空着，我还没想好怎么写得不废话。先这么挂着吧。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!