为什么不太好
在全面实施 ISR 概念之前，你可能需要考虑一下其中的一些缺陷。
当用户访问您的页面时，您希望他们立即看到最新版本。使用 ISR，第一个访问页面的访问者将看不到该版本。他们总是会先看到后备版本。然后，如果数据过时，第一个看到该缓存页面的访问者将首先看到过期数据，然后才会重新验证。同样，如果您的用户因旧/未构建的页面而体验到负面影响，这种不一致的体验可能很难调试。
还记得上面关于原子和不可变部署的整个部分吗？不幸的是，ISR 打破了该模型。通过 摩洛哥电报号码数据库 向你的包中添加额外的页面，回滚不再是即时的，当你更新内容时，你不再拥有你网站的单个新版本。
假设您建立了一个网站，其中有大量待售产品，并且每种产品都位于 ISRed 页面上。在理想情况下，您的用户可以导航到产品页面，查看待售产品并购买。下一个访问该页面的用户将看到该产品，并且该页面可能会更新以显示该产品已售罄。
如果您将网站回滚到不同的部署，由于您的页面与包分开缓存，因此它对用户而言可能处于与预期不同的状态。它可能是网站的旧版本、新版本，或者一些奇怪的中间缓存版本试图重新验证自身。不幸的是，调试这个很困难，因为不同的用户（和开发团队！）会看到不同的页面，而且可能很难复制。
ISR 意味着你可以回滚，但陈旧/单独缓存的页面将保持不变
请注意，在这张图中，单独缓存的页面仍保留着漂亮的大勾号，而回滚的页面不再是已发布的部署。如果用户导航到这些缓存的路线，他们可能会看到过时的数据。
驱动 ISR 的过时重新验证缓存是这些陷阱的根源。当 ISR 基于提供这样的过时内容时，我们最终会陷入一个相当大的困境，这最终会让用户感到困惑，让开发人员感到沮丧。
Netlify 如何处理它？
目前，ISR 已内置于 Next.js 中，我们通过Netlify Functions提供这些未构建的页面，每次都将它们渲染为新页面，以避免缓存问题。这确实不是 ISR 的精神，但我们强烈支持原子和不可变的部署。有比这种类型的缓存更好的方法来处理您的网站。
我们未来会推出解决方案，以更好的方式为这些未构建的页面提供服务，请继续关注！