对抗性自检

把这个项目的代码当成别人的提交来 review,切换成最挑剔的审查者。 ## 找 专找这几类:边界情况、异常/恶意输入、空值与类型错误、并发竞态、资源未释放 (文件/连接/监听器/定时器)。逐文件读真实代码,不靠印象。 ## 验 —— 每个发现必须过这关才算数 对每个疑似 bug,反过来【试图证伪它】: - 给出【具体触发输入】+【用户能观察到的错误后果】(崩溃/数据损坏或丢失/ 错位/泄漏/卡死)。给不出 → 丢弃。 - 确认经【正常用户流程可达】。需手编坏数据、删自己的配置、或调用方已保证不发生的 → 丢弃(那不是 bug)。 - 能写一小段可复现测试就写、跑一下确认;不能就用代码 trace 论证到行。只保留证伪不掉的。宁可漏,不可凑。 ## 修 —— 每个真 bug - 最小、对症。【不】为不可达输入加防御垫片、【不】做预防性/装饰性改动—— 那是另一种债(过度工程),修 bug 不该顺手制造。 - 修完自检:不引入新 bug、不破坏既有行为、不偷偷改其它路径。 ## 迭代到收敛 一轮(找→验→修)做完再开一轮,在【已确认 bug 之外】找新的——尤其去攻【你这轮的修复】(修复常引入回归)。连续 2 轮挖不到新的确认 bug 就停。不要「直到挑不出任何问题」——挑剔的人总能编理论边际问题,那样永不收敛。 ## 输出 每个确认 bug:file:line · 触发输入 · 错误后果 · 最小修复。 每轮结尾:本轮新确认 N、证伪丢弃 M、累计 X。