运气比正确更重要：为什么你的代码需要“看似无用”的 catch‑alls

Source: Dev.to

Introduction

在我作为软件工程师，横跨 C# 后端、SQL 数据库和 JavaScript 前端的所有时间里，我学到一个不可否认的真理：无论你为多少边缘情况做好准备，用户总会以某种方式让你大吃一惊。你可以设计最严密的架构，但有时唯一拯救系统的，是一个恰到好处的全局捕获或额外的空值检查。

Why Catch‑alls Matter

你一定遇到过这种情况：同事在 PR 评审时标记了一个检查，问道：“这有什么意义？这里的数据不应该为 null。”你批准了 PR，认为这个检查没有必要——结果一周后才发现，这行代码阻止了一次大崩溃，因为某位用户以某种方式跳过了表单的第 3 步，导致一半预期的模型数据缺失。

“好运眷顾有准备的人，亲爱的。” – Edna Mode

你应该始终设法考虑所有荒诞的角度——从这些角度出发，用户可能会破坏你的应用。用户在做你未预料的事情时，创造力是惊人的。

Real‑world examples

• 输入过长 – 用户在 PlaceName 字段粘贴了 50 个字符的地址，导致数据库悄悄截断并丢失了实际的位置信息。
• 绕过验证 – 用户找到一种方式提交违背前端验证规则的负载，暴露出隐藏的 bug。

AI Assumes the “Happy Path”

无论你使用 Copilot、本地 Ollama 模型，还是其他助手，AI 在给出你所要求的内容时表现得非常出色。它会优雅地编写“幸福路径”，但很少考虑混乱的人为边缘情况。

AI 假设用户会遵守规则。作为工程师，我们知道他们从不遵守。如果你依赖 AI 来编写数据处理或 API 逻辑，你必须自己为模型忽略的不可预见情景做好准备。

Conclusion

系统可能崩溃的方式不计其数。尽管我们都希望代码和逻辑能够百分之百“正确”，但实际上根本不可能做到 100 %。有时，你的工程直觉必须发挥作用。当你想要添加额外的验证步骤、冗余的回退，或看似毫无意义的全局捕获时——就去做吧。它现在可能看起来多余，但在某个星期五的下午，它可能正是拯救系统的关键。