Firebase Functions单次调用是否会发生多次冷启动？

首先明确冷启动的基本粒度：冷启动是对外暴露的单个云函数实例维度的行为，和你代码里拆分的内部business.js、common.js这类不对外暴露的本地模块没有关系。
你当前的代码写法本身存在显性问题：在两个文件的顶层都写了admin.initializeApp()，冷启动加载依赖链时这两行代码会先后执行，直接抛出「Firebase App已存在」的运行错误，根本跑不到实际的业务逻辑。
正常无错场景下，当你第一次调用对外暴露的business.parentCalledFunction端点、平台侧没有闲置的热实例时，冷启动的完整流程是：

1. 平台拉起新的Node.js运行容器，分配运行资源
2. 从函数入口开始递归加载所有依赖的npm包、本地代码文件
3. 执行所有被加载文件的顶层代码（包括require firebase-admin、执行初始化、定义全局常量等）
4. 所有顶层代码执行完成后，才会进入你写的请求处理逻辑，响应本次调用

• 两个模块的逻辑是否都会产生冷启动耗时？
  所有写在模块顶层的代码（不管是business.js还是common.js里的），只要在冷启动阶段被加载执行，耗时都会计入本次冷启动的总时长。但这不是两个模块各触发一次冷启动，只是同一次冷启动流程里包含了两个文件的顶层代码执行开销。
• 父函数完成admin初始化后，被调用的common子方法是否还要承担冷启动开销？
  不需要。冷启动是整个容器实例级别的一次性流程，只要实例完成冷启动进入热运行状态，实例内部所有本地模块的方法调用都是普通的进程内函数调用，没有任何额外的冷启动开销。
• 冷启动是单次调用触发一次，还是每个函数单独触发？
  分两种场景：
  • 如果你拆分的common方法只是本地内部函数，没有单独部署为对外暴露的云函数：冷启动仅针对对外暴露的那个父函数触发，一个冷启动完成的实例可以连续处理多次该函数的请求，内部所有模块共享实例资源，不会单独触发冷启动。
  • 如果你把common里的方法也部署成了独立的对外云函数，通过HTTP/云函数SDK跨函数调用：那两个函数是完全独立的运行实例，各自有独立的冷启动流程，哪怕父函数是热实例，被调用的子函数如果没有闲置热实例，依然会单独触发冷启动。

• 第一步先修正重复初始化的问题：把admin初始化逻辑抽成独立的共享模块，比如新建admin.js文件，写入以下代码：

const admin = require("firebase-admin");
// 仅当没有已初始化的app实例时才执行初始化，避免重复报错
if (!admin.apps.length) {
  admin.initializeApp();
}
module.exports = admin;

后续所有业务文件、通用工具文件需要用admin的时候，直接通过const admin = require('./admin.js')引入即可，不要在各个文件里重复写初始化代码，既避免报错，也减少重复执行的冗余开销。

• 所有Firestore读写、参数校验这类通用逻辑，全部作为普通本地模块存放在代码库中，和对外暴露的云函数一起打包部署，绝对不要把这类高频调用的基础逻辑拆成独立云函数做内部调用——跨函数调用会走网络请求增加额外延迟，还会引入被调用方的额外冷启动成本，完全得不偿失。
• 顶层代码仅保留全局必须的初始化逻辑，非核心依赖、大体积计算逻辑不要放在顶层执行，按需在请求处理逻辑里加载，进一步压缩冷启动时长。
• 核心对外函数可以配置最小常驻实例数，保留1-2个热实例常驻，直接消除用户侧的冷启动感知。

内容的提问来源于stack exchange，提问作者Dorian Pavetić