Gridsome/Gatsby 用例：仅 CMS？
我读到 Gridsome/Gatsby 与 CMS 配合得很好，但我从来不需要对 CMS 做任何事情，这就是为什么我个人无法理解这种优势的原因。这是最好使用 Gridsome/Gatsby 的唯一情况吗？
静态站点生成和预取
都可以进行静态站点生成和预取。行为有什么不同吗？
灵活性
基本上使用 Nuxt/Next，我可以灵活地做我想做的事，并在我积极开发时轻松更改构建行为（SSR 或静态站点生成）。另一方面，Gridsome/Gatsby 没有提供灵活性。或者是吗？
时间投资
此外，考虑到时间，学习两个框架——嗯——非常耗时。因此 Nuxt/Next 可以让我覆盖更广泛的用例，并且更值得学习。至少根据我目前的知识，我是这么认为的。
当前的个人用例
在我的具体情况下，我想创建一个登录页面。理论上，从阅读文章来看，Gatsby/Gridsome听起来更合适。但是从功能上看，Nuxt/Next 与 Gridsome/Gatsby 相比，可以做到完全一样，没有任何缺点。
当 Nuxt/Next 是 SSR 优先时，Gridsome/Gatsby 仅面向静态。
SSG：静态站点生成器 - Gatsby/Gridsome
SSR：服务器端渲染 - Next/nuxt
仅 CMS
不，但是有很多 SSG 插件可以帮助您从 CMS（Wordpress、Drupal、Contenful、Strapi 等）获取数据。您不需要 CMS 即可使用 SSG，您可以使用 JSON、Markdown、MDX 来丰富您的标记。
灵活性
实际上，您无法使用 SSG 更改构建行为。但是你可以用静态网站做动态的事情。
时间投资
SSG 和 SSR 之间非常相似。SSG 可能更简单、更抽象，但如果你使用 Gatsby，你将学习 React 的一部分，Next 也是如此。
个人用例
对于登陆页面，我认为 SSG 是完美的工具。您需要的不仅仅是在构建过程中获取数据的静态显示吗？形式？您可以使用 Netlify 表单（或任何其他工具）。后端功能？使用无服务器功能。
SSG 带有出色的 SEO/性能插件，我不确定它们是否可用于 SSR。
使用像 Gridsome 或 Gatsby 这样的静态站点生成器，您可以在非常便宜的静态托管平台（如 S3）上部署您的站点，并将所有动态部分保留在客户端的浏览器上。您只需要一个动态后端（例如 NodeJS 或无服务器）来进行 API 调用或表单处理。
对于像 Nuxt 或 Next 这样的服务器端渲染引擎，您通常还需要一个 NodeJS 服务器来提供静态页面，并自己处理该服务器上的容量和可用性，这可能会更加昂贵。
还有一种两全其美的方法，即在 Next 或 Nuxt 中编写您的站点，并将其用作静态站点生成器，使用诸如“ next export ”或“ nuxt generate ”之类的命令。它们对静态站点不支持的功能有一些限制，因此您需要进行一些试验以查看是否适合您。