直接回答：冷启动发生在平台需要新建执行环境时：下载代码包、启动运行时、执行初始化代码（全局作用域、建立连接），之后才进入 handler。热启动直接复用容器毫秒级返回；冷启动视运行时和初始化量从几百毫秒到数秒。缓解手段分三层：减少发生概率（预留并发/provisioned concurrency、定时预热）、缩短初始化（精简依赖、延迟加载、选型轻运行时）、以及架构规避（关键路径不用函数或接受同步重试）。

展开解析：对症下药的思路：先量测——X-Ray/日志里 init duration 与 duration 分开看，确认冷启动占比再投入。缩初始化的具体动作：树摇和压缩部署包、把重初始化（SDK 客户端、连接池）放 handler 外只做一次、解释型运行时（Node/Python）天然优于 JVM（JVM 可选 SnapStart/CRaC 类快照方案）。预留并发用钱换确定性，适合用户面接口；事件驱动型任务（队列消费、ETL）通常无需优化——延迟不敏感。架构层面的判断：突发且稀疏的流量冷启动占比最高，平滑流量反而低；长稳高 QPS 服务用容器/虚机往往比函数更经济。冷启动不该是默认焦虑，先问业务对 P99 的真实要求。

追问方向：预留并发与自动扩缩如何互动？部署包大小与 VPC 接入各自增加多少延迟？SnapStart 的原理与限制？

（约 450 字）