正文
这些适配器可以由框架作者、托管服务提供商、社区或上述各方共同维护。框架通常具有良好的结构，这样任何人都能构建自己的适配器，以防他们所选择的提供商没有对应的适配器。之所以能做到这一点，是因为它们有公开的适配器规范文档。这也意味着意外情况会更少，因为适配器接口的更改会遵循语义化版本的约定。
在平台供应商方面，他们通常有自己的 API 文档，说明框架应如何与平台交互，任何框架都可以使用这些 API。在我们的场景中，这就是 Netlify Framework API。
以 Netlify 如何使用带有 Netlify 构建适配器的框架 (Astro) 来构建站点为例
Next.js 所面临的独特挑战在于，尽管 Vercel（平台）早在 2022 年就为框架提供了构建输出 API（Build Output API），但 Next.js 本身并不遵循该 API，也没有适配器机制，任何其他角色都无法通过该机制支持其他平台。相反，Next.js 构建使用的是一种私有的、基本没有文档记录的格式，这种格式可能会发生变化。
相反，Netlify、Cloudflare、AWS Amplify Hosting、SST、Google Firebase App Hosting 和 Microsoft Azure Static Web Apps 等提供商必须从磁盘读取 Vercel 定制的、部分未文档化的构建输出，将其转换为自己的格式，然后再写回磁盘上
。
Next.js 构建仅与 Vercel 兼容，因此其他平台（如 Netlify）必须在事后将其转换为自己的格式。
在 Netlify，我们会在 Next.js 构建后自动运行一个构建插件（OpenNext Netlify 适配器）。再加上全面的自动化测试（包括框架自身的测试和我们自己的测试套件），最终在 Netlify 实现了强大的 Next.js 体验。对于绝大多数站点来说，都可以做到开箱即用，无需任何配置。但是，如果 Next.js 能够遵循既定的适配器模式，实现起来会更简单、更易于维护，也更便于社区为其做出贡献。这个问题已经断断续续讨论了一段时间，但自从 OpenNext 小组的范围扩大，明确表达了多方的需求后，这个问题才真正得到解决。现在，它 终于启动了！
Next.js 部署文档列出了这些部署选项：
你可以使用 Vercel 部署托管的 Next.js，也可以在 Node.js 服务器、Docker 镜像甚至静态 HTML 文件上自行托管。
这里的“Node.js 服务器”指的就是一个简单的 Node.js 服务器。对于正式的项目来说，Node.js 服务器的单个唯一实例（无论是否使用 Docker）不具备横向扩展的能力和零停机部署的能力，这并不是一种可行的部署策略，而且完全静态的网站目前只能覆盖有限的 Next.js 使用场景。在默认的情况下，这并不能支撑 Next.js 的大部分功能，比如，边缘中间件、全局持久化页面、获取缓存以实现增量式静态再生（Incremental Static Regeneration）和按需重新验证等，正是这些特性使得 Next.js 在大规模环境中变得非常强大。
自托管文档 简要介绍了一些复杂问题：
缓存和重新验证页面（使用增量静态再生（ISR）或 App Router 中较新的功能）使用相同的共享缓存。[...]
