我在 Vercel 专业计划上托管的 NextJS 项目遇到问题。使用 ISR 设置的路由只会超时。我revalidate目前已设置为 120 秒，但我也尝试过 60 秒、30 秒和 6000 秒，以防我过于频繁地调用它。
我使用 Strapi 作为无头 CMS，为 NextJS 提供 API 以构建页面并部署在 Render 的德国区域。Strapi 使用的数据库是托管在 MongoDB Atlas 上并部署在 MongoDB 的爱尔兰 AWS 区域上的 mongodb 数据库。（我还将 Vercel 上的无服务器功能设置为从英国伦敦提供服务，但我不确定这是否会影响 ISR？）
有 3 个不同的动态路由，每个路由大约 20 个页面，在构建时它们平均分别为 6999 毫秒、6508 毫秒和 6174 毫秒。然而在运行时，如果我更新 Strapi CMS 中的一些内容并等待我为revalidate页面设置的 120 秒，则几乎不会重建。如果我查看显示实时日志的 vercel 仪表板“功能”选项卡，我会发现许多页面都试图同时重建所有页面，并且它们都达到了 60 秒的超时限制。
我也将vercel日志发送到LogTail，如果我为我编辑的页面名称过滤日志，我可以看到它在120秒之前返回一个304状态代码，但在120秒之后它会尝试获取并构建新页面，几乎总是返回超时错误。
所以我的第一个问题是，如果所有这些页面的 CMS 中没有任何变化，但我故意改变了自己，为什么还有这么多人试图同时重建？其次，为什么在构建时构建页面平均只需要 6000 毫秒，但在 ISR 期间却达到了 60 秒的超时限制？
可能是因为触发了如此多的重建，以至于它们最终都导致彼此超时？如果是这样，那么我该如何解决第一个问题？
这是我的 vercel 实时日志的屏幕截图。如您所见，许多页面都试图立即重建，但我不知道为什么，在这种情况下我只更改了一页的数据。
为了尝试调试问题，我决定创建一个 Postman Flow 来构建动态路由之一，然后将构建页面所需的每个 api 调用的时间加起来，经过几次测试后，我平均得到 7621 毫秒。这是 Postman 控制台的屏幕截图：
我对 NextJs ISR 没有那么丰富的经验，所以我希望我只是做错了什么，或者我在 vercel 等上没有正确设置。但是在查看了 stackoverflow 和其他网站之后，我相信我正在使用 ISR正如预期的那样。如果有人对可能发生的事情有任何想法或建议，我将非常感激。