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>存储元信息（如最后访问时间），避免对缓存值产生强引用干扰 GC
关键约束：
- 所有“主动清理”动作必须是副作用可控的（比如只删 Map 条目，不试图 resurrect 对象）
- 不要依赖
FinalizationRegistry做资源释放主逻辑（如关文件、退订事件），它太不可靠；应配合显式.destroy()或AbortController
WeakRef + FinalizationRegistry 是弱引用管理的正确工具链，但它们解决的是“如何不阻碍 GC”和“如何知道 GC 发生了”，不是“如何按内存压力调度回收”。真要软引用语义，得自己搭水位探测 + 缓存淘汰策略，且接受浏览器间行为差异。
