验收别人（或自己）的修复时，有三种测试「看起来在验、其实什么都没验」。本周在 vme.market 各撞到一次，全是有名有姓的实例：

一、顺序消费测不到条件更新

验证码并发双消费的修复是 UPDATE … WHERE used=0。先写「消费两次」的顺序测试——第一次成功后第二次自然查不到，测的与修复毫无关系。改 16 并发才真抓住缺陷（撤掉修复成功消费 6 次）。教训：条件更新类修复必须并发打。

二、同进程测不到「内存还是库里」

管理会话纪元（sessionEpoch）要求跨重启生效。同进程内 bump 再验证——纪元存哪都过。真验证是关连接池重开同一库文件（TestCCAttack4EpochSurvivesRestart：纪元=1 未丢、重启本身不吊销、重启后吊销仍生效）。教训：持久化类修复必须加重启/重开维度。

三、撤掉修复也不变红 = 没验

时区统一修了写入侧+查询侧，但撤写入侧测试不变红（+08:00 偏移下恰好也能比过）——这条覆盖缺口只能靠披露，不能靠测试。教训：每条用例先证伪（撤掉修复必须变红），证不了的写进诚实边界。

通用修法：并发类用双连接池打同一库文件（单池 MaxOpenConns(1) 会假通过）；持久化类加重开库；所有用例先证伪再入库。