很抱歉，如果这个问题不适合 SO。
但我试着寻找很多答案。
我正在研究断路器设计模式，据我了解，它用于使您具有 API 容错能力。现在我很困惑的是，
假设我有调用支付 api 的 API，假设我将电路配置为在 5 个调用连续失败时打开。
现在根据断路器设计，我将在打开电路后将后续调用路由到回退方法。假设接下来的 5 次通话，在第 6 次通话时，如果 api 在线，我将调用支付 API，我将关闭电路。
但我没有发现这种模式的任何优势，比如 catch 块和断路器之间的区别。
我们可以在回退方法中做什么？这有什么帮助？
我们的同事已经展示了断路器的优势，所以我将专注于实际示例。
所以，看看你的例子，你有一个必须调用支付 API 的流程>让我们假设它是一个“外部”组件。如果没有这个电话，整个流程可能不能被视为“成功完成”（我知道您有一些在线流程，其中付款是其基本步骤之一）。
在这种情况下，断路器确实可能不会那么有用，除非作为后备，您将支付命令存储在某种中间存储中，然后“重新应用”支付逻辑。
断路器的全部意义在于提供合理的回退，以便在应用回退逻辑时不会将流程视为失败。
这是断路器更有意义的另一个示例。
如果您构建了一个“类似 netflix”的门户，并且在 UI 中有一个显示“推荐”电影的小部件。推荐引擎会考虑您以前看过/喜欢的电影。从技术上讲，这是一个“外部系统”/微服务。
现在，如果填充 UI 数据的流程无法获得推荐（例如，如果推荐服务关闭），您会“失败”整个流程吗？可能不会，也许最好显示一些推荐电影的“通用列表”并让用户继续使用该应用程序。
在这种情况下，断路器可以是实现对外部推荐服务的调用的不错选择。
现在，这个流程和异常处理有什么区别？
如果该推荐系统失败的原因是一些临时网络中断/数据库缓慢，那么最好给这个服务一些时间而不是试图一遍又一遍地调用它，我们应该给它一个“恢复”的机会'。当我们应用断路器时，在“开路”期间，我们的代码甚至不会尝试调用服务器，而是直接路由到回退方法。
另一方面，常规的 try/catch 块将始终调用推荐服务。
总而言之，断路器是问题中所述的容错模式；它是一种可以在某些情况下适用的工具，而在其他情况下则无关紧要。
确实，断路器的大量使用用于使 API 容错。
就像捕获块和断路器之间的区别一样。
catch 块和断路器之间的主要区别在于对故障情况的处理。假设我们正在调用外部系统的 api。可以说，api调用失败。
如果我们使用 catch 块，我们将捕获异常并调用回退方法。下次我们将调用相同的 api 并且外部系统仍然关闭。因此，同样的事件循环将再次发生。这将不必要地轰炸受苦的外部系统，消耗系统资源并增加您的 api 响应时间。
如果我们使用断路器模式，那么我们的第一次调用失败，然后我们打开电路。下次我们甚至不会调用外部系统，直接按照 fallback 模式。瞧，一切都处理好了！
我们可以在回退方法中做什么？这有什么帮助？
一个后备方法的好例子如下。我们有一个支付系统，可以将支付路由到不同的支付网关。假设我们从特定的支付网关收到错误，然后在备用方法中我们可以将其路由到不同的支付网关。
您也可以阅读本文以了解有关此主题的更多信息：https ://martinfowler.com/bliki/CircuitBreaker.html
这种设计模式的目标是封装处理意外的重复错误的逻辑。
此模式的wikipedia 页面有一些有用的部分解释了您希望实现此逻辑以避免发出您期望失败的请求的情况类型。
这种模式有什么好处
当您遇到您知道某项服务将不可用并且您希望在该服务重新联机之前自定义行为的情况时，此模式是有利的。例如，在数据库迁移期间，将请求中断到队列中直到迁移完成是有意义的。
捕捉块和断路器有什么区别
我认为这种差异是概念和实现之间的差异。检测是否存在要“打开电路”的情况可能意味着检测 catch 块中的错误并对其进行计数，如您的示例所示。然而，处理不仅限于错误。
在我的示例中，后端可能会通知前端即将发生迁移，从而导致前端出现“断路”，直到它收到迁移完成消息。