FunctionGraph 冷启动与超时排查备忘：我踩过的坑和一份自查清单

最近在个人小项目里用 FunctionGraph 写了几个 HTTP 触发的接口，平时调用很顺，但偶尔第一次请求要等好几秒，还碰到过几次莫名其妙的超时。花了两个晚上把问题捋清楚，这里把排查思路和清单记下来，方便以后自己翻，也给遇到类似情况的朋友参考。

一、先分清是“冷启动慢”还是“执行本身慢”

我一开始犯的错误，是把所有慢请求都当成冷启动。后来养成习惯：先看函数的调用日志，对比每次请求的初始化耗时和执行耗时。如果只有隔一段时间后的第一次请求慢，后续请求很快，基本可以判定是冷启动；如果每次都慢，那就是代码或下游依赖的问题，和冷启动关系不大。

我的判断方法很简单：

1. 在入口函数外层（全局作用域）打印一次时间戳，标记“实例初始化”；
2. 在处理函数开头和结尾各打一条日志；
3. 连续调用几次，观察初始化日志是否只出现一次。

这样一眼就能看出时间花在哪一段。

二、冷启动慢的常见原因

结合自己的测试，主要有这几类：

• 代码包太大：我曾把整个依赖目录连同测试文件一起打包，包体积膨胀了好几倍，拉取和解压明显变慢。精简后冷启动时间肉眼可见地下降。
• 全局初始化太重：在全局作用域里加载大模型文件、建立多个数据库连接，都会算进冷启动。能懒加载的尽量懒加载。
• 运行时选择：同样逻辑，解释型语言的轻量函数一般启动更快；依赖较重的运行时初始化会更久。
• 内存规格偏小：内存规格通常和分配的计算资源相关，规格太小时初始化阶段也会拖慢。我把内存从最小档调高一档后，初始化快了不少，费用增加有限。
• VPC 访问：函数配置了 VPC 访问后，首次建立网络连接可能会多一些耗时，这点要心里有数。

三、缓解冷启动的做法

1. 精简代码包，只保留运行必需的依赖；
2. 把可复用的客户端（如 HTTP 连接池、数据库连接）放在全局，但避免一次性做大量无关初始化；
3. 对延迟敏感的接口，考虑使用预留实例，让一部分实例常驻；
4. 如果业务允许，用定时触发器做轻量“预热”调用——不过这只是权宜之计，要评估成本；
5. 合理调高内存规格，做一次对比测试再决定。

四、超时排查路径

超时比冷启动更容易让人抓狂。我的排查顺序如下：

• 确认超时配置：先看函数配置的超时时间是否太短。我第一次就是默认值没改，下游接口一慢就直接超时。
• 看下游依赖：大部分超时其实卡在外部调用上。给每次外部请求单独设置客户端超时，并打印耗时日志，别让函数傻等。
• 检查网络连通性：访问公网资源时，如果函数在 VPC 内且没有配置相应出口，请求会一直挂起直到超时。这个坑我踩过，日志里只有“超时”，没有任何报错，很迷惑。
• 注意异步代码：Node.js 里如果有未完成的 Promise 或者忘了返回结果，函数可能会一直等待。
• 关注并发与配额：突发流量时实例扩容需要时间，叠加冷启动，尾部延迟会被放大。

五、我的自查清单

• 日志能区分初始化耗时与执行耗时
• 代码包已精简，无测试文件和无用依赖
• 全局初始化只做必要工作
• 函数超时时间大于下游调用超时之和，并留有余量
• 每个外部调用都有独立超时与重试上限
• VPC 场景下已确认出网路径
• 延迟敏感接口评估过预留实例
• 改动前后做过对比测试并记录数据

六、小结

冷启动和超时看起来都是“慢”，但根因完全不同。先用日志把时间拆开，再对症下药，比盲目调参数有效得多。以上都是我在个人测试环境中的经验，具体数值会因运行时、规格和业务而不同，建议大家按自己的场景实测验证。