Workers内存分析怎么看：分配热点与长期泄漏不能画等号

Workers内存分析怎么看：分配热点与长期泄漏不能画等号。围绕实际建站与运维需求，整理检查步骤、验证方法和适用边界，避免照搬配置导致新的问题。

先写清楚要证明的问题

Cloudflare于2026年10月开放Workers和Durable Objects按需分析后，开发者可以查看函数层面的资源线索。但一次内存分配热点，只说明采样期间某段代码分配较多，并不自动证明对象长期无法释放。

把负载和版本固定下来

选择能复现问题的请求类型，记录部署版本、并发、输入大小与采样窗口。把单次大文件处理和普通页面请求混在一起比较，容易得出错误结论。先观察总体错误和内存现象，再选择对应函数进行分析。

排查缓存或集合时，记录条目数量是否随任务结束而回落，以及相同任务重复后占用是否持续增加。检查是否保留了整个响应、重复序列化或让全局容器无限增长。这些是调查方向，不是看到宽条后就能确认的原因。

用一项改动验证假设

每轮只修改一个明确因素，例如限制缓存上限或减少中间副本。在接近的负载下重新采样，同时检查响应结果和耗时。内存下降但频繁重新请求上游，也可能把成本转移到其他环节。

源码映射有助于识别函数；流量不足时应先确认采样对象。保留修复前后记录，避免只展示最好的一次图。本文没有给出适用于所有应用的容量数字，也没有把厂商示例成绩当作本站实测。

官方资料核对：2026-11-02。

参考：官方资料。