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