上周跟一个做电商的朋友吃饭，他说大促刚过，最头疼的不是流量不够，是零点刚开抢那三分钟，有近两成用户点了下单按钮，转了五秒圈，直接退了。查了日志才发现，七成报错全是Serverless函数的冷启动超时。
很多人对冷启动的认知还停留在“加载代码慢”，实际上这只是整个链路里最不起眼的一小段。
冷启动到底卡在哪 不是你想的那样
说白了，冷启动是从云平台收到你的函数请求开始，到第一个请求被正常处理完成的整个过程。中间要走的步骤包括：分配可用的宿主机资源、拉取对应的容器镜像、初始化运行时环境、加载业务代码、初始化所有业务依赖（比如数据库连接、缓存客户端、消息队列生产者）。任何一个环节卡壳，都会把冷启动时间拉长。
我之前见过一个团队，上来就把函数代码压到100M以内，省了不少拉镜像的时间，结果业务代码里初始化Redis连接的逻辑写在全局变量里，每次冷启动还要等连接池握手，平白多了300多毫秒。你说冤不冤？
很多优化的误区，就是盯着某一个环节抠，忘了整个链路是串起来的。比如你把镜像从500M砍到50M，省了两秒拉取时间，结果运行时选了个冷启动本来就慢的语言版本，那前面省的全白费。
最容易被忽略的是宿主机的资源争抢。云厂商的共享宿主机上，可能同时跑着十几个其他用户的函数，你申请的CPU和内存配额，有时候根本拿不到满额，初始化的时候被其他进程抢了资源，冷启动时间直接翻三倍。这事没几个人提，但每个用Serverless超过半年的人都踩过。
那些被吹上天的优化方案 算完账你可能不会用
现在大家提到冷启动优化，第一反应就是开预热实例。提前把函数实例保持在运行状态，流量来的时候直接用，根本没冷启动。听起来完美。
但麻烦在于，你预热的实例只要在跑，就要花钱。我见过一个团队，给所有峰值QPS过万的函数都开了预热，结果每月账单比之前多了60%。更坑的是，他们的流量只有大促当天那两个小时是峰值，其他时间预热的实例全在空转，钱花了，用户根本没感知。
预留实例的档位不是越高越好。比如你选了100个预留实例，结果当天峰值只用到40个，剩下60个全是白扔的钱。
还有人说用自定义运行时，把运行时和代码打包到一起，省了初始化运行时的时间。这个确实有效，但代价是你要自己维护运行时的安全补丁，出了漏洞云厂商不管，全是你的锅。你要是小团队，没专门的运维，根本玩不转。
那种按时间段设置预热策略的，比如早高峰9点到10点多预热几个实例，其他时间缩容到零。听起来很聪明，但你要考虑到，万一某一天用户提前一小时涌入呢？比如突然上了个热搜，8点就开始有流量，那预热的实例还没起来，冷启动直接把链路打崩。你说这风险谁担？
还有人说把函数拆成更小的粒度，减少单个函数的加载时间。对，拆小确实能降低冷启动的耗时，但拆得太碎，函数之间的调用链变长，每次请求要调五六个函数，网络开销加起来比原来的冷启动时间还长，这就是典型的捡了芝麻丢了西瓜。
不用烧钱也能落地的优化 都是细节里抠出来的
先别上来就买预留实例，先把你所有函数的冷启动耗时测一遍，别凭感觉。很多人连自己的函数冷启动要多久都不知道，上来就优化，纯纯瞎搞。
比如你测下来，发现拉镜像只占10%的时间，初始化业务依赖占了70%，那你就别浪费时间去抠镜像大小了。把全局初始化的逻辑做懒加载，改几行代码的事，就能省掉很多没必要的初始化时间。比如你函数里只是处理个webhook的文本校验，没必要一上来就初始化MySQL连接，等真的需要写库的时候再连就行。
还有个小技巧，把你常用的公共依赖，比如日志组件、监控组件，打到基础镜像里，这样所有函数拉镜像的时候，不用重复拉这些公共层，拉镜像的时间能省掉不少。这个也不用加钱，就是要跟云厂商的默认镜像对齐，别自己瞎改。
我见过最离谱的，一个处理webhook的函数，里面装了整个TensorFlow，问他为什么，他说之前写代码的时候不小心装的，忘了删。你说这不是搞笑吗？就这种镜像，冷启动能快才怪。
如果你真的要开预热，别上来就给所有函数开。先挑那些对延迟敏感的，比如用户下单、支付的接口，这些接口冷启动超时直接影响营收，开预热值得。那些后台跑的定时任务，比如每天凌晨备份数据的，冷启动多等几秒根本没人在意，就没必要开预热，白花钱。
上次跟那个电商朋友聊完，他回去把所有支付相关的函数的初始化逻辑改了，懒加载了不必要的数据库连接，又给这几个函数开了刚好匹配峰值的预热实例，这次大促的冷启动超时率从3%降到了0.2%，每月账单只多了不到10%。
说白了，Serverless冷启动优化根本不是什么高深的技术。别光听厂商吹，也别光看网上的最佳实践，先把自己的链路摸清楚，算清楚每一分钱的代价，比啥都强。