上周跟几个做后端的朋友撸串，聊到最近把核心下单链路迁到Serverless之后，半夜被告警电话炸醒的破事。
不是系统挂了。是流量低谷缩容到零之后，突然来一波搜索流量，接口直接卡了1.2s，后台数据里堆了200多个排队的请求，直接触发了熔断。
很多人对Serverless的印象还停留在“不用管运维，按量付费，弹性随便扩”，真踩过坑才知道，冷启动这事儿，能把你之前省的所有运维成本，连本带利吐回去。
别再把锅全甩给运行时初始化
很多人一开始查冷启动慢的原因，第一反应就是运行时加载太慢。比如Node.js启动要几百ms，Python解释器加载要几百ms，加起来就快1s了。
真不是。
你把全链路的耗时拆解开看，平台调度资源、拉起虚拟机或者容器、挂载存储卷、拉取运行时镜像，这些环节加起来，有时候比你自己代码的初始化时间还长。
更坑的是，大部分人只会盯着运行时的启动时间优化，完全忽略自己业务代码里的初始化逻辑。我之前见过一个做内容平台的团队，把文章详情接口迁到Serverless之后，测出来冷启动要1.7s，查了半天才发现，他们代码启动的时候要加载一份全量的敏感词库，还要初始化一个本地的语义分析模型，光这两步就占了1.1s。
说白了，这部分锅，云厂商真背不动。你自己在启动的时候硬塞了一堆非必要的初始化逻辑，凭啥让平台给你提速？
那些看起来有效的优化为啥用不了
网上一搜Serverless冷启动优化，一堆教程教你怎么精简代码，怎么用预留实例，怎么搞预热。
没用的。
不是方法不对，是大部分方法都有你没明说的代价。
比如预留实例。这个方法确实能把冷启动的概率降到几乎为零——反正一直给你留着资源，不让它缩容到零。但代价是啥？成本。
之前有个做小电商的朋友算过，他们一开始迁Serverless就是为了省闲时的服务器成本，本来每天闲时的流量只有峰值的5%，按量付费的话一个月才几百块。结果为了消冷启动，按峰值的20%买了预留实例，算下来闲时的成本直接翻了10倍，比原来用的K8s集群还贵。
还有代码精简。把没用的依赖砍掉，用更轻量的运行时，这个确实能降冷启动时间。但很多老项目里的依赖都是祖传的，谁也不知道哪段代码藏着哪个没写文档的工具函数，砍完跑个三天出个线上bug，谁背锅？
还有所谓的“渐进式初始化”。把非核心的初始化逻辑延迟到第一次请求的时候再跑，美其名曰“降低启动耗时”。说白了就是把冷启动的成本转嫁给第一个倒霉的用户。我之前就见过一个团队这么干，大促当天第一个点进活动页的用户，等了3秒才看到页面，直接退出去找竞品了。这损失，比你省的那点成本贵多了。
真正有用的优化都是算过账的
我跟几个云厂商的架构师聊过，他们说大部分客户上来就要求冷启动压到50ms以内，问清楚业务场景之后，一半以上的需求都是伪需求。
比如你是内部的OA系统，一天到晚没几个请求，冷启动慢个几百ms，根本没人在乎。你花大价钱搞预留实例、搞快照优化，纯纯的浪费钱。
但如果是面向C端的核心交易接口，用户对延迟的容忍度可能只有200ms，那你就得算清楚账。
没必要全量预留。留个最小的预留池，比如1到2个实例，应对日常的突发流量就行。大促之前提前把实例预热好，把配置、依赖都加载完，等流量来的时候直接接请求。
还有那些启动时没必要做的事，能拆就拆。比如全量的配置文件，能不能只拉启动必须的部分，剩下的等请求来了再拉？数据库连接池，能不能用云厂商的连接代理，不用每次启动都重新建连？
现在很多云厂商推的快照恢复技术，确实能把冷启动时间压到100ms以内。就是把你已经初始化好的运行时环境存成快照，下次启动的时候直接从快照恢复，不用重新跑初始化逻辑。但这个也有代价——快照的存储成本不低，如果你代码改了，还要重新打快照，更新的链路也麻烦。要是你用的是带GPU的自定义运行时，快照体积几个G，拉取快照也要时间，根本不是万能的。
哦对，还有个小技巧。很多人不知道，Serverless平台的冷启动概率，跟你函数的部署地域也有关系。如果你把函数部署在离用户最远的地域，哪怕冷启动时间只有100ms，加上网络延迟，用户那边还是觉得慢。不如把函数部署到离用户近的可用区，哪怕冷启动多几十ms，整体的响应时间反而更短。
说白了，Serverless冷启动优化从来不是什么技术难题，就是个取舍的问题。你愿意花多少钱，换多少延迟的降低，你的业务能容忍多少的延迟波动，算清楚这些账，比你找一百个教程都有用。
别总想着找什么一劳永逸的银弹。真没有。