小程序云函数上线后，不少开发者会观察到一种现象：第一次调用某个云函数时耗时可能超过2秒，随后立刻再调用，响应却降到几百毫秒。这不是网络抖动，而是云函数冷启动在起作用。当函数实例长时间没有请求时，平台会回收计算资源；下一次调用到来时，系统需要重新分配容器、加载运行环境、读取代码包并初始化依赖，这个过程就是冷启动。冷启动无法完全避免，但可以通过预留并发让实例保持在线，以及通过层管理缩小代码包和依赖体积，从而显著压缩冷启动耗时。
冷启动到底慢在哪些环节
要优化冷启动，得先知道时间消耗在哪里。云函数实例的启动过程通常包含四个阶段：计算资源调度、运行环境初始化、函数代码和依赖加载、以及首次业务逻辑执行前的准备。计算资源调度由平台负责，开发者无法直接干预；运行环境初始化与选择的运行时和内存规格有关；代码和依赖加载则受代码包大小、依赖数量、层挂载情况影响。前三个阶段都属于冷启动开销。
热启动之所以快，是因为上一步已完成的实例被暂时保留，后续请求可以直接复用进程内的变量、连接池和模块缓存。平台通常会在函数空闲一段时间后回收实例，这就导致低频调用、定时任务、突发流量下的第一批请求更容易遭遇冷启动。值得注意的是，并发扩容时新创建的实例同样会产生冷启动，因此即使函数平时有稳定流量，流量突然增加时也可能有一批请求变慢。
以下是一个常见的云函数入口示例，在代码顶部引入了多个依赖。例子中 axios 和 lodash 都属于较重或中等的依赖，冷启动时加载它们会明显增加耗时。
// 云函数入口文件
const cloud = require('wx-server-sdk')
const axios = require('axios')
const _ = require('lodash')
cloud.init({
env: cloud.DYNAMIC_CURRENT_ENV
})
exports.main = async (event, context) => {
const res = await axios.get('https://api.ipipp.com/data')
const sorted = _.sortBy(res.data, ['id'])
return {
code: 0,
data: sorted
}
}
这类写法在功能上没有问题，但每次新实例启动都需要从磁盘读取这些模块并完成解析，对于几十 MB 的 node_modules 目录，耗时可能达到一两秒。优化冷启动的一个重要思路，就是把依赖加载和代码包体积降到最低。
预留并发：保持热实例随时待命
预留并发，也常被称为预置并发或保活实例，是云开发提供的一种实例保持机制。开启预留并发后，平台会为指定函数维持固定数量的实例常驻运行，即使没有请求也不会回收。当业务请求到来时，调度器会优先把请求路由到这些已经准备好的实例上，从而跳过资源调度和环境初始化阶段。
配置预留并发的方法通常位于云开发控制台的云函数管理页面，进入目标函数后可以找到预置并发或预留实例的选项。比如一个订单查询函数在每天上午 9 点到 11 点是调用高峰，可以在这个时间段内设置预留并发为 10，让 10 个实例提前处于热状态。高峰过后再把预留并发调低，避免空闲成本过高。
预留并发并不是设置得越大越好。预留实例在空闲时仍然会计费，尤其对于内存较高的函数，10 个预留实例一个月可能产生不小的费用。更合理的做法是结合云监控的调用量和冷启动比例，找到业务可接受的延迟与成本之间的平衡。通常优先给核心交易链路、高并发查询、定时任务等函数配置预留并发，而低频后台函数可以暂不配置。
配合预留并发，代码层面还需要把可复用的连接和客户端放到全局作用域，这样热实例一旦创建，后续请求可以不断复用，避免每次调用都重新建立数据库连接或创建 HTTP 客户端。下面是一个改造后的数据库连接示例。
const cloud = require('wx-server-sdk')
const mysql = require('mysql2/promise')
cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV })
let pool
async function getPool() {
if (!pool) {
pool = await mysql.createPool({
host: '127.0.0.1',
user: 'app_user',
password: 'your_password',
database: 'main_db'
})
}
return pool
}
exports.main = async (event, context) => {
const db = await getPool()
const [rows] = await db.query('SELECT id, name FROM users LIMIT 20')
return { code: 0, data: rows }
}
这段代码将连接池放在模块顶层，不会随每次函数调用重复创建。对于已经预热的实例，第一次请求会建立连接池，后续请求直接复用，不仅能降低冷启动延迟，也能减少数据库连接压力。
层管理：拆出公共依赖减少代码包体积
层（Layer）是把公共依赖、运行时扩展或自定义资源独立打包和版本化的一种机制。函数通过声明挂载某个层，即可在运行时访问层中的依赖，而无需把依赖打进函数自身的代码包。微信云开发控制台中，可以创建层并上传包含依赖的压缩包，然后将层绑定到一个或多个云函数。
使用层管理带来的第一个好处是代码包体积显著下降。假设一个项目有 5 个云函数都用到了 axios、lodash 和 moment，传统做法是每个函数的 node_modules 都包含这些依赖，导致每个函数包都超过 10 MB。改用层后，把公共依赖放在一个层里，函数自己的代码包可能只有几十 KB，部署更快，冷启动时读取和加载的文件也少得多。
创建层时需要注意目录结构。以 Node.js 运行时为例，依赖通常需要放在 nodejs 目录下并包含 package.json 和 node_modules。上传前可以先在本地整理好目录，然后打包成 zip。下面是一个层内容的目录示例。
layer-common-deps/nodejs/node_modules/axios layer-common-deps/nodejs/node_modules/lodash layer-common-deps/nodejs/package.json
绑定层之后，云函数代码可以像使用普通依赖一样直接 require，不需要修改包引用方式。例如函数中只写业务逻辑，axios 和 lodash 来自挂载的层。
const cloud = require('wx-server-sdk')
const axios = require('axios')
const _ = require('lodash')
cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV })
exports.main = async (event, context) => {
const res = await axios.get('https://api.ipipp.com/items')
const result = _.sortBy(res.data, ['publishTime'])
return { code: 0, data: result }
}
层管理也带来依赖版本统一的好处。多个函数共享同一个层版本时，不会出现 A 函数用 axios 0.21、B 函数用 axios 1.6 这种碎片化问题。升级依赖时只需要更新层版本，再调整函数绑定的层版本即可，维护成本明显降低。
组合优化与冷启动指标监控
预留并发和层管理并不是二选一的关系，实际项目中两者配合使用效果更好。层管理降低了冷启动时依赖加载的绝对时间，预留并发则减少了冷启动发生的次数。对于频繁调用的核心函数，可以同时开启预留并发并挂载公共依赖层；对于调用频率较低但偶尔有突发的函数，可以只使用层管理来减轻偶发冷启动的影响。
优化之后需要持续观察冷启动指标。云开发控制台通常会提供函数调用次数、平均执行时间、错误率等监控，结合日志中打印的初始化耗时可以大致判断冷启动占比。也可以在函数中埋点，记录模块加载到业务处理完成的时间，帮助评估优化效果。下面是一段简单的耗时记录代码。
const startTime = Date.now()
exports.main = async (event, context) => {
// 在热实例中，startTime 来自实例创建时；通过日志对比可观察冷启动额外耗时
const elapsed = Date.now() - startTime
console.log('elapsedSinceInstanceStart', elapsed)
return { code: 0, elapsed }
}
需要特别注意，这种测量方式在热实例中会因为实例存活时间较长而得到较大数值，因此更适合配合平台日志中的初始化耗时一起分析。不要单凭一个指标就判断冷启动已经消失。
最后还要避开几个常见误区。一是认为预留并发开启后冷启动就完全不存在，实际扩容超出预留数量时新实例仍会冷启动。二是层体积并非越小越好，层太大且包含大量无关依赖时，加载层本身也会增加耗时。三是把所有依赖都塞进层，导致层版本更新影响多个函数，变更风险被放大。合理规划依赖边界，按业务模块拆分两三个层，能让优化收益更稳定。
通过预留并发保持热实例、通过层管理降低依赖加载成本，再配合可复用的全局连接和持续监控，微信小程序云函数的大部分冷启动延迟都可以控制在可接受范围内。对于用户体验敏感的小程序，这些优化带来的响应提升会直接反映在转化率和留存上。