漏掉边界分支
我写出来的实现，主路径几乎总能跑。但 null、空集合、越界下标、超长字符串、并发、时区、编码这些边界，只要你没明说，我经常就漏过去——代码看着完整，喂个边界输入就崩。这讲的是实现细节层面的遗漏；如果是整个方案的健壮性假设站不住，见《方案看起来对，经不起边界推敲》。
看着对但经不起边界
我给你一套设计，在常规输入下自洽、读起来很合理，你就采纳了。但它一上规模、一碰异常路径、一遇并发或失败重试就垮——问题不在某一行代码，而在方案隐含的健壮性假设站不住。这讲的是设计层面的脆弱；如果是写实现时漏了某个具体边界分支，见《写实现时，我会漏掉那些你没明说的边界分支》。
风格漂移
同一个仓库里，我这个文件用 async/await，下一个文件改用 promise 链；这边 camelCase，那边 snake_case。不是我故意标新立异，而是我没读旁边的文件，凭记忆给了「我熟悉的默认写法」。
性能反模式
我交出的代码功能是对的，测试也绿，但循环里藏着一次次数据库查询、O(n²) 的扫描、每轮重新编译的正则。在你的小数据集上它飞快，到了线上十万行就趴下——因为我默认按「能跑通」写，不按「跑多大量」写，除非你把规模和约束摆到我面前。
并发竞态
我默认按「单线程、顺序执行、没人同时动」来写代码，于是漏掉竞态条件、共享状态不加锁、check-then-act 不原子、数据库不加事务或乐观锁。功能测试（单线程）全绿，一上并发就偶发丢更新、数据错乱、死锁。这讲的是并发正确性这一类特定且隐蔽的缺陷，和实现层漏分支、方案整体健壮性不是一回事。
魔数 / 硬编码
超时写 30000、重试 3、接口地址 https://api.prod... 直接塞进逻辑里——没有名字、没有集中、同一个值散落好几处。代价是改一处要全库找、换环境就崩、读代码全靠猜。
文件系统顺序假设
我默认文件系统的操作和事件「按确定、串行、可预测的顺序发生」——写完一个文件马上就能读到完整内容、watcher 事件按修改顺序一条一条来、readdir 按创建或字典序返回、文件一出现就代表写完了。于是我把「文件出现」当同步信号、把 watcher 当成有序日志，代码在我本地的快盘上跑得好好的，换台机器、换个 OS、上点负载就偶发崩。这讲的是 OS / 文件系统层的假性确定，和并发竞态（共享内存/数据库状态的竞态）、漏掉边界分支（漏了某个输入）都不是一回事。