冷启动是什么，为什么烦人
Serverless 云函数有一个绕不开的问题：冷启动。
函数一段时间没被调用，会被平台回收实例。下次再调，平台要重新拉起环境、加载你的代码和依赖——这个过程快则几百毫秒，慢则一两秒。
对小程序的实时交互场景（比如闯关提交答案后立刻出分），一两秒的卡顿体验是很伤的。
下面是我实际做的四个优化，把一次冷启动从约 2 秒压到了 300 毫秒左右。
优化一：砍依赖体积
冷启动要加载你的代码和依赖，依赖越多、越大，启动越慢。
做法：
- 只引真正用到的依赖，别把整个 SDK 全家桶都打进去；
- 能自己写的小工具函数，别为了省事引一个库；
- 定期审查
package.json，清掉死依赖。
这一项往往是收益最大、成本最低的。
优化二：复用数据库连接
很多人（包括曾经的我）会在每次函数调用里重新建数据库连接，连接建立的握手开销不小。
做法：把连接对象放在函数作用域外、模块级缓存，利用实例复用来复用连接。
这样同一个实例处理多次请求时，连接只建一次。
优化三：定时预热
冷启动的本质是"实例被回收了"。那能不能让它别被回收？
做法：用定时任务定期触发一次函数（比如每 5 分钟 ping 一次），让实例保持"温热"。
成本极低，但对"有固定流量、又不想为常驻付费"的场景很实用。
优化四：常驻实例（花钱换速度）
如果对延迟极度敏感，可以直接买常驻实例 / 预留并发，让函数永远有实例待命。
取舍：常驻要额外付费，适合对延迟要求高、且能覆盖成本的场景。多数情况下，前三步优化已经够用，别一上来就上常驻。
一个提醒：先量化，再优化
优化前，先搞清楚你的冷启动到底有多慢、占比多少。用监控面板看 p50 / p99 延迟，别凭感觉改。
我的经验顺序是：先砍依赖、再复用连接、够用了就停，还不够再考虑预热和常驻。
收尾
冷启动优化，本质是在"成本"和"速度"之间找平衡。多数场景下，砍依赖 + 复用连接这两个最朴素的优化，就能解决大部分问题。
这几个优化我在「面关」小程序的云函数里都用过，微信搜索「面关小程序」可以体验实际响应速度，前面关卡免费。
你被云函数冷启动坑过吗？有什么好用的优化手段？欢迎评论区交流。
