weakref和finalizationregistry提供弱引用与回收通知，不支持内存压力触发的软引用语义；deref()返回null仅表示对象已被回收，时机不可控；finalizationregistry回调不及时、不传对象、不可重注册，无法模拟软缓存策略。

WeakRef 和 FinalizationRegistry 本身不构成软引用语义——它们提供的是弱引用 + 回收通知，不是“内存紧张时才回收”的软引用行为。想模拟软引用效果，必须额外引入内存压力感知与手动干预逻辑。

---

WeakRef.deref() 返回 null 的真实原因

WeakRef 不阻止 GC，但它的回收时机完全由 JS 引擎决定，且不可预测：

• 对象仅被 WeakRef 持有时，可能在下一次 GC 就被回收，也可能撑过多次 GC
• 引擎不会因内存不足而“加速”回收 WeakRef 所指对象（这和 Java 的 SoftReference 有本质区别）
• deref() 返回 null 只说明“已被回收”，不代表“该回收了”

常见误判场景：

• 在测试中反复调用 gc()（非标准 API，仅 V8 DevTools 可用）观察 deref() 是否为 null，误以为能控制回收节奏
• 把短生命周期对象缓存进 WeakRef，却期望它“尽可能久地存活”，结果频繁 miss

---

为什么不能直接用 FinalizationRegistry 模拟软引用

FinalizationRegistry 的回调：

• 不保证及时性：注册后可能数秒甚至更久才触发，也可能在页面卸载前都未触发
• 不传递原始对象：只传你注册时给的 holdings 值（如字符串 ID），无法读取对象状态或做条件判断
• 不可取消/重注册相同对象：同一对象只能注册一次，重复调用 registry.register(obj, ...) 会静默忽略

这意味着：

• 无法在回调里“检查内存水位，决定是否真清理”
• 无法实现“保留最近 N 个、淘汰最久未用”的 LRU-like 软缓存策略
• 无法回滚或延迟清理动作（比如发现刚回收的对象又被请求了，想临时复活——做不到）

---

如何逼近软引用行为（需组合手段）

你要的其实是：对象尽量驻留，仅当内存吃紧时才释放。JS 没有暴露内存水位 API，但可结合以下方式粗粒度模拟：

• 使用 performance.memory（仅 Chromium 系列支持）定期采样：

  if (performance.memory?.usedJSHeapSize > performance.memory?.totalJSHeapSize * 0.8) {
  // 主动清空部分 WeakRef 缓存
  cache.clear(); // 或 selective purge
  }

• 给每个缓存项打时间戳 + 访问计数，配合 FinalizationRegistry 回调做“回收后统计”：
  • 回调里记录“某 ID 在何时被回收”
  • 若某 ID 频繁重建又快速回收，说明它生命周期短，可降级为不缓存
• 用 WeakMap 替代 Map<key weakref></key> 存储元信息（如最后访问时间），避免对缓存值产生强引用干扰 GC

关键约束：

• 所有“主动清理”动作必须是副作用可控的（比如只删 Map 条目，不试图 resurrect 对象）
• 不要依赖 FinalizationRegistry 做资源释放主逻辑（如关文件、退订事件），它太不可靠；应配合显式 .destroy() 或 AbortController

---

WeakRef + FinalizationRegistry 是弱引用管理的正确工具链，但它们解决的是“如何不阻碍 GC”和“如何知道 GC 发生了”，不是“如何按内存压力调度回收”。真要软引用语义，得自己搭水位探测 + 缓存淘汰策略，且接受浏览器间行为差异。