为了尽量减少冷启动，我为我的谷歌云函数设置了一个最小实例。我实际上是用这样的 firebase admin SDK 来做的：
functions.runWith({ minInstances: 1 })
...但我可以在 Google Cloud Console 中看到它得到确认：
我注意到每次部署后，我仍然会遇到一个冷启动。我会假设一个实例已准备好并准备好接受第一个请求，但事实似乎并非如此。例如，以下是日志：
您可以看到部署后约 16 小时，第一个请求进来。这是一个冷启动，需要 8139 毫秒。下一个请求大约在一个小时后到来，但没有冷启动，请求需要 556 毫秒，比第一个请求快得多。
这是预期的行为吗？即使设置了最小实例，我们还会遇到冷启动吗？然后，我是否应该在每次部署后使用虚拟请求启动云功能，以防止我的用户遇到第一次冷启动？
Tl;dr：具有最小实例集的函数的第一次执行在技术上不是冷启动，但可能会比该实例的后续执行慢。
函数的最小实例将在部署时立即“预热”，并处于温暖但空闲的状态，准备好响应请求。但是，我们编写的函数在第一次实际触发时通常需要进行额外的设置工作。
例如，我们可能使用动态导入来拉入库或需要建立与远程数据库的连接。即使函数实例是温暖的，但必须在第一次执行时完成的额外工作意味着它可能会比以后的执行慢。
最小实例设置的好处是，以后的执行可以从第一次执行完成的所有设置工作中受益，并且可以比将它们缩小到零并在下一次请求时重新设置自己要快得多。
更新：有时，空闲实例可能会被 Cloud Functions 后端杀死。如果发生这种情况，将立即启动另一个实例以满足所需的最小实例设置，但该新实例将需要在第一次触发时再次完成其额外的设置工作。但是，这确实不应该经常发生。
该文档没有对行为做出硬性保证（强调我的）：
为了最大程度地减少冷启动的影响，Cloud Functions会在处理请求后尝试让函数实例在未指定的时间内保持空闲状态。
所以，有一个尝试（不能保证），它在处理请求后（而不是在部署后）开始，但你不知道这会持续多久。如前所述，听起来您可能想要提出请求，并期望它可能仍无法始终按照您想要的方式工作。