Cloudflare Workers性能剖析上线：生产环境火焰图直查CPU与内存

Cloudflare 给 Workers 和 Durable Objects 加上了按需采集的 CPU 与内存性能剖析能力，开发者能用交互式火焰图排查生产环境里的性能瓶颈。这项功能在 2026 年 10 月 9 日发布，入口有两个：Workers Observability 控制台和 cf CLI，生成的火焰图可交互查看，帮团队锁定吃资源的函数和内存分配，不用再只盯着日志和汇总指标。

采集对象是已经部署的 Worker 版本，CPU 或堆内存分配数据都能抓，结果以火焰图呈现。图里某一块越宽，说明对应函数占的 CPU 时间越多，或者采样到的内存分配占比越高。剖析数据支持下载，拿去做离线分析也行。

和常见的做法不同，它剖析的是已经在跑的隔离实例，不会另起一个新实例，因此开发者看到的就是真实生产流量下执行的代码。Durable Objects 也能指定某个实例单独剖析，方便查有状态工作负载相关的问题。前提是目标实例在采集期间得有足够流量经过；另外 TypeScript 开发者最好开启源码映射，函数名会好认一些。

难点在于 Workers 散布在 Cloudflare 各处边缘基础设施上，同一份脚本可能在多个数据中心、多台物理机器上跑着多个隔离实例。剖析请求先要认准所需的 Worker 版本，再找到合适的活跃隔离实例。Durable Objects 更麻烦一层：它有状态，还可能在不同位置之间迁移，Cloudflare 的做法是把剖析请求路由到托管指定对象的那台机器。

采集全程并不会一直占着隔离实例锁。做 CPU 剖析时，运行时先拉起一个按 1 毫秒间隔采样的 V8 性能分析器，然后就把锁放开，让请求接着跑；等剖析结束、收集结果时再把锁拿回来。这样平台能观察实时执行情况，采集期间正常的请求处理不用停下来。

CPU 剖析和内存剖析回答的并不是同一个问题。前者靠采样调用栈，看出执行时间花在哪，帮人找出耗时多的函数、重复计算和可以优化的地方；后者则把与函数相关的内存分配标出来，让开发者找到那些创建对象过多、加重内存压力的代码。

这个区别在诊断性能问题时很关键：有的函数 CPU 吃得厉害，内存却几乎不分配；有的函数内存分配一大堆，却不是执行时间的主要来源。对着相应的剖析数据看，能把调查范围收窄到真正的资源瓶颈上。

Cloudflare 自己在内部就用它找出了多余的计算和内存开销。团队剖析一个使用 R2 绑定的 Worker 时，发现有个递归 JSON 替换函数反复遍历嵌套数据，干了不少多余的活。据称改完实现后，这个函数的运行速度提升到原来的 2.7 倍。另一份剖析数据则揪出一次不必要的重复指标调用，约占 CPU 时间的 1%。

内存剖析还翻出了另一个问题：据称部分已被禁用的 Prometheus 插桩代码仍在大量占用内存。Cloudflare 称，把剩余代码清掉后，这个 Worker 的第 99.9 百分位内存使用量从 133 MB 降到 118 MB，落到了 128 MB 的限制线以下。

这项功能是补足现有工具，而非取代它们。Chrome DevTools 能做本地 CPU 性能剖析，开发阶段用着合适，可生产流量和数据往往难以复现。pprof 在 Go 及其他受支持的性能剖析流程里用得很多，离线剖析数据分析能力很强，Cloudflare 也允许用 pprof 查看下载下来的剖析数据。Cloudflare 这项功能的不同之处在于，从平台现有的运维界面就能对正在运行的 Workers 和 Durable Objects 发起剖析。

它同样补上了日志、指标和分布式追踪的空缺。那几样工具能帮人发现服务何时变慢、何时资源消耗过多，剖析数据则能进一步指出是哪个函数该负责。几种手段配合起来，对应用运行状况的把握会更完整。

按需采集不等于持续监控。剖析窗口偏短的话，间歇性问题可能被漏掉；堆内存剖析记录的是采集期间的分配情况，并不能完整反映留存内存。Cloudflare 表示正在推进持续性能剖析，目标是让罕见的性能问题更容易查，不用事先猜它什么时候冒出来。

对在 Cloudflare Workers 上跑生产负载的团队来说，这次发布多了一项实用的调试手段：不必先在本地复现问题，就能从发现资源压力一路查到造成问题的代码。