上次跟一个做电商技术的朋友撸串，他拍着烤腰子跟我吐槽，大促零点那波流量冲上来，Serverless函数死活起不来，用户点个结算页转半分钟，直接掉了两成下单。
别扯那些虚的。
你以为的冷启动，根本不是真问题
很多人一提到Serverless冷启动优化，上来就说要从内核层面把启动速度压到极致。麻烦在于，冷启动的耗时从来不是单环节堆出来的——容器镜像拉取、运行时初始化、业务代码加载、依赖解压、连接池建立，每一段的耗时占比，换个业务场景就完全不一样。
我见过有人为了优化冷启动，跟着厂商的文档做了半天内核参数调整，最后发现自己的函数包打了400多兆，70%的冷启动时间都在等镜像解压。纯纯找错方向。
真的别上来就拿通用模板套。你一个轻量的Python接口，冷启动慢可能是因为运行时加载了多余的科学计算库；你一个Java函数，冷启动慢可能是Spring的自动配置扫了太多类；你一个定时触发的日志清理函数，冷启动慢根本不影响任何用户，费那劲优化干嘛。
很多人踩过的坑更离谱：为了消掉所有冷启动，把所有函数都开了常驻实例，月底账单出来，比之前用ECS还贵三倍。我当时盯着那账单愣了五分钟。
真能落地的优化，全是带着代价的交换
现在没人跟你明说的一点是，所有的冷启动优化本质都是成本和体验的交换，没有零成本的解法。
最常用的预置并发，说白了就是你提前把烘热的容器摆在那等着接请求，但这部分资源哪怕没流量，也是要照价付费的。你要是不管不顾给所有函数都开上预置，哪怕那些几个月才触发一次的定时任务，空转的成本能把你吓一跳。
我见过最聪明的做法，是把预置并发和历史流量曲线绑在一起。比如核心交易接口，在流量波峰前10分钟自动拉起预热实例，波峰过了立刻把超出的实例缩回去，根本不用24小时开着。
还有些几乎零成本的优化，很多人懒得做。比如把函数包里根本用不上的依赖全删掉，有人把Java函数的依赖从400MB砍到30MB，冷启动直接从3秒掉到400ms。这事没那么玄，就是别图省事把整个开发框架都打进去，用啥引啥。还有连接池预热，很多函数冷启动慢根本不是代码跑不起来，是等请求来了才开始跟数据库握手、等Redis鉴权、跟下游接口做证书校验，你在函数初始化阶段就把这些连接提前建好，能省下来近一半的等待时间。
当然也别太走极端。我见过最离谱的团队，为了省那点预置的钱，硬生生把核心支付链路的冷启动压在2秒，用户每次点支付都要转两圈，那点省下来的算力钱，还不够客服处理投诉的零头。
别被厂商的宣传话术绕进去
现在刷技术博客，总能看到云厂商吹自己的Serverless冷启动能压到几十毫秒，你真拿自己的业务代码上去测，根本不是那回事。人家测的是什么？是打印个hello world的空函数，没有依赖，没有外部连接，没有业务逻辑，那当然快。你把自己那堆几十兆的业务包传上去，该3秒还是3秒。
说实话，厂商的公开冷启动测试数据，从来不会适配你的真实业务。
你也不用追求把冷启动压到极限。核心链路的接口，比如用户下单、支付，冷启动控制在300ms以内就够了，再往下压，边际成本高到离谱——你要从300ms压到100ms，可能要多花三倍的预置成本，带来的体验提升，普通用户根本感知不到。那些非核心的链路，比如日志处理、图片转码、离线报表，冷启动哪怕2秒，又有什么关系？根本不影响用户操作。
上次跟那个撸串的朋友复盘，他最后按这个思路调整完，核心链路的冷启动稳定在200ms上下，整体账单比之前全量常驻的时候少了60%。
没有什么万能的优化公式。
你要做的从来不是把冷启动压到最低。是算清楚每多压10ms，你要花多少钱，换回来多少用户留存。
对了，昨天还有人问我，是不是Serverless就天生适合所有场景。
拉倒吧。