JavaScript WeakRef 缓存反模式：为什么你的弱引用缓存根本不会命中 - 简希博客

ES2021 带来了 WeakRef 和 FinalizationRegistry，许多开发者第一反应是："终于可以写一个自动清理的缓存了！" 于是写下这样的代码：

// 反例 1：天真地以为弱引用 = 自动命中缓存
const cache = new Map(); // key -> WeakRef

function load(key) {
  const ref = cache.get(key);
  if (ref) {
    const value = ref.deref();
    if (value !== undefined) {
      return value; // 命中缓存
    }
  }
  const value = expensiveCompute(key);
  cache.set(key, new WeakRef(value));
  return value;
}

表面看逻辑无懈可击：只要对象还活着，deref() 就能拿到它；一旦被回收，WeakRef 自动失效。但这段代码在生产环境里几乎永远命中不了缓存。

反例为什么会翻车

WeakRef 的语义是"不阻止目标被 GC"，但它不保证目标在两次 deref() 之间保持存活。真正致命的是：GC 的触发时机完全不在你的掌控之中。

// 反例 2：deref 之后立刻使用，依然可能拿到 undefined
function getImage(id) {
  const ref = imageCache.get(id);
  if (!ref) return loadAndCache(id);
  const img = ref.deref();
  if (!img) return loadAndCache(id);
  // ❌ 这里 img 仍可能在下一条语句前被回收（虽然概率极低，但规范允许）
  return process(img);
}

更常见的失败模式是缓存键本身就是强引用的来源。看这个经典错误：

// 反例 3：用对象本身当 key，等于没弱引用
const weakCache = new WeakMap();

function getProfile(user) {
  if (weakCache.has(user)) return weakCache.get(user);
  const profile = { user, bio: fetchBio(user) };
  weakCache.set(user, profile);
  return profile;
}

这里 user 作为 key 是强引用，只要 user 还活着，profile 就永远不会被回收。关键问题是——你以为"值 profile不再被引用就能回收"，但实际上 profile.user 反向强引用了 user，形成事实上的强关联。缓存根本没起到减轻内存压力的作用。

命中率归零的真相

来看一个可以复现的案例。我们在 Node 里观察 WeakRef 缓存的真实命中率：

// 正确实验：理解父对象与目标的引用关系
let hit = 0, miss = 0;
const cache = new Map(); // name -> WeakRef<Data>

function getData(name) {
  const ref = cache.get(name);
  const cached = ref && ref.deref();
  if (cached) { hit++; return cached; }
  miss++;
  const data = { name, payload: new Array(1000).fill(name) };
  cache.set(name, new WeakRef(data));
  return data;
}

// 模拟：拿到结果后，外部不再持有 data，只靠 cache 的弱引用
for (let i = 0; i < 1000; i++) {
  const d = getData('key' + (i % 10));
  consume(d); // consume 内部不保留引用
}

// 触发 GC，然后再次访问
global.gc?.();
for (let i = 0; i < 10; i++) {
  getData('key' + i);
}
console.log({ hit, miss });

运行 node --expose-gc index.js，你会看到 miss 远大于 hit。原因是：一旦外部没有强引用，data 就成了孤岛，GC 随时可能回收它。你的"缓存"实际上只在一个极窄的时间窗口内才有效——这个窗口短到可以忽略。

什么时候 WeakRef 才真正有用

WeakRef 不是用来做"缓存"的，而是用来做"不让缓存阻碍回收"的协作式弱引用。正确的使用场景：

1. 昂贵的缓存 + 便宜的重新计算

只有当"缓存命中是纯优化，未命中完全无副作用"时，弱引用才有意义：

// 正例：可重建的昂贵派生值，未命中无损
const derivedCache = new Map();

function getDerived(key) {
  const ref = derivedCache.get(key);
  const cached = ref && ref.deref();
  if (cached !== undefined) return cached;

  const derived = expensivePureCompute(key); // 纯函数，无副作用
  derivedCache.set(key, new WeakRef(derived));
  return derived;
}

这里的关键约束：expensivePureCompute 是纯函数。即使缓存失效导致重复计算，结果也完全一致。这不适合网络请求、数据库查询等有副作用或昂贵 I/O 的操作。

2. 配合强引用缓存做"最后一道防线"

真正健壮的模式是强缓存 + 弱缓存分层：

// 正例：强缓存为骨架，弱缓存作为容量淘汰后的兜底
const strongCache = new Map(); // 有容量上限，LRU
const weakCache = new Map();   // 淘汰后仍能抢救的弱引用

function get(key) {
  if (strongCache.has(key)) return strongCache.get(key);

  const ref = weakCache.get(key);
  const rescued = ref && ref.deref();
  if (rescued !== undefined) {
    strongCache.set(key, rescued); // 重新“激活”
    return rescued;
  }
  const value = load(key);
  strongCache.set(key, value);
  return value;
}

function evict(key) {
  const value = strongCache.get(key);
  strongCache.delete(key);
  weakCache.set(key, new WeakRef(value)); // 降级为弱引用，GC 说了算
}

这样 weakCache 只是一个机会主义加速层：命中是赚到，未命中回到正常加载路径，逻辑正确性完全由 strongCache + load 保证。

FinalizationRegistry 的清理陷阱

另一个高频误用是试图用 FinalizationRegistry 做资源释放：

// 反例：以为 finalizer 能可靠关闭资源
const registry = new FinalizationRegistry((id) => {
  db.closeConnection(id); // ❌ 不可靠！执行时机不确定，甚至永不执行
});

function makeClient() {
  const client = db.openConnection();
  registry.register(client, client.id);
  return client;
}

FinalizationRegistry 的回调不保证：

何时执行（可能延迟很久）
是否执行（程序退出前可能根本不会触发）
在哪个调用栈执行（可能与其他对象批量清理一起触发）

它只适合清理那些"漏掉了也不会出错"的辅助资源，比如删除诊断用的 Map 键、写日志标记等。对于需要确定性释放的（文件句柄、网络连接、Worker），应该用显式的 close()/AbortController/try-finally。

// 正例：确定性资源释放，与 GC 无关
async function processFile(path) {
  const handle = await fs.open(path, 'r');
  try {
    return await handle.readFile();
  } finally {
    await handle.close(); // ✅ 显式、确定、可测试
  }
}

正确姿势总结

场景	是否该用 WeakRef	原因
有副作用/昂贵 I/O 的缓存	❌	命中率不可控，会导致重复副作用
纯函数计算的派生值缓存	✅	未命中无损，弱引用防止内存泄漏
LRU 强缓存淘汰后的兜底	✅	作为机会主义加速层
需要确定性释放的资源	❌	用显式 close/try-finally
诊断/辅助性清理	⚠️ 可用 FinalizationRegistry	但不要依赖它保证执行

核心心智模型：WeakRef 解决的是"我要引用一个对象，但不希望因为引用它而阻止它被回收"，而不是"我想缓存一个对象"。前者是内存治理诉求，后者是性能诉求，两者看似相近，实则对你的代码正确性有截然不同的要求。

一旦你理解 weakCache.get(key) 返回 undefined 是"正常路径"而非"异常情况"，你就真正掌握了 WeakRef 的正确姿势。

// 最终心智模型：命中是意外之喜，miss 是默认路径
function load(key) {
  const cached = tryRescueFromWeak(key); // 可能 undefined，没关系
  if (cached !== undefined) return cached;
  return buildFresh(key); // 永远正确的兜底
}

记住：弱引用缓存的价值不是"命中"，而是"不挡路"。把命中当作 bonus，你的缓存设计才不会踩坑。