云函数冷启动：先弄清它慢在哪，再谈怎么优化

很多团队第一次把接口搬上云函数，都会遇到同一种困惑：平时请求只要几十毫秒，偶尔却要两三秒，甚至直接触发网关超时。代码没有改，流量没有涨，慢的那一次到底发生了什么？多数时候，答案是冷启动。本文以华为云函数工作流 FunctionGraph 为例，把冷启动拆开来讲：它到底是什么、时间花在了哪里、哪些因素会让它更慢，以及六种经过验证的优化手段。读完之后，你应该能判断自己的慢请求是不是冷启动造成的，并知道先从哪一项改起。

一、什么是冷启动：实例从无到有的那一次

云函数的核心承诺是按需执行、用多少算多少。为了做到这一点，平台不会一直为每个函数保留一台专属服务器，而是把请求分配到一个个临时的执行实例上。一个实例从创建到可以处理请求，需要经过一段准备时间；如果请求到来时正好赶上实例创建，这次请求就要额外等待这段准备时间，这就是冷启动。

与之相对的是热启动：实例已经存在，请求直接进入函数代码执行，通常只有毫秒级的开销。两者的差别不在于代码逻辑，而在于请求到来时实例是不是现成的。理解这一点很重要：冷启动不是代码写错了，也不是平台出了故障，而是按需计费模式下必然存在的一种成本。它无法被彻底消灭，只能被控制在业务可以接受的范围之内。

实例的生命周期大致是这样的：平台收到请求，发现没有空闲实例，就创建一个新实例；实例启动运行时、加载代码、执行初始化，然后处理请求；请求处理完后，实例不会立刻销毁，而是保留一段时间等待下一个请求；如果这段时间内一直没有新请求，实例会被回收，下一次请求又要重新经历冷启动。并发量越高，需要同时存在的实例就越多，冷启动发生的概率也越高。

二、冷启动的时间都花在了哪里

把一次冷启动按阶段拆开，耗时主要分布在以下几个环节：

需要注意的是，上面每一项单独看可能都不大，但它们是串行发生的，会累加到同一次请求上。一个 50MB 的部署包、一个需要两秒初始化的 SDK、一次跨 VPC 的数据库建连，叠加起来就可能让一次冷启动达到数秒。优化的思路也由此而来：不是去优化某一个环节，而是逐项压缩，让总时间降下来。

三、哪些因素会让冷启动更慢

第一，部署包体积。包里每多一个用不上的依赖，加载时就要多读、多解压、多导入。把测试工具、示例数据、多个版本的模型文件一起打进部署包，是最常见的浪费。

第二，依赖的初始化成本。有些库在导入时就会做大量工作：扫描插件、加载模型、建立线程池。导入语句写在文件顶部，意味着每次冷启动都要先付这笔账，哪怕本次请求根本用不到这个库。

第三，内存配置。多数云函数平台会按内存比例分配 CPU，内存配得越小，分到的 CPU 越少，解压和初始化的速度也就越慢。把内存从 128MB 调到 512MB，有时反而能让总耗时下降，这笔账要按实测结果算，而不是凭感觉。

第四，网络位置。如果函数需要访问 VPC 内的数据库、缓存或内网接口，冷启动时还要完成网络配置与建连；如果配置不当，建连失败重试会进一步拉长耗时。公网访问与内网访问的路径不同，耗时特征也不同。

第五，并发突增。平时每分钟几个请求，突然来了一波流量，平台要在短时间内创建几十个实例，每一个都要走一遍冷启动流程。用户感受到的，就是一波集中的慢请求。

第六，运行时的选择。解释型语言通常启动较快，而需要预热的运行时冷启动更重。这并不意味着要为了冷启动放弃某个语言，而是要在选型时把启动时间算进成本里。

四、先确认：慢请求到底是不是冷启动

动手优化之前，先花一点时间确认问题，避免在错误的方向上用力。冷启动有几个典型的特征：慢请求零星出现，而不是持续变慢；往往发生在流量低谷之后的第一批请求，或者并发突然放大的时刻；同一接口在短时间内重复调用，后几次明显变快。

定位时可以这样做：在函数入口和关键节点记录时间戳，把一次请求的耗时拆成初始化耗时与执行耗时；查看平台提供的调用链与日志，确认慢发生在实例创建阶段还是下游调用阶段；对比不同时间段的耗时分布，看慢请求是否集中在实例新建的时刻。如果慢请求均匀分布、与实例新建无关，那问题可能在数据库、第三方接口或代码本身，这时优化冷启动收效甚微。

一个实用的习惯是给每次调用打上实例标识，比如在日志里输出实例的进程标识或启动时间。同一实例的多次调用共用一个标识，冷启动只会在新标识第一次出现时发生。这个简单的标记，能让排查从猜测变成验证。

五、六种优化手段：从便宜的先做起

1. 给部署包瘦身

只打包运行时真正需要的依赖，删掉测试代码、示例数据和用不到的驱动。把体积大的静态资源、模型文件放到对象存储 OBS 里，函数在需要时再按需读取，而不是每次冷启动都跟着部署包一起加载。包越小，拉取与解压越快，这是性价比最高的一步。

2. 延迟加载不常用的依赖

不是所有依赖都要在启动时导入。把重量级库的导入移到真正使用它的函数内部，冷启动时只加载核心路径需要的部分。例如：

# 不要在文件顶部导入重量级库
def handler(event, context):
    if event.get("need_report"):
        import heavy_report_lib  # 只有需要报表时才加载
        return heavy_report_lib.build(event)
    return quick_response(event)

这样，多数请求完全跳过了重量级依赖的加载成本。

3. 把初始化移到实例级别并复用

数据库连接、对象存储客户端、配置加载这些工作，应该在实例生命周期内只做一次，而不是每次请求都重做。把客户端定义在函数体之外，利用实例复用机制，让后续的热启动直接使用已经建好的连接：

import obs_client  # 模块级只创建一次

_client = None

def get_client():
    global _client
    if _client is None:
        _client = obs_client.create()
    return _client

def handler(event, context):
    client = get_client()  # 热启动时直接复用
    return client.read(event["key"])

需要注意：复用的前提是客户端本身是线程安全或在单并发下使用；连接数也要控制在数据库可承受的范围之内，不能为了复用而无限制地建连。

4. 调整内存配置，用实测说话

内存与 CPU 通常按比例分配，适当调大内存可以加快初始化速度，缩短冷启动时间。但内存越大，单次执行的计费也越高。建议的做法是：以 128MB 为起点，按 256MB、512MB 各测一轮，记录冷启动耗时与执行耗时的变化，选出耗时与成本的平衡点，而不是一次调到最大。

5. 对关键接口使用预留实例或定时保温

对于延迟敏感的接口，比如面向用户的登录、支付回调，可以用 FunctionGraph 的预留实例提前准备好一定数量的实例，让请求到来时直接有热实例可用。对于低频但要求稳定的定时任务，可以用定时触发器定期调用一次，让实例保持活跃。

这两招都要算成本账：预留实例按预留量计费，定时保温会产生额外的调用次数。只对真正延迟敏感的函数使用，不要给所有函数都加上。

6. 把流量削峰，减轻并发突增

冷启动最怕的不是总量大，而是短时间内的并发突增。把同步调用改成异步处理、让消息队列承接突发流量、给前端加上合理的重试与退避，都能把实例创建的压力摊平。流量曲线越平滑，需要同时新建的实例越少，用户遇到冷启动的概率也越低。

六、落地检查清单

• 部署包是否只包含运行时必需的依赖？
• 重量级依赖是否改成了按需加载？
• 数据库连接与 SDK 客户端是否在实例级别复用？
• 内存配置是否经过 128MB、256MB、512MB 三档实测对比？
• 延迟敏感的函数是否配置了预留实例或定时保温？
• 突发流量是否有队列或异步化承接？
• 超时时间是否按冷启动后的最慢情况留出了余量？
• 慢请求的排查是否先区分冷启动与下游耗时？

七、四个容易踩的误区

误区一：预热能解决一切。预热只能减少低频场景的冷启动，并发突增时仍需新建实例；把它当成万能药，会掩盖包体积与依赖加载的真正问题。

误区二：内存越大越好。内存超过需求之后，初始化速度的提升会趋于平缓，而费用会继续上升。没有实测数据的调参，只是换一种浪费。

误区三：把状态放在实例内存里。实例随时可能被回收，内存里的数据不可靠；会话、计数、缓存这类状态要放到数据库、缓存服务或对象存储里。

误区四：无限放宽超时。超时时间放得越宽，用户等待的时间就越长；真正该做的是压缩冷启动耗时，而不是让用户容忍更慢的响应。

结语

冷启动不是云函数的缺陷，而是按需模式的固有代价。处理它的正确顺序是：先确认慢请求是不是冷启动，再按成本从低到高逐项优化——瘦身部署包、延迟加载依赖、复用初始化成果、合理配置内存，最后才是预留实例与流量削峰。多数场景下，前三项做完，冷启动就能降到业务可以接受的水平。如果你的接口也遇到过偶发的慢请求，不妨按本文的检查清单逐项核对一遍，先找到时间花在了哪里，再决定从哪一项改起。