CDN边缘脚本（例如Cloudflare Workers、AWS Lambda@Edge、腾讯云EdgeOne的JavaScript运行时）在距离用户最近的数据中心执行，平台通常采用V8隔离实例（Isolate）为每个脚本提供独立堆。与浏览器环境不同，边缘节点的内存配额往往只有128MB到512MB，且单个进程会承载成百上千个隔离实例。当一段脚本被设计为持续运行并处理请求时，任何一次微小的对象引用残留都可能在大流量下被指数级放大。内存泄漏的本质是对象已经不再参与业务逻辑，但引用链依然可达，导致垃圾回收器无法回收。本文从V8堆内存分配机制出发，梳理边缘脚本最常见的泄漏模式，并给出可操作的检测与修复方案。
边缘脚本内存模型与泄漏根源
V8引擎将堆分为新生代（Young Generation）和老生代（Old Generation）。新生代存放生命周期短的对象，通过Scavenge算法快速回收；老生代存放存活时间较长的对象，使用标记-清除和标记-整理算法。边缘脚本运行时通常为每个请求创建一个新的执行上下文，但脚本顶层定义的全局变量、模块级缓存以及挂在globalThis上的对象会跨越请求存活。如果这些全局结构不断累积数据而不主动清理，老生代堆就会持续增长，直到达到平台限制触发强制回收或进程重启。
在CDN边缘场景中，内存泄漏往往不是由单次大对象泄漏引起，而是大量小对象的滞留。比如一个边缘脚本在全局作用域维护了一个Map对象，用于缓存用户配置或AB测试结果。每次请求都会向这个Map中写入一条新记录，但没有设置淘汰策略。假设单条记录占2KB，每秒处理1000个请求，一分钟就会增长约120MB，很快耗尽256MB的堆配额。这种模式在传统服务器上可能数小时才暴露，但在边缘节点上几分钟内就能触发OOM。理解V8的对象可达性分析是定位问题的关键：只要从根（全局对象、栈、寄存器）出发能到达的对象，都不会被回收。
另一个容易被忽视的根源是闭包引用。JavaScript闭包会捕获其定义时所在作用域的所有变量，即使闭包内部只使用其中一个变量，整个作用域链都会被保留。在边缘脚本中，常见做法是在请求处理函数中创建定时器或注册回调，而定时器回调又间接引用了请求对象（如request、response）。如果定时器没有及时清除，或者回调被长期保存在全局事件表中，请求对象及其关联的响应体、头部信息都会被长期持有，导致严重内存泄漏。
典型泄漏模式与代码复现
第一种模式是全局缓存失控。以下代码片段展示了一个常见的错误做法：边缘脚本尝试缓存API响应以减少上游请求，但用全局Map存储且永不清理。
// 错误示例：全局缓存无淘汰策略
const cache = new Map(); // 跨请求存活的全局Map
async function handleRequest(request) {
const url = new URL(request.url);
const key = url.pathname; // 只用路径作为缓存键，忽略了查询参数可能的变化
if (cache.has(key)) {
return new Response(cache.get(key), {
headers: { 'content-type': 'application/json' }
});
}
const upstream = await fetch('https://api.origin.com' + url.pathname);
const body = await upstream.text();
cache.set(key, body); // 每次都写入，从不删除
return new Response(body, {
headers: { 'content-type': 'application/json' }
});
}
addEventListener('fetch', event => {
event.respondWith(handleRequest(event.request));
});
该脚本中cache变量位于模块顶层，属于全局对象可达，因此每次请求写入的响应体永远不会被回收。即使上游响应只有几KB，在攻击者不断请求不同路径的情况下，内存会在几分钟内被打爆。修复思路是引入带TTL的缓存或者使用WeakMap配合外部过期检查。更推荐的做法是利用边缘平台自带的Cache API（如caches.default），它由平台管理内存和持久化，不会造成进程内堆泄漏。
第二种模式是闭包意外持有请求上下文。例如在setTimeout中捕获了request对象，而定时器又被注册为长时间运行的任务。
// 错误示例：定时器回调持有请求对象
async function handleRequest(request) {
const timer = setTimeout(() => {
// 回调中引用了request，但定时器可能很久以后才执行
console.log('Request URL:', request.url);
}, 60 * 60 * 1000); // 1小时后触发
// 假设这里没有清除定时器，而是直接响应
const response = new Response('ok');
// timer没有被clearTimeout，定时器对象会一直存在
return response;
}
在V8中，定时器由事件循环维护，直到触发或清除前，其回调闭包持有的所有变量都不可回收。上述代码中request对象及其内部的headers、body流都会被闭包保留至少一小时。如果每秒有多个请求执行该脚本，内存泄漏速度会非常惊人。正确做法是在请求处理结束前调用clearTimeout(timer)，或者避免在定时器回调中直接引用请求对象，改为传递必要的标量值。
第三种常见问题是流式处理未正确消费。边缘脚本经常需要代理或转换请求/响应流，如果读取了request.body但没有调用reader.releaseLock()或流被意外中断，底层缓冲区可能无法释放。尤其在处理大文件上传或下载时，一个未关闭的流可能占用数十MB内存。建议始终使用await和Reader的规范方式消费流，并在finally块中释放锁。
内存泄漏检测与堆快照分析
要确认边缘脚本是否存在内存泄漏，不能只靠线上OOM告警，需要在本地或测试环境进行压力测试。对于基于V8的运行时，可以使用Node.js的--inspect标志启动脚本，通过Chrome DevTools的Memory面板采集堆快照。对于Deno环境，可以使用deno --inspect并配合Deno.core.heapStats()获取内存信息。在Cloudflare Workers本地模拟器中，也可以利用wrangler dev的调试端口进行堆分析。
堆快照分析的核心指标是Retained Size（保留大小）。它表示一个对象及其独占引用的所有对象总共占用的内存。定位泄漏的通用方法是：在脚本运行一段时间后采集两次快照，对比两次快照之间的对象数量差异。重点观察Map、Set、闭包上下文（通常显示为(closure)）以及字符串的实例数量是否持续增长。如果某个自定义类的实例数量随时间线性增加，基本可以断定存在泄漏。此外，Distance字段表示对象距离GC根的距离，泄漏对象通常有较短的Distance，因为被全局或持久引用直接持有。
在边缘平台生产环境中，直接获取堆快照比较困难，但多数平台提供了内存指标。例如Cloudflare Workers的cf-ray头或运行时指标中可能包含内存使用量。可以编写一个定时任务，每隔一段时间记录当前隔离实例的内存占用，并绘制曲线。如果内存曲线呈现阶梯式上升且从未回落，说明存在泄漏。部分平台还提供PerformanceResourceTiming或自定义日志，可以将内存数据写入日志系统进行聚合分析。
治理策略与防御性编码
针对全局缓存泄漏，最有效的做法是避免在脚本顶层维护任何可增长的数据结构。如果确实需要跨请求缓存，必须实现严格的TTL机制和容量上限。下面给出一个简单的带过期时间的缓存实现，使用setTimeout自动删除条目，并限制最大条目数。
// 带TTL和容量限制的缓存
const MAX_ENTRIES = 1000;
const TTL_MS = 60 * 1000; // 1分钟
const cache = new Map();
const expiryTimers = new Map();
function cacheSet(key, value) {
if (cache.size >= MAX_ENTRIES) {
const firstKey = cache.keys().next().value;
cache.delete(firstKey);
clearTimeout(expiryTimers.get(firstKey));
expiryTimers.delete(firstKey);
}
cache.set(key, value);
const timer = setTimeout(() => {
cache.delete(key);
expiryTimers.delete(key);
}, TTL_MS);
expiryTimers.set(key, timer);
}
// 使用时：cacheSet(key, data)
对于闭包引用，推荐使用WeakRef和FinalizationRegistry处理非关键缓存，或在回调中仅传递原始值。例如将请求URL提取为字符串后再放入定时器，避免直接引用整个Request对象。此外，在finally块中主动清理事件监听器和定时器是内存安全的基本习惯。边缘平台的隔离实例通常会在请求结束后被冻结或重置，但脚本顶层全局变量仍然存活，因此任何模块级可变状态都应当视为潜在泄漏源。
针对流处理，应当遵循总是读完或取消的原则。如果不需要读取请求体，可以调用request.body?.cancel()来主动释放资源；处理响应时使用pipeTo并确保在异常时调用reader.cancel()。同时，避免在流数据上调用arrayBuffer()或text()后再次读取，因为流只能消费一次，重复读取会抛出异常并可能造成缓冲区悬挂。
监控与自动恢复机制
边缘平台通常会对单个隔离实例设置内存上限，达到上限时会触发OOM错误并强制重启该实例。虽然重启能够暂时恢复，但频繁重启会导致请求失败率上升和缓存击穿。因此，需要建立内存预警体系。可以在脚本内部通过globalThis.memoryUsage等自定义接口上报内存数据，或者使用平台提供的Worker健康检查。当内存占用达到阈值时，主动采取降级措施，例如关闭非核心缓存、拒绝高开销请求或返回静态降级页面。
另一个有效的策略是利用隔离实例复制和请求路由。许多边缘平台允许设置脚本实例的内存配额和最大请求处理时间。如果发现某类脚本经常内存泄漏，可以将其拆分为多个轻量级函数，每个函数只处理单一职责，避免全局状态累积。对于需要长驻缓存的场景，优先使用平台提供的持久化存储（如KV存储），将缓存从进程内存转移到外部，彻底消除堆内泄漏风险。
最后，定期进行压力测试和泄漏扫描应当纳入发布流程。可以使用autocannon或wrk模拟高并发请求，持续运行几分钟并观察内存曲线。在CI中集成内存检查工具，如memlab或自研的堆快照对比脚本，能够提前发现泄漏趋势。边缘脚本的内存治理不是一次性工作，而是需要编码规范、检测工具和平台监控共同构成的持续防线。