我能够注解掉我的每个API控制器，加载swagger页面，然后重新打开它们，直到页面再次崩溃。一旦我找出了哪个控制器有问题，我就对控制器中的所有端点重复这个过程。
原来，我们的一个非常旧的方法是将ORM实体作为主体参数（非常糟糕），这导致swagger试图解析整个ORM对象图并耗尽内存。将此方法更改为接受DTO而不是数据层实体解决了该问题。

我认为这是一个已知的错误，当你使用非标准的序列化程序或配置你的web api是非标准的。
这是一个循环引用问题。
请参阅git hub存储库中的问题：https://github.com/domaindrivendev/Swashbuckle/issues/486

如果其他人遇到这个问题，并且似乎没有任何帮助，下面是我在我们的代码中发现的。
我们找了一个人来编写我们的API，他肯定已经自动导入了一堆基于DB Schema的类，但它所做的是创建大量引用其他分部类的分部类，而这些分部类又反过来引用了原始类。
所以这最终成为了一个循环引用的问题，就像上面提到的，但并不完全一样。我花了一段时间才弄清楚有什么不同，但当我注解掉对其他分部类的引用时，一切都运行得很好。
我的建议是结合上述两个答案，使用您自己的DTO，并确保您没有循环引用。
另一个重要的问题是[Route()]标签，这个家伙在POST/PUT方法的参数中放置了[Route("{model}"]，他使用[Route("{model}")]标签解析模型的JSON主体，所以在Route标签中放置它是不必要的，这会导致问题。它应该是[Route("")]。

检查你的api方法的ResponseType属性。在我的例子中，当我修改一个api方法的时候，我忘记删除responsetype，因为我删除了返回一个对象。

我也遇到了同样的问题。最后我可以让我的[ResponseType()]按照我的意愿与ORM实体保持原样，但是我设法通过在[SwaggerResponse()]中添加另一个模型来使swagger不冻结
以下是更多信息：https://mattfrear.com/2015/04/21/generating-swagger-example-responses-with-swashbuckle/

我们有一个来自NetTopologySuite.Geometries命名空间的“Point”类，它使swagger崩溃。

我一直在试图找到Swagger UI产生这种“页面无响应/您可以等待它成为响应或退出页面。”对话框的原因（因为它出现在Chrome。）Chrome偶尔会发出“啊，啪！错误代码：内存不足。”
[Edge和Firefox行为类似。]
如果我重复地告诉浏览器等待，大约一打或二十打，请求最终会成功。这显然是一个不确定的、间歇性的bug。因此，它不太可能是某种循环引用的结果。看起来Swagger UI只是使用了太多的内存，导致了浏览器超时。
我的WebAPI已经发展到大约55个路由;但我怀疑问题可能源于底层实体框架DbContext的复杂性，看起来Swashbuckle在生成其WebAPI模式期间对DbContext执行反射;但我不太熟悉它的实际工作原理。
我第一次遇到这个问题是在ASP.NETCore3.1中;但我目前的目标是.NET6Preview5。
我尽量让软件包保持最新;并且当前的Swashbuckle. AspNetCore版本为6.1.4。
我已经尝试从项目中排除Web API的每个子路径。只有在我删除了所有引用DbContext的路由时，这种方法才开始起作用。
我还有其他基于更简单的EF数据模型的Web API项目，其中Swagger UI工作得很好。

我经历了同样的像阿梅尔与“点”类从NetTopologySuite.Geometries。评论出来解决了问题。