线上 Worker 变慢却复现不了？Cloudflare 让你直接剖析生产环境

“线上慢，本地复现不了”是后端工程师最熟悉的困境之一。日志告诉你请求变慢了，指标告诉你资源占用上去了，但没人能指出是哪一行代码干的。Cloudflare 这次想解决的就是最后这一步。

一分钟速览

• 可针对已部署的 Worker 版本采集 CPU 或堆内存分配剖析数据
• 结果以火焰图呈现，越宽表示该函数占用的 CPU 时间或内存分配比例越高
• 剖析数据支持下载，可用 pprof 等工具离线分析
• Durable Objects 支持针对指定实例剖析，便于排查有状态负载
• CPU 剖析使用 1 毫秒间隔的 V8 采样器，采集期间不长时间持有实例锁

为什么”生产环境剖析”很难

传统做法是在本地或预发环境跑 profiler，但生产流量很难被完整模拟。Cloudflare 的方案是把剖析对象换成正在运行的隔离实例，而不是新起一个实例。这样采集到的就是真实流量下的执行路径。

难点在于 Workers 分布在边缘各处：同一个脚本可能在不同数据中心、不同物理机器上运行多个隔离实例。剖析请求必须能识别目标 Worker 版本，并找到一个合适的活跃实例。Durable Objects 更麻烦，它们有状态，还可能在不同位置之间迁移，平台需要把请求路由到托管指定对象的那台机器上。

实现上的取舍也值得一提。运行时不会在整个采集过程中一直持有隔离实例锁：CPU 剖析启动采样器后即释放锁，让请求继续执行；结束采集时再重新获取。这样平台能观察实时执行，而不必暂停正常请求处理。

CPU 和内存回答的是两个问题

CPU 剖析通过采样调用栈，揭示执行时间花在哪里，帮助找出耗时函数、重复计算和优化机会。内存剖析则突出与函数相关的内存分配，帮助定位创建过多对象、加重内存压力的代码。

两者的区别在诊断时很关键：一个函数可能吃掉大量 CPU，却几乎不分配内存；另一个函数可能产生大量分配，但不是执行时间的主要来源。先看哪张图，取决于你怀疑的是算力瓶颈还是内存瓶颈。

内部实测的两个例子

Cloudflare 自己用这套工具做了两轮优化。第一轮针对一个使用 R2 绑定的 Worker，剖析发现一个递归 JSON 替换函数反复遍历嵌套数据，做了大量重复工作。修正实现后，该函数运行速度提升到原来的 2.7 倍。

第二轮发现一次不必要的重复指标调用，约占 CPU 时间的 1%。更重要的是内存：移除遗留的插桩代码后，该 Worker 的第 99.9 百分位内存使用从 133MB 降到 118MB，压到了 128MB 限制以下。这类”差一点就超限”的场景，正是剖析数据最有价值的地方。

局限也要说清楚

按需采集不等于持续监控。较短的剖析窗口可能错过间歇性问题；堆内存剖析记录的是采集期间的分配情况，不能完整反映留存内存。此外，目标实例在采集期间必须接收到足够流量，否则样本会失真；TypeScript 开发者还需要开启源码映射，否则火焰图上全是编译后的函数名。

Cloudflare 表示正在推进持续性能剖析，目标是让罕见的性能问题不必依赖”猜什么时候会发生”。

趋势洞察

这类功能的意义，不只是多了一个调试按钮。它标志着边缘计算平台的运维能力正在补齐：从最早只提供日志，到指标、分布式追踪，再到现在的剖析，可观测性的三层结构逐步完整。

对在 Workers 上跑生产负载的团队来说，实际价值在于缩短定位路径——从”发现资源压力”直接走到”定位到具体函数”，不必先在本地复现。当无服务器架构承载的业务越来越重，这种能力会从”锦上添花”变成”上线前置条件”。

对平台方而言，竞争也开始从冷启动、价格转向工程效率。谁能帮用户更快找到那 1% 的浪费，谁就更容易留住长期负载。