很多服务在基准测试中表现亮眼，但一遇到真实流量峰值就立刻卡顿甚至超时。原因往往不在平均响应时间，而在于冷启动延迟被刻意隐藏了。 所谓 warm latency，是指实例已经预热、资源已分配时的处理速度；而 cold-start latency 则要额外承担初始化环境、加载依赖、建立连接等开销。这两者可能相差数倍甚至一个数量级。 更关键的是并发数学：假设单个实例冷启动需要 2 秒，每秒到达 10 个新请求，那么预热实例只能覆盖其中一部分，剩余请求必须等待新实例完成启动。如果压测时只测单个请求的延迟，完全看不出问题；一旦流量突增，冷启动排队会迅速放大响应时间。 因此，真正可靠的性能评估不能只看基准数字，必须把冷启动频率、并发请求量、实例伸缩速度一起计算。否则，你看到的“快”只是实验室里的假象，而用户遇到的“慢”才是现实。