1. Promise 错误处理的重要性：超越 Linter 警告
许多前端项目会启用像 @typescript-eslint/no-floating-promises 这样的 Linter 规则，当遇到未捕获的 Promise 错误时会发出警告。例如，以下代码会触发 Linter 警告：
functionReturningPromise()
.then(retVal => doSomething(retVal));为了消除警告，开发者可能会简单地添加一个 catch 块，但又立即重新抛出错误：
functionReturningPromise()
.then((retVal) => doSomething(retVal))
.catch((error) => {
throw error; // 看起来只是为了满足 Linter
});这种做法背后的疑问是：如果最终错误还是被抛出，显式添加 catch 块的意义何在？这正是我们需要深入理解 Promise 错误处理机制的关键。
2. 未捕获 Promise 拒绝的后果：环境差异与严重性
未捕获的 Promise 拒绝在不同的 JavaScript 运行环境中会导致截然不同的后果，其严重性远超 Linter 警告本身。
2.1 Node.js 环境中的“硬错误”
在 Node.js 环境中，特别是 Node v15 及更高版本，未处理的 Promise 拒绝被视为硬错误（HARD ERROR），这意味着它将导致进程立即退出。
考虑以下示例代码：
Promise.reject();
setTimeout(() => console.log('hello'), 1000);这段代码看似无害：一个未处理的 Promise 拒绝，以及一个在 1 秒后打印 'hello' 的定时器。
在 Node.js 中执行这段代码：
$ node -e "Promise.reject(); setTimeout(() => console.log('hello'), 1000)"
node:internal/process/promises:288
triggerUncaughtException(err, true /* fromPromise */);
^
[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "undefined".] {
code: 'ERR_UNHANDLED_REJECTION'
}
Node.js v18.12.1从输出可以看出，'hello' 并没有被打印出来，因为 Node.js 进程在检测到未处理的 Promise 拒绝后立即终止了。这意味着在生产环境中，一个未被捕获的 Promise 错误可能导致你的整个服务意外崩溃，造成严重的可用性问题。
作为对比，如果 Promise 被成功解决：
$ node -e "Promise.resolve(); setTimeout(() => console.log('hello'), 1000)"
hello此时，程序正常执行，'hello' 也被成功打印。
因此，对于任何支持 LTS 版本的 Node.js 应用程序，你都必须处理 Promise 错误，否则将面临意外崩溃的风险。
2.2 浏览器环境中的“静默失败”与用户体验
在浏览器环境中，未捕获的 Promise 拒绝通常不会导致整个应用程序崩溃，浏览器会将其记录为“未捕获的 Promise 拒绝”错误到控制台，然后继续执行。然而，这并不意味着错误可以被忽略。
想象一个场景：你的 Promise 跟踪一个 API 调用，该调用用于提交用户在应用程序中输入的数据。如果这个 API 调用因某种原因失败，而你没有捕获这个错误，那么：
- 静默失败： 用户可能认为数据已成功提交，而实际上并未成功。
- 糟糕的用户体验： 应用程序可能会显示一个无限加载的旋转器，或者保持在不正确的状态，因为没有错误处理逻辑来通知用户或恢复状态。
- 数据不一致： 用户可能会尝试重新提交，导致重复数据或更复杂的逻辑问题。
用户通常不会查看控制台，所以即使浏览器记录了错误，他们也无法感知到问题。一个健壮的应用程序应该在出现问题时向用户提供适当的反馈，例如显示错误消息、允许重试或引导用户采取其他行动。
3. 常见的错误处理误区：.catch(e => { throw e }) 的危害
正如前面提到的，仅仅为了满足 Linter 而写 .catch(e => { throw e }) 实际上并没有真正处理错误。这种做法只是创建了一个新的、被拒绝的 Promise，而这个新的拒绝很可能仍然是未被处理的，最终仍然会被记录到控制台，甚至在 Node.js 中仍然可能导致进程退出。
它只是将一个未处理的拒绝转换为另一个未处理的拒绝，并没有解决根本问题。
4. 正确的 Promise 错误处理实践
真正的错误处理意味着你需要在 catch 块中执行有意义的操作，而不仅仅是重新抛出错误。这些操作可能包括：
- 用户反馈： 向用户显示友好的错误消息（例如，通过 alert()、Toast 提示或页面上的错误区域）。
- 日志记录： 将错误信息记录到日志系统，以便开发团队进行故障排查。
- 状态管理： 更新应用程序状态，以反映错误情况，例如关闭加载指示器、禁用提交按钮。
- 优雅降级： 尝试提供备用功能或数据。
- 重试机制： 在某些情况下，可以尝试重新执行失败的操作。
- 上报监控： 将错误上报到错误监控平台（如 Sentry, Bugsnag）。
例如，在浏览器环境中，一个更实际的错误处理方式可能是：
functionReturningPromise()
.then((retVal) => doSomething(retVal))
.catch((error) => {
console.error("操作失败:", error); // 记录到控制台
alert("操作失败，请稍后重试。"); // 向用户显示提示
// 或者更新 UI 状态，例如显示一个错误横幅
// UI.showErrorMessage("提交数据失败：" + error.message);
throw error; // 如果需要将错误继续传播给上层调用者
});在这个例子中，即使你选择重新抛出错误，也已经执行了有意义的错误处理步骤，例如记录日志和通知用户。
总结
捕获 Promise 错误不仅仅是为了满足 Linter 规则，更是构建稳定、可靠、用户友好的应用程序的关键。未捕获的 Promise 拒绝可能导致 Node.js 应用程序崩溃，并在浏览器中造成静默失败和糟糕的用户体验。通过在 catch 块中实现有意义的错误处理逻辑，我们可以确保应用程序在面对异步错误时能够优雅地响应，提升整体的健壮性和用户满意度。始终记住，一个好的错误处理机制是任何生产级应用程序不可或缺的一部分。
