在函数计算这类Serverless平台上，多次调用之间运行环境并不保证一定会被复用，代码必须具备无状态设计思维，任何依赖本地内存、临时文件或进程内缓存的逻辑都可能在下次调用时彻底失效。
函数计算冷启动为什么这么慢：核心原因是运行环境没有“活着”等你
刚接触Serverless的同学,几乎都经历过同一个困惑：第一次调用函数，响应等了老半天；紧跟着再调一次，瞬间返回，于是不少人得出结论：我的函数第二次跑得更快了，其实第二次快，不是因为你的代码优化得好，而是平台把第一次运行的环境顺手保留了一会儿，直接拿来处理新请求。
但这份“顺手保留”不是白纸黑字的承诺，平台出于成本控制，会在实例空闲一段时间后回收环境，据主流云厂商公开的产品文档，函数实例的空闲保留策略各不相同，短则几分钟，长则几十分钟，一旦被回收，下一次请求就得重新走一遍完整流程：分配沙箱、下载代码、加载运行时、初始化依赖，这个从零开始的阶段，就是用户常说的“冷启动”。
冷启动之所以慢,主要有三个环节拖后腿，代码包体积大，解压加载耗时；运行时初始化重，比如Java的JVM、Node.js的依赖加载；业务代码里还有全局初始化逻辑，每次新实例都要重复执行一遍，业内专家指出，冷启动的耗时通常比热启动多出一个数量级，这一差距在大依赖项目中表现得尤其明显，换句话说，你感受到的“慢”，不是平台故意刁难，而是环境不再听你使唤。
搞清楚了这个背景,再看一个更扎心的事实：平台内部的调度策略你摸不透，就算实例没超时，负载均衡也可能把新请求分给一个刚创建的新实例，你以为自己在和同一个“人”对话，实际上对面已经换人了。
环境不保留带来的坑：全局变量、临时文件与连接池
运行环境不保证复用,最直观的后果就是你写在函数里的“本地状态”全都靠不住，下面这几个场景，基本覆盖了大多数初学者的踩坑现场。
全局变量：只是当前调用的一次性便签
很多人习惯把用户会话、IP黑名单、配置字典塞进全局变量里，想着“反正实例一直在，下次直接用多省事”，但环境一旦被回收，所有全局变量归零；就算实例还在，同一实例上的多个请求也会共享这份数据，A用户的数据可能被B用户读到。
举个具体例子：一个简单的访问频率限制函数，把请求IP存进全局数组，第二次调用时发现数组空了，限流直接失效，更麻烦的版本是，同一个实例同时处理多个请求，全局数组被并发写坏，数据张冠李戴，这不是代码bug，而是平台取回了你的“草稿纸”。
临时文件、连接池：建好不等于能一直用
函数计算也支持写本地磁盘,但可写目录通常只有/tmp，而且这份存储空间不保证持久，写进/tmp的文件，可能在下次调用前就被平台清了，连个招呼都不打，至于数据库连接池，如果你在全局初始化里建了十个连接，实例回收后全部白建；新实例冷启动时还得重新连一遍数据库，连接时间直接叠加进请求耗时。
避免把所有重复工作都堆在每次调用里
还有一个隐蔽的坑：为了防冷启动，有人把初始化逻辑写成惰性加载，每次请求先检查全局变量是否存在，不存在就重新构建，这种做法本身没问题，但如果你把初始化做得太重，比如加载一个几百MB的机器学习模型，那么每次冷启动都会让用户等上好几秒，平台对运行时的限制是“尽力而为的复用”，不是“永久托管”，所以任何沉重的本地资源都不该被当作常驻服务来依赖。
Serverless多次调用环境不保留怎么办：无状态改造的实操步骤
既然环境不保证存活,那就把“有状态”的包袱从函数里卸掉，改造思路不复杂，无非是状态外置、数据持久化、请求幂等这三件事。
第一步：状态和缓存全部搬进外部存储
业务数据、会话记录、临时计算结果，凡是需要跨请求保留的东西，一律放到Redis、数据库或对象存储里，比如之前那个IP限流案例，把访问记录写进Redis，带上过期时间，每次请求都从Redis读计数，而不是从全局变量里碰运气，这么做有三个好处：实例被回收不影响数据，多个实例之间能共享状态，并发场景下行为可预期。
第二步：把/tmp当成一次性草稿，而不是仓库
/tmp目录适合存放单次请求的中间产物，比如下载后转码的临时文件，处理完就要及时删除，或者让文件系统“自生自灭”，不依赖它在下次调用时还在，写代码时，对临时文件的路径做好唯一命名，避免不同实例之间的文件冲突。
第三步：连接管理遵循“短连接、可重试、幂等写”
数据库连接池不是不能用,而是不要假设它能存活，你可以设计一个懒加载的连接管理器，检测到旧连接失效就自动重建，业务逻辑要做幂等设计：同一个请求被重试多次，结果仍然一致，比如支付回调函数，先查订单状态再更新，而不是无条件执行扣款操作。
下面用一个表格把“有状态写法”和“无状态改造”放一起对比，方便照着改：
| 场景 | 有状态写法（容易翻车） | 无状态改造（推荐） |
|---|---|---|
| 用户会话 | 存全局变量 | 存Redis，携带会话ID访问 |
| 图片临时裁剪 | 写/tmp文件名固定 |
文件名带UUID，用后即删 |
| 数据库连接 | 全局连接池 | 懒加载+连接失效重试 |
| 配置读取 | 进程内缓存 | 外部配置中心或环境变量 |
| 调用计数 | 全局计数器 | Redis原子自增操作 |
第四步：冷启动优化要趁早
针对前文说的冷启动慢,能做的优化不少，精简代码依赖，把打包体积降下来；避免在全局作用域写耗时逻辑，改用用户请求处理器内按需初始化；如果业务对延迟极度敏感，也可以考虑平台提供的预置并发功能，提前拉起一批实例候着，但这些优化只是降低冷启动的影响，并不能换来“环境一定复用”的保证。
函数计算 vs 容器服务：状态化应用到底放哪
有的团队在改造过程中会发现,某些业务无论如何都难以无状态化，比如长连接服务、本地文件处理流水线，这时候，与其硬塞进函数计算，不如倒回去看看普通云服务器或容器服务，对比一下两种部署方式的特点：
- 函数计算：自动扩缩容、按调用计费、冷启动存在、状态不保留。
- 容器服务：实例常驻、本地状态可持久、手动或自动伸缩、成本按资源规格持续计费。
怎么选？看业务特征，流量波动大、单次处理时间短、逻辑可拆分，优先考虑函数计算，服务需要长时间运行、频繁读写本地磁盘、对启动延迟零容忍，选容器服务更省心，有些团队的做法是两套混用，核心服务跑在容器上，边缘事件处理交给函数计算，各取所长，函数计算最适合的场景，永远是短平快的任务，而不是一个需要长期守夜的“看门人”。
多次调用环境不保留，新手最常见的几个疑问
为什么我的函数第二次调用时全局变量里的数据没了？
因为第二次调用可能被调度到一个全新创建的实例上,平台保留了上一个实例不等于一定会把后续请求继续分给它；即便分给它，实例空闲超时后也会被回收，全局变量只存在于实例的内存中，实例没了，数据自然就没了，所以不要依赖全局变量保存跨请求的数据，需要保留的状态请放进外部存储。
把数据写在/tmp目录里，下次调用还能读吗？
理论上,只要实例没被回收且没触发磁盘清理，就能读到，但平台不保证这一点，/tmp也可能被其他请求写入干扰，所以它只适合存单次请求的临时文件，跨请求保留的数据，放到对象存储或数据库里更稳妥。
函数一直有请求，还会不会遇到冷启动？
即便请求连续不断,平台也可能因为自动扩缩容创建新实例，新实例必然经历冷启动，只是并发请求多时，存量实例被复用的概率更高，冷启动影响被稀释了，为了保证整体延迟稳定，可以提前预热，但无法彻底杜绝冷启动。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/638164.html
