Localhost 是一个谎言：Happy Path 谬误

Source: Dev.to

幸存路径谬误

我们都有过这种经历。你在开发新功能时，想象一个完美的场景：API 总是 20 ms 响应，用户总是输入有效的电子邮件地址，数据库从不超时，JSON 总是格式正确。你写好代码，跑在本机上，完美运行。提交、推送，然后回家。

然后，凌晨 3:00，你的手机亮起。生产服务器崩溃，因为 API 返回了一个纯文本的 “502 Bad Gateway” HTML 页面。你的代码尝试把它当作 JSON 解析，卡住了，导致整个应用挂掉。

这就是 幸存路径谬误——初级开发者被 PagerDuty 警报惊醒的最大原因。危险的幻想是：

“只要在本地能跑，就能在生产环境跑。”

Coder 编写在一切顺利时能工作的软件。Professional 编写在出现问题时仍能存活的软件。如果你只为幸福路径编写代码，你的应用就会脆弱。

“这就像在不装安全气囊的情况下造车，因为你计划‘只要小心驾驶’。”

乐观是一种我们负担不起的奢侈。网络会拥堵，第三方服务会宕机，用户会做出意想不到的操作。要从 coder 转变为 professional，你必须用偏执取代乐观：假设输入是恶意的，网络是拥堵的，数据库已耗尽。

• 初级思维： “我一定会得到数据。”
• 高级思维： “如果我得不到数据会怎样？”

---

信任 JSON：常见的罪魁祸首

我们都写过假设 API 响应是有效 JSON 的代码。它在 99 % 的情况下工作，但那 1 % 可能毁掉你的可用性。

之前：“乐观”做法

// We assume the network is perfect and the API is our friend.
// If 'apiResponse' is "502 Bad Gateway" (string), this crashes the app.
const parsedResponse = JSON.parse(apiResponse);

// We immediately try to use the data.
// If the previous line failed, we never get here.
updateUI(parsedResponse.user);

之后：“偏执”做法

let parsedResponse;

try {
  // Attempt the dangerous operation
  parsedResponse = JSON.parse(apiResponse);
} catch (error) {
  // CHAOS DETECTED: The API lied to us.
  // Handle it gracefully instead of crashing.
  console.error('API returned malformed JSON:', error);

  // Load a default configuration so the app stays alive
  parsedResponse = DEFAULT_CONFIG;
}

// The app continues running, even though the API failed.
updateUI(parsedResponse);

在第二个例子中，API 失败了，但应用仍然存活。用户可能会看到一条通用错误信息或缓存的数据显示，但不会看到白屏死亡。

---

防御式编码原则

• 不要信任网络。
• 不要信任用户输入。
• 不要信任数据库。

防御式编写代码。当服务器在凌晨 3 点起火时，“在我的机器上能跑”不是有效的借口。停止只为取悦编译器而写代码。

---

延伸阅读

本文摘自我的手册 《Professional Junior: Writing Code that Matters》——一本关于未成文工程规则的实战指南。

👉 Get the Full Handbook Here