2.4 云函数与托管心得：冷启动、区域与部署节奏

云函数和托管是四大件里的“工程件”：逻辑不难，难的是运行时机、地理位置和发布节奏这些工程细节。这一节讲的都是长期项目中反复验证过的手感。

冷启动：低频函数的第一声咳嗽

云函数是事件驱动的：HTTP 请求能触发、数据库文档变化能触发、定时器也能触发，按调用次数和运行时长计费，具体价格以官方文档为准。听起来很美，但有一个绕不开的物理现实：实例不是常驻的。 一段时间没人调用，实例被回收，下一次调用就要现场拉起环境，这就是冷启动。

低频函数的冷启动最疼——比如每天只跑几次的统计接口，用户每次都可能赶上“第一声咳嗽”，等待明显变长。我的应对经验，按场景分三种：

保活要权衡：定时唤醒能压住冷启动，但这引入了持续成本和额外调用次数，值不值要看业务对延迟的真实敏感度，别无脑上。

我的总原则：先量化，再优化。 用日志看清函数真实的调用频率和延迟分布，大部分情况下你会发现冷启动没有想象中可怕。

区域选择：一开就定的事

函数区域离谁近很重要。两个原则：

• 函数要离数据库近。 函数和 Firestore 之间每次交互都走网络，跨区域等于每次数据库操作都叠加跨洋延迟，一个函数里循环读写几十次，延迟是灾难性的。函数区域尽量和数据库区域一致。
• 建库区域一开就定。 Firestore 的区域创建后不能改，选区前想清楚用户主力在哪里。函数以后还能换区重部署，数据库搬家几乎等于重做。

区域是典型的“决策成本五分钟，返工成本一个月”的事项，项目立项时就该定下来。

部署节奏：模拟器、低峰、可回滚

部署出过几次事故后，我固化了一套节奏，核心是三句话：

• 先在本地模拟器跑通。 模拟器套件能在本地把函数和数据库整套装起来，部署前跑一遍核心路径，大部分低级错误（拼写错路径、规则没同步）就地拦截。
• 生产部署选低峰期。 函数部署期间存在切换窗口，别在业务高峰动手，深夜或清晨的十几次部署换不来用户的十几次报错。
• 回滚靠版本。 部署出问题别现场救火改代码，回滚到上一个正常版本先止血，再慢慢查。这也是为什么每次部署前要确认上一个版本是可用的。

Hosting 缓存心得

Hosting 负责静态站点与 CDN，还能配重写规则把某些路径转给云函数，前端路由和 API 能挂在同一个域名下，省掉跨域配置。缓存是 Hosting 的心得重点，一句话口诀：静态资源长缓存，HTML 短缓存。

带哈希指纹的 JS、CSS、图片可以放心配长缓存，内容变了文件名就变；HTML 是入口，缓存久了用户会停留在旧版本上引用已被删除的资源，所以要短缓存或不缓存。配重写规则时留意优先级，路径匹配顺序不对，请求会落到意料之外的后端。

本节小结

云函数与托管的心得都是工程纪律：冷启动先量化再优化，区域跟着数据库走且开库即定，部署走模拟器、低峰、可回滚三步，缓存按资源类型区别对待。这些细节单个都不起眼，合起来决定了项目上线后你是睡觉安稳还是半夜被叫醒。