函数计算（FC）在事件驱动、流量波动大的场景非常香，但它不是万能药。理清适用边界，能少走很多弯路。
「Serverless 的适用边界与冷启动优化」并不是一个孤立的话题。Serverless 与函数计算同时牵动容量规划、网络划分、弹性伸缩与容灾边界等多个层面，只有把它们当作一个整体来推进，才能避免上线之后反复返工、被动救火。
适合的场景
图片 / 视频处理、Webhook 回调、定时任务、突发流量的轻量 API、异步解耦的任务。按调用计费，闲时几乎零成本。
不适合的场景
长连接、超长运行任务、以及稳定的高并发负载——这些场景常驻实例往往更省钱也更稳定。
冷启动优化
- 减小代码包体积，精简依赖，缩短初始化时间。
- 把初始化逻辑（建连接、加载模型）放到 handler 之外复用。
- 对关键路径用预留实例消除冷启动。
- 选择启动更快的运行时。
与容器结合
用 Serverless 容器（ASK / SAE）平滑迁移已有服务，兼顾弹性伸缩与改造成本，是从传统部署过渡的好选择。
小结：把 Serverless 用在"波峰波谷明显、事件驱动"的地方，收益最大；稳定重载负载别硬套。
冷启动要先量化，再决定优化手段
谈冷启动优化前先测清楚：在函数初始化阶段与业务入口分别打点，统计首次请求耗时的分位数（P50/P95/P99），区分「冷启动慢」与「业务本身就慢」，否则优化方向会错。
- 减负：精简依赖与部署包体积，把重初始化（连接建立、模型与配置加载）挪到实例复用周期内只做一次。
- 复用：数据库连接、HTTP 客户端、SDK 实例尽量复用，避免每次调用重建。
- 预留与按量配比：预留实例可消除冷启动但会产生常驻成本，按流量比例逐步放量，而不是一次全量预留。
- 触发方式：事件驱动与定时预热能显著改善体感，但要注意不要为了预热制造无效调用。
反向判断同样重要：当业务出现长连接、稳定高并发、需要精细调优运行时参数的特征时，说明这部分负载更适合常驻服务或容器形态。Serverless 的优势区间是波动大、事件驱动、单次执行短的任务，超出这个区间就该换形态而不是硬优化。
把Serverless 与函数计算放回架构全局来看
单点的最优解，叠加起来未必是全局最优。评估Serverless 与函数计算时，建议先明确业务的峰值模型与故障容忍度，再倒推资源与网络该怎么设计：哪些负载是稳定基线、哪些是突发流量、哪些可以容忍短暂中断，答案不同，架构取向也完全不同。
在此基础上再谈规格与参数，才有意义。否则很容易陷入「先买资源、再找用途」的被动局面，成本与复杂度都会随之上升。
落地前的自检清单
- 容量与规格：是否用真实压测数据而非经验估算来定规格，是否预留了弹性空间。
- 网络与边界：网段划分是否留有扩展余地，安全组是否遵循最小开放原则。
- 弹性与容灾：扩缩容策略是否经过演练，故障切换路径是否清晰、可回退。
- 可观测性：关键链路是否有指标、日志与告警覆盖，出问题能否快速定位。
这四件事做到位，Serverless 与函数计算才算真正「落地」，而不是停留在方案文档里。