结论：FaaS（Lambda/Cloud Functions）适合事件驱动、流量波动大、低频或突发型负载——定时任务、Webhook、文件处理流水线、低频 API；按调用计费到毫秒，零流量零成本，免运维扩缩容。不适合：延迟敏感的热路径（冷启动）、长任务（执行时限通常 15 分钟级）、稳定高流量（单价反超常驻实例）。
展开：隐性成本清单：1）冷启动——语言运行时 + 依赖初始化造成百毫秒到秒级延迟，VPC 内函数历史上有额外 ENI 建立开销；缓解靠 provisioned concurrency（付费保温）、精简依赖、选快运行时（Rust/Go 优于 JVM）；2）状态管理外移——函数无本地状态，会话/缓存/队列都要买托管服务，架构被云厂商服务网格化，锁定加深；3）观测与调试——传统 APM agent 模式失效，本地复现困难，需要结构化日志 + X-Ray/OTel 专门链路；4）成本结构反直觉——API 网关、NAT、日志（CloudWatch 常是账单大头）等周边服务费用可能数倍于函数本身；稳定高 QPS 场景容器化部署通常便宜数倍。决策框架：流量曲线（波动大→FaaS）、延迟预算（P99 < 100ms 慎选）、团队规模（小团队免运维红利最大）。易错点：把 FaaS 当省钱银弹，忽略高并发下按次计费与预留实例的交叉点测算。
追问方向：Knative 如何在 K8s 上自建 FaaS 体验（scale-to-zero 的冷启动权衡）、边缘函数（Cloudflare Workers）的 isolate 模型为何没有传统冷启动。