本文详解如何通过 runwith() 方法在代码中声明式地配置 firebase cloud functions 的超时时间（timeoutseconds）和内存（memory），确保部署后配置不被重置，彻底解决 function execution took 60000 ms 错误。
Firebase Cloud Functions 默认采用保守的资源限制：60 秒超时 + 256 MB 内存。当函数执行耗时超过 1 分钟（例如处理批量数据、调用外部 API 或执行复杂计算），日志中将出现 Function execution took 60000 ms, finished with status: ‘Error’，函数强制终止。
⚠️ 注意：在 google Cloud console 手动修改函数的 timeout/memory 设置仅是临时操作——一旦执行 firebase deploy –only functions，Firebase CLI 会依据源码中的配置（或默认值）覆盖控制台的修改，导致配置“回滚”。因此，必须将资源配置内聚到函数定义代码中，实现真正意义上的“永久生效”。
✅ 正确做法：使用 runWith() 声明资源配置
从 Firebase SDK v3.20.0+（对应 Functions SDK v1）起，所有触发器类型（http、Callable、Pub/Sub、Scheduler 等）均支持 runWith() 方法，用于显式指定运行时参数：
import * as functions from "firebase-functions"; export const myfunction = functions.pubsub .schedule("*/5 * * * *") .runWith({ timeoutSeconds: 500, // 最长执行 500 秒（约 8.3 分钟） memory: "512MB", // 分配 512 MB 内存 }) .timeZone("UTC") .onRun(async (context) => { await main(); // 你的业务逻辑 });? 关键点：runWith() 必须紧接在触发器构造器之后、.onRun()/.onCall() 等处理器方法之前调用，否则将抛出类型错误或运行时异常。
? 支持的资源配置项（v1 函数）
| 参数 | 类型 | 可选值示例 | 说明 |
|---|---|---|---|
| timeoutSeconds | number | 90, 300, 540 | 范围：9s–540s（9 分钟），不可设为 0 或超过 540 |
| memory | string | “128MB”, “512MB”, “1GB”, “2GB” | 必须为标准规格字符串（区分大小写），不支持 “512mb” 等小写形式 |
| minInstances / maxInstances | number | 0, 1, 10 | （可选）控制实例伸缩范围，避免冷启动或成本失控 |
⚠️ 注意事项与最佳实践
- 版本兼容性：runWith() 仅适用于 Functions SDK v1（即 firebase-functions@^3.x）。若仍在使用 v2（firebase-functions@^4.x），语法保持一致，但需确认项目已正确迁移至 v2 运行时（v2 默认启用更高并发与更优性能）。
- 配额与计费：增加 timeoutSeconds 和 memory 会直接影响费用——费用 = 内存 × 执行时间 × 次数。建议按需设置，避免过度分配（例如无需 2GB 内存时勿设 “2GB”）。
- 调度函数特殊性：使用 functions.pubsub.schedule() 的函数本质是 Pub/Sub 触发器 + 后台定时任务，其 runWith() 配置完全生效，与 HTTP 函数无异。
- 本地调试：firebase emulators:start 会尊重 runWith() 中的 timeoutSeconds，但部分旧版模拟器可能忽略 memory；生产环境始终以部署配置为准。
✅ 验证部署结果
部署后，可通过以下方式确认配置已生效：
- 查看 Firebase CLI 输出日志，搜索 timeoutSeconds 和 memory 字样；
- 进入 Google Cloud Console → Cloud Functions，点击函数名称，在 “Runtime” 标签页查看 Timeout 和 Memory allocated；
- 在函数详情页的 “Source” 标签中确认 runWith 配置存在于源码中（证明非手动修改）。
通过将资源配置内聚于代码，你不仅实现了配置即代码（git 可追踪、CI/CD 可审计），更从根本上杜绝了因人工操作导致的配置漂移问题。这是现代 serverless 工程实践的核心准则之一。