我在 Vercel 网站上找到了this 的报价：
在使用 Next.js 时，Vercel 优化了服务器渲染页面和 API 路由的无服务器函数输出。所有函数都将在同一个包中创建（如果大于 50mb，则在多个块中创建）。这有助于减少冷启动，因为捆绑的功能更可能是热的
但是getServerSideProps 也是这样吗？
我有一个带有 API 的小项目和另一个使用 getServerSideProps 加载数据的页面。当第一个 API 完成时。我会除了带有getServerSideProps 的下一页会很快，但这似乎也有冷启动。
第二次一切都很快。
【问题讨论】：
标签： aws-lambda next.js server-side-rendering vercel
基于相关 GitHub 讨论中来自 Vercel 的以下两个 cmets：
有一点需要注意——在 Vercel（最近的更新）、Next.js SSR 页面和 pages/api 路由被捆绑到两个单独的 Lambdas (λ) 中，所以你 不必担心 Serverless Function 的限制。
来源：https://github.com/vercel/vercel/discussions/5093#discussioncomment-57628
API Routes 都会被捆绑，每个 SSR 页面也会被捆绑 - 如果超过，这两个都将创建另一个功能 最大容量 (50MB) 虽然这是在 限制以避免它太靠近。
来源：https://github.com/vercel/vercel/discussions/5458#discussioncomment-614662
我的理解是，在您的场景中，API 路由（或您可能拥有的任何其他 API 路由）将被捆绑到一个函数中，而 getServerSideProps 将被捆绑到另一个函数中。如果任一超过 50MB 大小限制，则会创建一个附加函数。
您所经历的似乎是意料之中的。 API 路由和getServerSideProps 将是不同的函数，因此具有单独的冷启动。
【讨论】：
您还可以在 getServerSideProps 和 API Routes 中使用缓存标头来进行动态响应。例如，使用 stale-while-revalidate。
如果您使用 Vercel 来托管您的前端，只需一行代码，您就可以利用 stale-while-revalidate 缓存策略，该策略在使用重新验证时与 getStaticProps 的行为非常相似。
// This value is considered fresh for ten seconds (s-maxage=10).
// If a request is repeated within the next 10 seconds, the previously
// cached value will still be fresh. If the request is repeated before 59 seconds,
// the cached value will be stale but still render (stale-while-revalidate=59).
//
// In the background, a revalidation request will be made to populate the cache
// with a fresh value. If you refresh the page, you will see the new value.
export async function getServerSideProps({ req, res }) {
res.setHeader(
'Cache-Control',
'public, s-maxage=10, stale-while-revalidate=59'
)
return {
props: {},
}
}
查看文档：https://nextjs.org/docs/going-to-production#caching
但重要的是要知道何时在 next.js 中使用 getServerSideProps 或 api url
getServerSideProps
每次用户请求页面时，getServerSideProps 函数都会获取数据。它会在将页面发送给客户端之前获取数据。如果客户端发出后续请求，则会再次获取数据。在这些情况下，使用：
如果页面不是 SEO 关键，例如，如果您需要为管理员获取当前用户，则不需要使用 getServerSideProps。但是，如果您要为主页获取购物项目，最好使用getServerSideProps。
重要的是要了解，我们正在构建的某些网站不仅需要根据请求将 Html 页面返回给用户。例如，您的网站上可能有一项功能，允许用户提交反馈或注册时事通讯。因此，当用户单击此类按钮以注册时事通讯时，请考虑在我们注册时事通讯时幕后发生的情况。
我们需要将数据发送到某个服务器以存储在某个数据库中输入的时事通讯电子邮件地址，并且发送的请求不是获取站点，而是存储数据。我们不想获得一个 Html 页面，而是希望将该用户输入的数据发送到某个数据库。这就是我们使用 API 的原因。有不同类型的 api，但主要思想是相同的。我们有一个服务器，它公开了一些特定的 url。这些 url 不仅仅是发送 html 数据，而是接受一些数据并用任何类型的数据发送回响应。
所以 Api 路由是一种特殊的 Url，您可以将其添加到 next.js 应用程序中，它不是关于获取标准浏览器请求并发送回预呈现的 html 页面，而是关于获取数据，可能使用数据将数据存储在某个数据库中，并以您选择的任何形式发回数据。
【讨论】：