根本原因与表象

调试中最诱人的陷阱，就是那种让错误消失却没修复原因的补丁。如果 user 是 undefined，你用 if (user) { ... } 来"修复"它，错误是停止了——但现在注册会悄无声息地什么都不做，这更糟糕：一次响亮的崩溃至少告诉了你哪里出了错，而现在什么都不告诉你了。真正的问题是为什么 user 在这里是 undefined？ 也许数据库查询失败了。也许某个字段被重命名了。也许上游缺了一个 await。

当 AI 提出一个修复方案时，问它：

• "这是在修复原因，还是在掩盖表象？"
• "这个值出错的最初原因是什么？"
• "同样的根本原因会不会破坏其他东西？"

修复根本原因通常会让代码更简单或更清晰。修补表象通常会添加一个守卫、一个吞掉错误的 try/catch，或者一个掩盖真正问题的默认值。对第二种要保持警惕。有一个值得学会的迹象：如果一个修复添加的代码，其唯一职责是防止崩溃，而不是做正确的事，那你很可能是在修补表象。真正的修复倾向于把那个不可能的状态彻底移除，而不只是熬过它。