我知道这首先错过了使用Cloud Functions的意义，但是在我的特定情况下，我正在使用Cloud Functions，因为这是将Next.js与Firebase Hosting桥接的唯一方法。我不需要使其具有成本效益，等等。
话虽这么说，Cloud Functions的冷启动时间简直无法忍受，而且还不能投入生产，对于我的样板，平均大约需要10到15秒。
我当然看过Google的这段视频（https://www.youtube.com/watch?v=IOXrwFqR6kY），其中谈到了如何减少冷启动时间。简而言之：1）修剪依赖关系； 2）依赖关系版本在Google网络缓存中的尝试和错误； 3）延迟加载。
但是，嘿，1）我可以裁剪的依赖项太多了。2）我怎么知道哪个版本的缓存更多？3）只有太多依赖项可以延迟加载。
另一种方法是一起避免冷启动。从本质上讲，我可以（仅一个）保持云功能的温暖，这是什么好方法呢？
对于所有“无服务器”计算提供商，总会有某种形式的冷启动成本无法消除。即使您能够通过ping通使单个实例保持活动状态，系统也可以启动任意数量的其他实例来处理当前负载。这些新实例将产生冷启动成本。然后，当负载减少时，不必要的实例将被关闭。
正如您所发现的，有许多方法可以使冷启动成本降至最低，但无法消除这些成本。
如果您绝对要求热服务器处理24/7的请求，则需要管理自己的运行24/7的服务器（并支付运行24/7的服务器的费用）。如您所见，无服务器的好处是您无需管理或扩展自己的服务器，而只为使用的服务器付费，但是与项目相关的冷启动成本却不可预测。这就是权衡。