Workers 的 CPU 时间和墙钟时间有什么区别？

一个请求花了 2 秒等上游接口返回，Worker 自己消耗的 CPU 时间可能只有几毫秒。反过来，一次同步的大 JSON 解析，墙钟时间很短，CPU 却可能顶到上限。

所以两者是两个不同的计量：CPU 时间只算你的代码真正在算的时间，墙钟时间是一次调用从开始到结束的总经过时间，含等待。 等待 fetch()、KV 读取、数据库查询不计入 CPU 时间，但计入墙钟时间。

限额分别卡在这两个量上，所以“响应很快”不等于“CPU 够用”。下面按你接着会问的顺序，把数字、报错和省 CPU 的方向讲一遍。

哪些时间算 CPU，哪些只算墙钟？

按官方限额页的口径：CPU time 是 CPU 真正执行你代码的时间；wall time 是一次调用从开始到结束的总经过时间。

  • 算 CPU：同步的大块计算，比如加密循环、整体缓冲后再解析的大 JSON。
  • 只算墙钟：等待 fetch() 返回、等待 KV 读取、等待数据库查询。

也就是说，await fetch() 的等待不消耗 CPU 额度，但会拉长墙钟时间，也会拉长客户端的等待。

限额具体是多少？

以下是 2026-10 官方限额页的数字，会变化，写代码前请重新核对：

  • HTTP 请求 CPU 时间：Free 10 ms；Paid 默认 30 秒，通过 limits.cpu_ms 最多配置到 5 分钟（300000）。
  • Cron Trigger CPU 时间：Free 10 ms；Paid 30 秒（间隔小于 1 小时）或 15 分钟（间隔 1 小时及以上）。
  • 墙钟时间：HTTP 请求无限制；Cron、Queue 消费者、DO alarm 为 15 分钟。
  • 每个 isolate 内存 128 MB。
  • 每次调用同时“等待响应头”的外发连接 6 个，第 7 个排队，等其中一个收到响应头。
  • Startup 1 秒。
  • waitUntil 在响应之后最多 30 秒，见 响应返回之后，Worker 里的代码还能继续跑吗。

“HTTP 墙钟无限制”不等于连接永远不断，客户端或中间链路可能先断开。断开时 Worker 能不能感知，见 Worker 怎么感知客户端断开连接。

超出 CPU 限制会看到什么？

客户端收到 Error 1102，信息是 Worker exceeded resource limits，分析里对应 exceededCpu。Workers Logs 与 Tail、Logpush 可以看到每次调用的 CPU 与墙钟时间。

怎么省 CPU？

官方给的方向是几条，我按顺序用：

  1. 避免在 handler 内做大块同步计算。
  2. 流式处理大响应体，而不是整体缓冲再解析。
  3. 先看 exceededCpu 的比例，再决定要不要提高 limits.cpu_ms。

别一上来就调大上限，先确认超限到底是不是常态。

本地跑通，线上就不会超限吗？

不能这么认为。我在本地 wrangler dev 上没有看到 CPU 限额被执行，所以本地跑通不代表线上不会撞到 CPU 限制。CPU 相关的问题，只能靠线上的 exceededCpu 和日志来看。

这里的 CPU 与墙钟口径、全部限额数字、Error 1102 与 exceededCpu 的对应关系，来自官方限额页，我没有在本地复现，数字会变化，以 2026-10 官方文档为准。本地 wrangler dev（workerd，wrangler 4.151.3）不会执行 CPU 限额，这一点我确认过。